Hi Shani, Florian,
On 2023-07-16 19:28, Shani Leviim wrote:
> Hi all,
> My previous patch wasn't aligned with the master branch.
> Here's the updated patch (compared to master):
Thanks for the patch.
Florian, do you have any comments about this patch?
>
> diff --git a/man3/strerror.3 b/man3/strerror.3
> index 862e153ee..6a3d83164 100644
> --- a/man3/strerror.3
> +++ b/man3/strerror.3
> @@ -71,11 +71,12 @@ part of the current locale to select the
> appropriate language.
> is
> .BR EINVAL ,
> the returned description will be "Invalid argument".)
> -This string must not be modified by the application, but may be
> -modified by a subsequent call to
> +This string must not be modified by the application,
> +and the returned pointer will be invalidated on a subsequent call to
> .BR strerror ()
> or
> -.BR strerror_l ().
> +.BR strerror_l (),
> +or if the thread that obtained the string exits.
> No other library function, including
> .BR perror (3),
> will modify this string.
> @@ -100,12 +101,12 @@ For example, given
> as an argument, this function returns a pointer to the string "EPERM".
> .\"
> .SS strerror_r()
> -The
> .BR strerror_r ()
> -function is similar to
> +is like
> .BR strerror (),
> -but is
> -thread safe.
> +but might use the supplied buffer
> +.I buf
> +instead of allocating one internally.
> This function is available in two versions:
> an XSI-compliant version specified in POSIX.1-2001
> (available since glibc 2.3.4, but not POSIX-compliant until glibc 2.13),
> @@ -238,7 +239,7 @@ Interface Attribute Value
> T{
> .BR strerror ()
> T} Thread safety T{
> -MT-Unsafe race:strerror
> +MT-Safe
> T}
> T{
> .BR strerrorname_np (),
> @@ -249,6 +250,10 @@ T{
> .BR strerror_l ()
> T} Thread safety MT-Safe
> .TE
> +.PP
> +Before glibc 2.32,
> +.BR strerror ()
> +is not MT-Safe.
> .hy
> .ad
> .sp 1
> @@ -292,13 +297,6 @@ to
> if the error number is unknown.
> C99 and POSIX.1-2008 require the return value to be non-NULL.
> .SH NOTES
> -The GNU C Library uses a buffer of 1024 characters for
> -.BR strerror ().
> -This buffer size therefore should be sufficient to avoid an
> -.B ERANGE
> -error when calling
> -.BR strerror_r ().
> -.PP
> .BR strerrorname_np ()
> and
> .BR strerrordesc_np ()
> @@ -309,4 +307,5 @@ are thread-safe and async-signal-safe.
> .BR error (3),
> .BR perror (3),
> .BR strsignal (3),
> -.BR locale (7)
> +.BR locale (7),
> +.BR signal-safety (7)
>
>
> Signed-off-by: Shani Leviim <sleviim@xxxxxxxxxx>
Can you please include that information in the commit message itself?
I suggest using git-format-patch(1) + git-send-email(1) to send the patch.
If git-send-email(1) is not an option for you, then I suggest adding a
copy of the patch as an attachment (but keep the inline copy please).
Check the ./CONTRIBUTING file.
Cheers,
Alex
>
> Regards,
> Shani Leviim
>
> On Thu, Jul 13, 2023 at 2:15 PM Shani Leviim <sleviim@xxxxxxxxxx> wrote:
>>
>> Thanks, Florian, for reviewing,
>> My original mail wasn't text plained, sorry for that.
>>
>> The information in my patch was obtained from a glibc upstream patch,
>> commit ID 28aff047818eb1726394296d27b9c7885340bead
>> Following the patch above, for glibc versions >=2.32, strerror() is
>> considered MT-Safe, and the man page should be changed accordingly.
>>
>> diff --git a/man3/strerror.3 b/man3/strerror.3
>> index 72b4d3994..31818e4ae 100644
>> --- a/man3/strerror.3
>> +++ b/man3/strerror.3
>> @@ -91,11 +91,12 @@ part of the current locale to select the
>> appropriate language.
>> is
>> .BR EINVAL ,
>> the returned description will be "Invalid argument".)
>> -This string must not be modified by the application, but may be
>> -modified by a subsequent call to
>> +This string must not be modified by the application,
>> +and the returned pointer will be invalidated on a subsequent call to
>> .BR strerror ()
>> or
>> -.BR strerror_l ().
>> +.BR strerror_l (),
>> +or if the thread that obtained the string exits.
>> No other library function, including
>> .BR perror (3),
>> will modify this string.
>> @@ -120,12 +121,12 @@ For example, given
>> as an argument, this function returns a pointer to the string "EPERM".
>> .\"
>> .SS strerror_r()
>> -The
>> .BR strerror_r ()
>> -function is similar to
>> +is like
>> .BR strerror (),
>> -but is
>> -thread safe.
>> +but might use the supplied buffer
>> +.I buf
>> +instead of allocating one internally.
>> This function is available in two versions:
>> an XSI-compliant version specified in POSIX.1-2001
>> (available since glibc 2.3.4, but not POSIX-compliant until glibc 2.13),
>> @@ -249,7 +250,7 @@ l l l.
>> Interface Attribute Value
>> T{
>> .BR strerror ()
>> -T} Thread safety MT-Unsafe race:strerror
>> +T} Thread safety MT-Safe
>> T{
>> .BR strerrorname_np (),
>> .BR strerrordesc_np ()
>> @@ -260,6 +261,10 @@ T{
>> .BR strerror_l ()
>> T} Thread safety MT-Safe
>> .TE
>> +.PP
>> +Before glibc 2.32,
>> +.BR strerror ()
>> +is not MT-Safe.
>> .SH CONFORMING TO
>> .BR strerror ()
>> is specified by POSIX.1-2001, POSIX.1-2008, C89, and C99.
>> @@ -300,13 +305,6 @@ to
>> if the error number is unknown.
>> C99 and POSIX.1-2008 require the return value to be non-NULL.
>> .SH NOTES
>> -The GNU C Library uses a buffer of 1024 characters for
>> -.BR strerror ().
>> -This buffer size therefore should be sufficient to avoid an
>> -.B ERANGE
>> -error when calling
>> -.BR strerror_r ().
>> -.PP
>> .BR strerrorname_np ()
>> and
>> .BR strerrordesc_np ()
>> @@ -317,4 +315,5 @@ are thread-safe and async-signal-safe.
>> .BR error (3),
>> .BR perror (3),
>> .BR strsignal (3),
>> -.BR locale (7)
>> +.BR locale (7),
>> +.BR signal-safety (7)
>>
>> Signed-off-by: Shani Leviim <sleviim@xxxxxxxxxx>
>>
>> Regards,
>> Shani Leviim
>>
>> Regards,
>> Shani Leviim
>>
>>
>> On Thu, Jul 13, 2023 at 11:12 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>>>
>>> * Shani Leviim:
>>>
>>>> @@ -169,6 +172,16 @@ is too small and
>>>> is unknown).
>>>> The string always includes a terminating null byte (\(aq\e0\(aq).
>>>> .\"
>>>> +.PP
>>>> +The automatically generated buffer for
>>>> +.BR strerror ()
>>>> +and
>>>> +.BR strerror_l ()
>>>> +is sufficient to avoid an
>>>> +.B ERANGE
>>>> +error when calling
>>>> +.BR strerror_r ().
>>>> +.PP
>>>
>>> I think this gives the wrong impression that the pointer returned by
>>> strerror/strerror_l can be used with strerror_r. This is not the case
>>> because the application does not own that buffer, or know its length.
>>>
>>> Thanks,
>>> Florian
>>>
>
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
