On 6/18/19 12:33 PM, Jakub Jelinek wrote:
> On Tue, Jun 18, 2019 at 12:27:31PM +0200, Martin Liška wrote:
>>> Oops. The problematic case is then if the STRING_CST c_getstr finds
>>> is not NUL terminated (dunno if we ever construct that) or if
>>> string_size is smaller than string_length and there are no NULs in that
>>> size.
>>
>> The function always returns a null-terminated string:
>>
>> 14587 /* Return a pointer P to a NUL-terminated string representing the
>> sequence
>> 14588 of constant characters referred to by SRC (or a subsequence of
>> such
>> 14589 characters within it if SRC is a reference to a string plus some
>> 14590 constant offset). If STRLEN is non-null, store the number of
>> bytes
>> 14591 in the string constant including the terminating NUL char.
>> *STRLEN is
>> 14592 typically strlen(P) + 1 in the absence of embedded NUL
>> characters. */
>> 14593
>> 14594 const char *
>> 14595 c_getstr (tree src, unsigned HOST_WIDE_INT *strlen /* = NULL */)
>> 14596 {
>> 14597 tree offset_node;
>> 14598 tree mem_size;
>>
>> That said, the unconditional strnlen should be fine.
>
> But *strlen it sets might be smaller.
No, for "A\0" you'll get *strlen == 3, but strlen (returned value) == 1.
>
> I'd try say const char foo[5] = "foobar";
> or similar, or say stick gcc_assert in c_getstr where it is setting
> *strlen and gcc_assert (strnlen (to be returned value, *strlen) < *strlen);
> do a bootstrap/regtest with that and see if it ever triggers (or instead
> of assert failure log into a log file with "a" mode).
>
> If not, there is no point to pass non-NULL second argument to c_getstr,
> you'd always just use strlen on the returned string.
There might be consumers (like folding of memcmp) of c_getstr which want to
know how long is a string constant
even thought there's a null-terminating character in the middle of the constant.
Martin
>
> Jakub
>
