This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
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. Martin 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] |