Re: [PATCH 1/2] strdup.3: drop mention of "the GNU GCC suite"

Alejandro Colomar (man-pages)
2021-08-24T10:40:39Z

Hi Ahelenia,

On 8/24/21 12:28 PM, наб wrote:
> Hi!
>
> On Tue, Aug 24, 2021 at 11:21:15AM +0200, Michael Kerrisk (man-pages) wrote:
>> On Mon, 23 Aug 2021 at 23:01, наб <nabijaczleweli@nabijaczleweli.xyz> wrote:
>>> ---
>>> man3/strdup.3 | 3 ---
>>> 1 file changed, 3 deletions(-)
>>>
>>> diff --git a/man3/strdup.3 b/man3/strdup.3
>>> index 1e1ac34de..963de7d48 100644
>>> --- a/man3/strdup.3
>>> +++ b/man3/strdup.3
>>> @@ -99,9 +99,6 @@ and
>>> are similar, but use
>>> .BR alloca (3)
>>> to allocate the buffer.
>>> -They are available only when using the GNU
>>> -GCC suite, and suffer from the same limitations described in
>>> -.BR alloca (3).
>>
>> Dropping mention of GCC seems reasonable, but why drop the piece about
>> "same limitations..."?
> That paragraph now reads
> strdupa() and strndupa() are similar, but use alloca(3) to allocate the buffer.
>
> I think this is short and unflowery enough that nothing more is needed
> (or, indeed, anything more would be detrimental) ‒ and clearly points to
> "see alloca(3) for the limitations of that allocator".
>
> Plus, it's not like malloc(3) doesn't have its problems, too,
> but I don't see those being touted in the first paragraph;
> reducing these to the bare minimum,
> strdup() copies into malloc(3) and you can free it with free(3),
> strndup() likewise, but up to n, and
> str[n]dupa() use alloca(3) instead ‒ be wary of what alloca(3) does!
> doesn't really make sense ‒ it's obvious that, ex definitione,
> alloca(3) suffers from alloca(3) problems and input limits,
> just like malloc(3) from the malloc(3) suite's.

That sounds convincing to me.

>
>>> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
>> This patch could do with a short commit message I think. See below.
>
> How about something like this for the message?
> str[n]dupa() are available on every modern platform, incl. Clang,
> ICC, &c.; by shortening the third paragraph, it now points squarely
> to alloca(3), which is scary enough, so drop the extraneous warning

Please break that into 2 paragraphs; I couldn't make sense of it in the
first few reads. Also, the longer explanation above also seems to me a
good part of the commit message.

Cheers,

Alex

>
> Best,
> наб
>

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/