[PATCH] manual: Update documentation of strerror and related functions
Andreas Schwab
schwab@suse.de
Wed Jun 21 10:57:07 GMT 2023
On Jun 21 2023, Florian Weimer wrote:
> * Andreas Schwab:
>
>> On Jun 21 2023, Florian Weimer via Libc-alpha wrote:
>>
>>> * Florian Weimer:
>>>
>>>> You should not modify the string returned by @code{strerror}. Also, if
>>>> +you make subsequent calls to @code{strerror} or @code{strerror_l}, or
>>>> +the thread that obtained the string exits, the returned pointer will be
>>>> +invalidated.
>>>
>>> I should point out that invalidation of the pointer on a subsequent
>>> strerror or strerror_l call is likely a defect because the standard does
>>> not allow this behavior.
>>
>> Doesn't the standard contain almost exactly the same wording?
>
> Not in C11, it only speaks of overwriting the string during future
> calls. POSIX says that it can be invalidated (I was confused before by
> the CX shading, which makes this difficult to read).
The new wording was added in the 2017 edition, which likely prompted the
corresponding change in C23.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
More information about the Libc-alpha
mailing list