Overview
| Artifact ID: | f4c18b2b5acc399500a044ae4f39bddc201b637abbffaf7310fe17cbd770e283 |
|---|---|
| Ticket: | 8ab8a138c9156e5a5a4a386310c6fd11608b8805
Functions passed to Tcl_EventuallyFree() must be declared/defined as Tcl_FreeProc |
| User & Date: | chrstphrchvz 2023-10-22 23:18:44 |
Changes
- icomment:
<blockquote>There's a lot of code out there (e.g. Tk, Itcl) which uses this feature, UBSan just reports false-positives for them.</blockquote> One can use <tt>-fsanitize=undefined -fno-sanitize=function</tt>, but I doubt UBSan’s reports of undefined behavior are false positives*, despite things behaving as expected under typical calling conventions. Or have I misunderstood what you meant by “false positives”? *(The only potential false positives I am aware of are those due to this feature’s reliance on name mangling, which is more strict than standard C type compatibility; see [https://reviews.llvm.org/D148827].) That being said, I do not know how immediate any danger posed by optimizing compilers is for exploiting this type of undefined behavior. Instances within a single translation unit, or with LTO enabled, speculatively seem more concerning.
- login: "chrstphrchvz"
- mimetype: "text/x-fossil-wiki"