[PATCH] manual: Update documentation of strerror and related functions

[Andreas Schwab]

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."