Ticket UUID: | ad5a57f2f271b5a40fe9abef4055dc7b547c80c0 | |||
Title: | Functions passed to Tcl_CreateFileHandler() must be declared/defined as Tcl_FileProc | |||
Type: | Patch | Version: | 8.6.13 | |
Submitter: | chrstphrchvz | Created on: | 2023-10-12 10:58:29 | |
Subsystem: | 01. Notifier | Assigned To: | jan.nijtmans | |
Priority: | 5 Medium | Severity: | Minor | |
Status: | Closed | Last Modified: | 2023-10-12 21:16:11 | |
Resolution: | Fixed | Closed By: | jan.nijtmans | |
Closed on: | 2023-10-12 21:16:11 | |||
Description: |
The signature of Tcl_NotifyChannel() does not match Tcl_FileProc, but in core Tcl there are 3 instances where it is passed to Tcl_CreateFileHandler() anyway. Example UBSan -fsanitize=function error when Tcl_NotifyChannel() is later called from FileHandlerEventProc():
tcl/macosx/tclMacOSXNotify.c:1223:6: runtime error: call to function Tcl_NotifyChannel through pointer to incorrect function type 'void (*)(void *, int)'
tclIO.c:8341: note: Tcl_NotifyChannel defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior tcl/macosx/tclMacOSXNotify.c:1223:6 in
Since Tcl_NotifyChannel() is a public API, the workaround I would propose is to use wrapper functions; see attached patch. If wanting to pass Tcl_NotifyChannel to Tcl_CreateFileHandler() is so common elsewhere that it should be allowed, then an alternative would be to add a special case to FileHandlerEventProc() which checks if filePtr->proc is Tcl_NotifyChannel so that Tcl_NotifyChannel() can be called directly. | |||
User Comments: |
jan.nijtmans added on 2023-10-12 21:16:11:
Fixed [428afeec4b77b244|here] Thanks for the report and the patch! |
Attachments:
- ad5a57f2f271.diff [download] added by chrstphrchvz on 2023-10-12 11:01:59. [details]