Re: [PATCH] Fix the damage done by my other patch from yesterday to strlenopt-49.c

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

On 07/30/18 18:01, Joseph Myers wrote:
> On Mon, 30 Jul 2018, Jakub Jelinek wrote:
> 
>> On Mon, Jul 30, 2018 at 03:52:39PM +0000, Joseph Myers wrote:
>>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>>
>>>> In the moment I would already be happy if all STRING_CSTs would
>>>> be zero terminated.
>>>
>>> generic.texi says they need not be.  Making the STRING_CST contain only
>>> the bytes of the initializer and not the trailing NUL in the C case where
>>> the trailing NUL does not fit in the object initialized would of course
>>> mean you get non-NUL-terminated STRING_CSTs for valid C code as well.
>>
>> One thing is whether TREE_STRING_LENGTH includes the trailing NUL byte,
>> that doesn't need to be the case e.g. for the shortened initializers.
>> The other thing is whether we as a convenience for the compiler's internals
>> want to waste some memory for the NUL termination; I think we could avoid
>> some bugs that way.
> 
> TREE_STRING_LENGTH includes the NUL if it is logically part of the object,
> but should not if the NUL is purely an implementation convenience.
> 

To complicate things a bit more STRING_CST that are created by the Ada FE
for the purpose of ASM constraints, do not contain a NUL character.
That is in TREE_STRING_LENGTH, there is of course always another NUL char
after the payload.  Likewise for C __attribute__ values.


Thanks
Bernd.