This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

On 08/21/2018 05:50 AM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:

I still believe it would be simpler, more robust, and safe
to pass in a flag to either count bytes (the default, for
all callers except sprintf %ls), or elements of the string
type (for sprintf %ls).

But the correct thing to count for sprintf %ls is elements of the type
expected by sprintf %ls.  That may not be the type of the string constant
(and as this is in variable arguments, there isn't any implicit conversion
to const wchar_t * like you would get with a function prototype - I'm not
sure if anything ensures this code is only reached, regardless of
language, if the argument does actually (after any casts present in the
source code) point to the correct wchar_t type).

Sure, but the only valid argument to %ls is wchar_t*.  Passing
it something else is undefined.

The only caller interested in the element count is %ls and
the only case where the function could return a result that
might be different from that of C wcslen() with the same
(invalid) argument is the undefined:

  snprintf (0, 0, "%ls", "1234");

In this case, c_strlen() would return 4 which GCC's snprintf
turns into [0, 24], and calls the libc snprintf which will
then proceed to read past the end of the narrow string and
return some bogus value (if it doesn't crash).

So I don't see a problem here(*).

In any event, my main concern isn't whether the function take
a flag or an element size as an argument.  What I believe it
needs to do is count bytes when requested even when the array
is a wide string.


PS The only problem I see is that GCC will call the library
function in this case, which we know is undefined and will
unavoidably read past the end of the argument and (if it
doesn't crash due to misalignment) return some indeterminate
value.  That's worse than any other outcome (such as folding
the call into a constant or trapping) and can easily be
prevented.  But that's a separate discussion.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]