>> ./pypcre.c:4524: warning: variable `start_bits' might be
>> clobbered by `longjmp' or `vfork'
>> ./pypcre.c:4525: warning: variable `start_match' might be
>> clobbered by `longjmp' or `vfork'
> These are often a PITA to fix: gcc does brain-dead flow analysis, and this
> particular msg is almost always bogus as a result. There are several open
> bugs filed against gcc on this (I know because one of them is mine <wink>).
> The others look straightforward to fix (on a first scan).
At least for start_match, what exactly is bogus about this message?
setjmp is invoked in line 4691 of pypcre, and start_match is modified
in line 4737, at the end of the while loop containing the setjmp
call. If somebody would invoke longjmp on the jmp_buf after
start_match is modified, it would have an indeterminate value,
according to 7.13.2.1p3 of C99.
Likewise for start_bits, as it may also be modified after setjmp() has
been called, since it appears in the same loop. I admit that there
wouldn't be too many calls that could actually invoke longjmp() before
the next invocation of setjmp, except perhaps for pchars(), but gcc is
not supposed to determine potential callers of longjmp:
The compiler sees only the calls to `setjmp'. It cannot know
where `longjmp' will be called; in fact, a signal handler
could call it at any point in the code. As a result, you may
get a warning even when there is in fact no problem because
`longjmp' cannot in fact be called at the place which would
cause a problem.
So while I'd admit that gcc "does brain-dead flow analysis", I think
this particular msg is not bogus in this specific case. It's more
often than not that gcc users fail to understand this message, though.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4