I must apologize as it seems I misread the PR somehow.
>>>> 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).
> I opened up the PR of this particular bug and the assignment of the
> literal is not part of the reported problem. It's just the lazy
> implementation of the GCC developer. So replacing the empty string literal
> "" with an array containing an empty string fixes both problems.
I'm not sure what I read yesterday, but looking again today at
indicates that the string being read-only is exactly what is the problem
>>> 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
>>> 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).
>> You seem to assume that failing this test always means that the
>> condition "s.name [s.len] != 0" will be true at runtime, and the test
>> author just used the write to the string as a substitute for a failed
> No, I assume that the author didn't think things through.
I must take this back.
>> However, it could very well be that the write to string in the C code is
>> required to trigger the bug we want to test for.
It seems so. How I understand it now is that
char *s = "";
if (*s != 0)
*s = 0;
was transformed by GCC into
*s = (*s != 0) ? 0 : *s;
And thus it probably ALWAYS writes to the literal which can be in
Maybe another optimization takes place after this transformation, like:
*s = 0;
But that still writes to the literal.
So now my conclusion is that I agree with you that this test should stay
as it is and that the current regression test suite cannot detect this
problem. But the warning should still be suppressed though.
>>> String literals are not required to be modifiable. This specification
>>> allows implementations to share copies of strings with identical text,
>>> to place string literals in read-only memory, and to perform certain
>>> optimizations. However, string literals do not have the type array of
>>> const char in order to avoid the problems of pointer type checking,
>>> particularly with library functions, since assigning a pointer to
>>> const char to a plain pointer to char is not valid.
>>> If the program attempts to modify such an array, the behavior is
>> So it is ok that SDCC places the string literal in ROM, but it is wrong to
>> make it const implicitly. And the behavior of modifying the contents at
>> runtime should not be checked (or even executed) in the regression tests.
Or we should check the SDCC implementation only.
> Hmm, if we make the simulators report an error on write to ROM (as we
> now do for invalid instructions) we can handle this. And we catch many
> cases of the much more common problem of writes through invalid
> pointers, too!
Well, to capture this bug we should. As mentioned for mcs51/ds390 this
could be done in _gptrput.c by locking up the MCU. For non-generic
pointers it will be caught at compile time since there is no instruction
to write to code memory in the mcs51. For other (von Neumann)
architectures it probably requires telling the simulator which memory is
ROM and which is RAM and adding the test to the simulator.