From: Maarten B. <sou...@ds...> - 2012-10-25 09:33:27
|
Philipp, >> Ah, so it segmentation faults if a regression test fails. That's also a >> way to fail. (gcc-torture-execute-20051104-1.c) > To me, regression test gcc-torture-execute-20051104-1.c is somewhat like > this: > > if(0) > x /= 0; > > Now, dividing by zero would be undefined behaviour. But a conforming > compiler has to accept this code. Just as it should accept > > char *a = "bla"; > if(0) > a[0] = 0; > > If instead of the plain 0 in the condition there is something that the > compiler cannot decide at compile time it still has to behave correctly. > Undefined behaviour may only happen when the code in question would > actually be executed. > > IMO the test gcc-torture-execute-20051104-1.c should stay as it is, and > we disable the sdcc warning using a #pragma (note that the standard > AFAIK never forbids emitting a warning for conforming code). > > Philipp I agree with your assertions, but disagree with your conclusion. This test has two issues. The first is that SDCC gives a warning for the assignment of the string literal and GCC stays quiet for some unknown reason. If we want to test that SDCC accepts this assignment, the expected warning should be disabled (suppressed) with the #pragma. That is exactly why I introduced this #pragma a long time ago. But I would prefer a specific regression test to accept char *s = "abc" and never use this construct in any other test as an accidental side effect test. This goes for all regression tests that generate expected warnings, so please do not commit tests that generate warnings. If the warning generating code is not the core of the issue to be tested change it to conforming code. IMHO only tests that generate warnings that still need to be fixed can stay as a reminder (e.g. long-long or double support). The second issue is that when for some reason the regression test fails it will execute code with undefined behavior. I find that a very unfriendly way to fail. On a machine with MMU like the host with GCC it can generate a segmentation fault. On an embedded MCU it most likely performs a NOP, but we might as well lock the MCU up (e.g. in _gptrput.c). to Borut, >>> I don't know what is written in the standard but IMHO it is better that >>> the compiler complains when the constant literal string is assigned to >>> non-constant pointer since it (potentially) causes the run time error >>> (which is never shown in sdcc case). >>> >>> And now the answer to your question from my point of view: in sdcc >>> string literal is constants an the compiler should throw an error when >>> assigning it to a non constant char pointer. >> >> So it seems we agree to disagree with the standard! String literals >> should be constant. And warnings should be given. But then I propose to >> change the gcc tests to conform and not use char *s = "123" in there. >> >> Maarten I'm with Philipp here that we should not generate an error but stick to a warning. >>> Putting literals strings into rw memory by default doesn't make sense >>> in embedded systems since it is an overhead in RAM, ROM and instruction >>> cycles consumption. >>> >>> Borut I fully agree. Maarten |