gh-111178: fix UBSan failures in Python/traceback.c
#128259
Conversation
picnixz
commented
Dec 25, 2024
•
picnixz
commented
- Issue: UBSan: Calling a function through pointer to incorrect function type is undefined behavior #111178
| {NULL} /* Sentinel */ | ||
| {"tb_next", tb_next_get, tb_next_set, NULL, NULL}, | ||
| {"tb_lineno", tb_lineno_get, NULL, NULL, NULL}, | ||
| {NULL, NULL, NULL, NULL, NULL} /* Sentinel */ |
There was a problem hiding this comment.
Is this needed? I was under the impression that a NULL name indicated the sentinel--nothing should be necessary after it, right?
There was a problem hiding this comment.
Strictly speaking no, but this would leave fields non-initialized. Considering that the UBSan PRs are meant to avoid compiler issues (also, I think it's always better to initialize fields when possible). But I can revert those changes.
There was a problem hiding this comment.
Ok, I've thought about it. Since we're moving towards removing un-necessary fields in static structures, I think it's better to just have a single NULL for a sentinel (ideally, a macro would be better so that we don't need to indicate that XXX is a sentinel but let's keep the diff smaller). I'll also update my other PRs.
There was a problem hiding this comment.
Strictly speaking no, but this would leave fields non-initialized.
I'm pretty sure partial initialization in C will leave the other fields as zero (or NULL here).
