Tanaka, It's interesting that you should point this out, because I started this debugging adventure by building a version of eval.c that would compile without these warnings. I ended up with many more volatile qualifiers and useless initializations and the code still didn't work. Later I found this text in the gcc manual: "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." There is a similar problem with uninitialized variable warnings. The compiler cannot predict the code's dynamic execution paths and so may emit false positives. So, it looks like the gcc project has yet to replace folks like us. That's comforting in these troubled times. :-) - brent Tanaka Akira-3 wrote: > > In article <49a9024b.0e0d6e0a.11f5.ffffee2f / mx.google.com>, > Nobuyoshi Nakada <nobu / ruby-lang.org> writes: > >> I guess you misses a point here, gcc is aware of setjmp() and >> emits code to save and restore registers into the stack before >> and after it. I suspect it doesn't work enough for some reason. >> Anyway, your way would be correct for other compilers. > > gcc -O -W warns it. > > % gcc -O2 -g -W -Wall -Wno-parentheses -DRUBY_EXPORT -I. -I. -c > eval.c > ... > -- > Tanaka Akira > > > -- View this message in context: http://www.nabble.com/MBARI8-patch-fixes-bugs-caused-by-incorrect-volatile-variable-declarations-tp22259357p22265962.html Sent from the ruby-core mailing list archive at Nabble.com.