[issue47188] ncurses: *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE=3
Change by Siddhesh Poyarekar : -- nosy: +siddhesh ___ Python tracker <https://bugs.python.org/issue47188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33029] Invalid function cast warnings with gcc 8 for getter and setter functions
Siddhesh Poyarekar added the comment: Sorry I haven't had time to look into this since and it doesn't look like I'll be able to get to it in the next couple of weeks. I had a couple of patches in the github fork but they're pretty outdated and probably not even correct. If nobody gets to it by Christmas holidays, I'll give it a shot. -- ___ Python tracker <https://bugs.python.org/issue33029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: > Pedantically the correct way is to cast to a function pointer with no > prototype (empty parentheses) and from that to the target type. See for > example. See for example https://godbolt.org/g/FdPdUj This is one way that the gcc diagnostics explicitly allow in addition to variable arguments like so: https://godbolt.org/g/Dtb4fv -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33015] Fix function cast warning in thread_pthread.h
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: Actually it is not; the parameter passed to Pythread_start_new_thread has a different type (void (*)(void *)) from what's accepted (and executed by) pthread_create (void *(*)(void *)). That is undefined behaviour. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33015] Fix function cast warning in thread_pthread.h
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: gcc8.1 throws this warning irrespective of the cast since converting function pointers may result in undefined behaviour unless it is cast back to its original type. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: Yeah, there are multiple such uses that need wrappers to actually fix for gcc8, which will be released this week. I think I'll have more time for some more patches in this vein this weekend. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: Fair enough, I'll reduce my scope of changes for this patchset, especially since I'm unable to find enough time to work on the remaining changes I had thought of in the coming weeks. I'll post an updated patch soonish. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: I forgot to clarify that the function cast warning allows for variable argument casts as a wildcard, which is my basis for the PyObject *(*)(PyObject *, PyObject *, ...) fix proposal. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment: > The warning in GCC shouldn't probably have been enabled at all in `-Wall > -Wextra` because the cast is explicit. However, it is somewhat true. The explicit cast is precisely what enables the more nuanced function cast warning where it checks the function for type compatibility. That is, it will check the types of the return and arguments and then warn in case of mismatch. > However, the correct way to fix would be to have the METH_NOARGS case cast > the function to the right prototype. There exists lots of existing code that > *is* going to break too. AFAICT, there is no right prototype for the METH_NOARGS function; there used to be a PyCFunctionWithNoArguments but that seems to have fallen out of favour some time back. The prototype that seems to be commonly in use (and in clinic as well, which is what I based my patches on) is the PyCFunction, which seems like a safe way to do things. > Perhaps PyCFunction should declare no prototype, i.e. empty parentheses, for > backwards compatibility: > > typedef PyObject *(*PyCFunction)(); > > and deprecate it; start using a new typedef for it - and then add proper > casts in every place that call a function. I have a patch in the works that makes it PyObject *(*)(PyObject *, PyObject *, ...) which allows for two compulsory arguments (fits in with most cases, provided the METH_NOARGS patch is accepted) and then the rest depending on the type of the cast function. The rest of the PyMethodDef functions are much simpler fixes this way. It also seems like a more intuitive description of the callbacks. Then there are getter and setter and other function pointers that need similar fixes to METH_NOARGS. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Siddhesh Poyarekar <siddhesh.poyare...@gmail.com> added the comment:
> I don't have GCC 8 so I cannot verify this bug, but *function pointer casts*
> are fine - any function pointer can be cast to any other function pointer -
> it is only that they must *not* be called unless cast back again to be
> compatible with the function definition. Any fix to the contrary might well
> *cause* undefined behaviour!
Please see the attached PR; METH_NOARGS callbacks are inconsistent in their
signature and many have just one argument while they're called with two
arguments, the second being NULL. The patch fixes these to consistently take
and call with two arguments.
> Could you provide a sample of the *actual warnings* so that they could be
> studied?
Here's one of a few hundred.
Objects/bytesobject.c:3085:25: warning: cast between incompatible function
types from ‘PyObject * (*)(striterobject *)’ {aka ‘struct _object * (*)(struct
*)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct
_object * (*)(struct _object *, struct _object *)’} [-Wcast-function-type]
{"__reduce__", (PyCFunction)striter_reduce, METH_NOARGS,
^
This is a new warning in gcc8, so you'll likely not find much reference, but
here's a gcc bug report that might give you more context:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33012>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33029] Invalid function cast warnings with gcc 8 for getter and setter functions
New submission from Siddhesh Poyarekar <siddhesh.poyare...@gmail.com>: gcc 8 has added a new warning heuristic to detect invalid function casts and a stock python build seems to hit that warning quite often. bug 33012 fixes the most trivial case of METH_NOARGS, this bug is to track a similarly trivial but widely applicable fix, which is to cast getter and setter functions. Patches coming up over the weekend. -- components: Build messages: 313443 nosy: siddhesh priority: normal severity: normal status: open title: Invalid function cast warnings with gcc 8 for getter and setter functions type: compile error ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Change by Siddhesh Poyarekar <siddhesh.poyare...@gmail.com>: -- keywords: +patch pull_requests: +5792 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33015] Fix function cast warning in thread_pthread.h
Change by Siddhesh Poyarekar <siddhesh.poyare...@gmail.com>: -- keywords: +patch pull_requests: +5773 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33015] Fix function cast warning in thread_pthread.h
New submission from Siddhesh Poyarekar <siddhesh.poyare...@gmail.com>: The PyThread_start_new_thread function takes a void (*)(void *) as the function argument, which does not match with the pthread_create callback which has type void *(*)(void *). I've got a fix for this that adds a wrapper function of the right type that subsequently calls the function passed to PyThread_start_new_thread. PR coming up. -- components: Build messages: 313357 nosy: siddhesh priority: normal severity: normal status: open title: Fix function cast warning in thread_pthread.h type: compile error ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
New submission from Siddhesh Poyarekar <siddhesh.poyare...@gmail.com>: gcc 8 has added a new warning heuristic to detect invalid function casts and a stock python build seems to hit that warning quite often. The most common is the cast of a METH_NOARGS function (that uses just one argument) to a PyCFunction. The fix is pretty simple but needs to be applied widely. I'm slowly knocking them off in my spare time; WIP here, which has a few other types of warnings mixed in that I'll sift out during submission and also create separate bug reports for: https://github.com/siddhesh/cpython/tree/func-cast I'll clean up and post PR(s) once I am done but I figured I should file this report first since it is a pretty big change in terms of number of files touched and wanted to be sure that I'm making changes the way the community prefers. -- components: Build messages: 313317 nosy: siddhesh priority: normal severity: normal status: open title: Invalid function cast warnings with gcc 8 for METH_NOARGS type: compile error ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17833] test_gdb broken PPC64 Linux
Siddhesh Poyarekar added the comment: It's not a change in glibc. __pthread_cond_timedwait is the internal function name while pthread_cond_timedwait is the exported alias. You're seeing __pthread_cond_timedwait here because either your glibc installation has debug symbols or you have debug info packages installed, which allows gdb to resolve the function name to the internal name. Without glibc debug info you should see just pthread_cond_timedwait@@... or just pthread_cond_timedwait. In any case, I guess you'd be better off just using .find(pthread_cond_timedwait) instead of startswith() since I've also seen this on ppc64, which might break your test again: Thread 2 (Thread 0x3fffb7d1f200 (LWP 5746)): #0 0x3fffb7f21ec8 in .pthread_cond_timedwait () from /lib64/libpthread.so.0 I'm not entirely sure what the preceding dot means, but it seems to indicate a function call outside the binary in ppc64. -- nosy: +Siddhesh.Poyarekar ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
