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

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

[наб]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 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).
 .SH RETURN VALUE
 On success, the
 .BR strdup ()
-- 
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 2/2] alloca.3: rewrite NOTES

[наб]

[-- Attachment #1: Type: text/plain, Size: 3203 bytes --]

This demistifies the internals and removes outdated information
and needless glibc guts

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/alloca.3 | 66 ++++++++++++++++-----------------------------------
 1 file changed, 21 insertions(+), 45 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 5bceeabe1..133ca6ab3 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -84,20 +84,14 @@ T}	Thread safety	MT-Safe
 .SH CONFORMING TO
 This function is not in POSIX.1.
 .PP
-There is evidence that the
 .BR alloca ()
-function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD.
-There is a man page for it in 4.3BSD.
-Linux uses the GNU version.
+originates from PWB and 32V, and appears in all their derivatives.
 .SH NOTES
 The
 .BR alloca ()
 function is machine- and compiler-dependent.
-For certain applications,
-its use can improve efficiency compared to the use of
-.BR malloc (3)
-plus
-.BR free (3).
+Because it allocates from the stack, it's always faster than
+.BR malloc (3)/ free (3).
 In certain cases,
 it can also simplify memory deallocation in applications that use
 .BR longjmp (3)
@@ -125,51 +119,33 @@ Do not attempt to
 .BR free (3)
 space allocated by
 .BR alloca ()!
-.SS Notes on the GNU version
-Normally,
-.BR gcc (1)
-translates calls to
+.PP
+By necessity,
+.BR alloca ()
+is a compiler built-in, also known as
+.BR __builtin_alloca ().
+By default, modern compilers automatically translate plain
 .BR alloca ()
-with inlined code.
-This is not done when either the
+calls, but this is forbidden if
 .IR "\-ansi" ,
 .IR "\-std=c89" ,
 .IR "\-std=c99" ,
-or the
+or
 .IR "\-std=c11"
-option is given
-.BR and
-the header
-.I <alloca.h>
-is not included.
-Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
-.I <stdlib.h>
-includes
+are specified, in which case
 .I <alloca.h>
-and that contains the lines:
+is required, lest an actual symbol dependency is emitted.
 .PP
-.in +4n
-.EX
-#ifdef  __GNUC__
-#define alloca(size)   __builtin_alloca (size)
-#endif
-.EE
-.in
-.PP
-with messy consequences if one has a private version of this function.
-.PP
-The fact that the code is inlined means that it is impossible
-to take the address of this function, or to change its behavior
-by linking with a different library.
-.PP
-The inlined code often consists of a single instruction adjusting
-the stack pointer, and does not check for stack overflow.
-Thus, there is no NULL error return.
+The fact that
+.BR alloca ()
+is a built-in means it is impossible to take its address
+or to change its behavior by linking with a different library.
 .SH BUGS
-There is no error indication if the stack frame cannot be extended.
-(However, after a failed allocation, the program is likely to receive a
+As it's untestable, there is no error indication if the allocation
+would overflow the space available for the stack.
+(However, the program is likely to receive a
 .B SIGSEGV
-signal if it attempts to access the unallocated space.)
+signal if it attempts to access that space.)
 .PP
 On many systems
 .BR alloca ()
-- 
2.20.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[Michael Kerrisk (man-pages)]

Hello Ahelenia

On 8/23/21 11:01 PM, наб wrote:
> This demistifies the internals and removes outdated information
> and needless glibc guts

Some of this patch seems fine, but it does more than I would like to see
in one patch. Some comments below.

> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>  man3/alloca.3 | 66 ++++++++++++++++-----------------------------------
>  1 file changed, 21 insertions(+), 45 deletions(-)
> 
> diff --git a/man3/alloca.3 b/man3/alloca.3
> index 5bceeabe1..133ca6ab3 100644
> --- a/man3/alloca.3
> +++ b/man3/alloca.3
> @@ -84,20 +84,14 @@ T}	Thread safety	MT-Safe
>  .SH CONFORMING TO
>  This function is not in POSIX.1.
>  .PP
> -There is evidence that the
>  .BR alloca ()
> -function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD.
> -There is a man page for it in 4.3BSD.
> -Linux uses the GNU version.
> +originates from PWB and 32V, and appears in all their derivatives.

The patch subject says "rewrite NOTES", but here you change 
the CONFORMING TO. For the record, I think the change is fine;
there was too much info here that isn't really helpful.
But, I would prefer this change as a separate patch, with
a commit message that notes that the CONFORMING TO is
overly complex, so let's simplify.

>  .SH NOTES
>  The
>  .BR alloca ()
>  function is machine- and compiler-dependent.
> -For certain applications,
> -its use can improve efficiency compared to the use of
> -.BR malloc (3)
> -plus
> -.BR free (3).
> +Because it allocates from the stack, it's always faster than
> +.BR malloc (3)/ free (3).

Okay.

>  In certain cases,
>  it can also simplify memory deallocation in applications that use
>  .BR longjmp (3)
> @@ -125,51 +119,33 @@ Do not attempt to
>  .BR free (3)
>  space allocated by
>  .BR alloca ()!
> -.SS Notes on the GNU version
> -Normally,
> -.BR gcc (1)

(Removing mention of gcc makes sense...)

> -translates calls to
> +.PP
> +By necessity,
> +.BR alloca ()
> +is a compiler built-in, also known as
> +.BR __builtin_alloca ().

I'm not convinced about this change, or what follows. At the
least, it needs some explanation.

> +By default, modern compilers automatically translate plain

What does "plain" mean here? It is not explained.

>  .BR alloca ()
> -with inlined code.
> -This is not done when either the
> +calls, but this is forbidden if

Why lose the piece "with inlined code"?

And why the word "forbidden"? Who forbids it?

>  .IR "\-ansi" ,
>  .IR "\-std=c89" ,
>  .IR "\-std=c99" ,
> -or the
> +or
>  .IR "\-std=c11"

Okay.

> -option is given
> -.BR and
> -the header
> -.I <alloca.h>
> -is not included.
> -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
> -.I <stdlib.h>
> -includes
> +are specified, in which case
>  .I <alloca.h>
> -and that contains the lines:
> +is required, lest an actual symbol dependency is emitted.

(That last line seems like a useful addition!)

>  .PP
> -.in +4n
> -.EX
> -#ifdef  __GNUC__
> -#define alloca(size)   __builtin_alloca (size)
> -#endif
> -.EE
> -.in
> -.PP
> -with messy consequences if one has a private version of this function.
> -.PP
> -The fact that the code is inlined means that it is impossible
> -to take the address of this function, or to change its behavior
> -by linking with a different library.

Why remove the preceding piece? This should be clarified in the 
commit message.


> -.PP
> -The inlined code often consists of a single instruction adjusting
> -the stack pointer, and does not check for stack overflow.
> -Thus, there is no NULL error return.

Why remove the preceding piece? 

> +The fact that
> +.BR alloca ()
> +is a built-in means it is impossible to take its address
> +or to change its behavior by linking with a different library.
>  .SH BUGS
> -There is no error indication if the stack frame cannot be extended.
> -(However, after a failed allocation, the program is likely to receive a
> +As it's untestable, there is no error indication if the allocation

It's not clear to me that adding "As it's untestable," really helps 
the reader. Why do you think it does? (This should be explained in
the commit message.)

> +would overflow the space available for the stack.
> +(However, the program is likely to receive a
>  .B SIGSEGV
> -signal if it attempts to access the unallocated space.)
> +signal if it attempts to access that space.)
>  .PP
>  On many systems
>  .BR alloca ()

My feelings about this patch:

* There's good stuff here, and stuff that I am less sure of.
* This should be *at least* 2 patches, but possibly 3 or 4.
* We need some meaningful commit messages. Your two line commit
  message is too vague; think of people some years from now
  looking at these changes, and asking: "what was the author's
  motivation for these changes?"

Would you be willing to rework this patch in the light of 
the above please? Breaking it into a few pieces (if you can)
would make it much easier to wave some pieces through and
discuss the other pieces in detail.

Thanks,

Michael

 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

At 2021-08-24T11:50:57+0200, Michael Kerrisk (man-pages) wrote:
> On 8/23/21 11:01 PM, наб wrote:
> > -option is given
> > -.BR and
> > -the header
> > -.I <alloca.h>
> > -is not included.
> > -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
> > -.I <stdlib.h>
> > -includes
> > +are specified, in which case
> >  .I <alloca.h>
> > -and that contains the lines:
> > +is required, lest an actual symbol dependency is emitted.
> 
> (That last line seems like a useful addition!)

I agree, but I note that the verb should be in the subjunctive mood.
Also, is the word "actual" doing any work here?  If <alloca.h> is
omitted, does some kind of virtual dependency or weak reference end up
in the object file (I'm not an ELF wizard).  If so, perhaps the nature
of that symbol should be explicitly identified.

Thus:

[[
	is required, lest a symbol dependency be emitted.
]]


Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[наб]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

On Tue, Aug 24, 2021 at 08:04:46PM +1000, G. Branden Robinson wrote:
> At 2021-08-24T11:50:57+0200, Michael Kerrisk (man-pages) wrote:
> > On 8/23/21 11:01 PM, наб wrote:
> > > -option is given
> > > -.BR and
> > > -the header
> > > -.I <alloca.h>
> > > -is not included.
> > > -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
> > > -.I <stdlib.h>
> > > -includes
> > > +are specified, in which case
> > >  .I <alloca.h>
> > > -and that contains the lines:
> > > +is required, lest an actual symbol dependency is emitted.
> > (That last line seems like a useful addition!)
> I agree, but I note that the verb should be in the subjunctive mood.
Not a clue what this means, but the "is" should be "be", I do agree.

> Also, is the word "actual" doing any work here?
Dunno; without standards conformance (-ansi, -std=c*) alloca() is a
magical identifier, in that, if you compile this:
-- >8 --
extern void * alloca(unsigned long s);
int main() {
	alloca(20);
	puts("200");
}
-- >8 --

You get
-- >8 --
nabijaczleweli@tarta:~/uwu$ cc a.c -oa.o -c
a.c:4:2: warning: implicit declaration of function 'puts' is invalid in C99 [-Wimplicit-function-declaration]
        puts("200");
        ^
1 warning generated.
nabijaczleweli@tarta:~/uwu$ readelf -s a.o

Symbol table '.symtab' contains 6 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS a.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
     4: 0000000000000000    33 FUNC    GLOBAL DEFAULT    2 main
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND puts
-- >8 --
and if you drop the -c, it will link, run, and print "200".

If you do request standards conformance, however,
-- >8 --
nabijaczleweli@tarta:~/uwu$ cc a.c -oa.o -c -std=c18
a.c:4:2: warning: implicit declaration of function 'puts' is invalid in C99 [-Wimplicit-function-declaration]
        puts("200");
        ^
1 warning generated.
nabijaczleweli@tarta:~/uwu$ readelf -s a.o

Symbol table '.symtab' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS a.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
     4: 0000000000000000    35 FUNC    GLOBAL DEFAULT    2 main
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND alloca
     6: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND puts
-- >8 --
and, trivially,
-- >8 --
nabijaczleweli@tarta:~/uwu$ cc a.c -oa -std=c18
a.c:4:2: warning: implicit declaration of function 'puts' is invalid in C99 [-Wimplicit-function-declaration]
        puts("200");
        ^
1 warning generated.
/bin/ld: /tmp/a-935faa.o: in function `main':
a.c:(.text+0xa): undefined reference to `alloca'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
-- >8 --

C compilers are fully allowed to do magic, and this is some of this
magic: unless in ISO mode, it's impossible to ODR-use alloca().

> Thus:
> [[
> 	is required, lest a symbol dependency be emitted.
> ]]
Sure.

Best,
наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[Alejandro Colomar (man-pages)]

Hello Ahelenia, (do you prefer наб or Ahelenia?  What does наб mean, if 
I may ask? :)

On 8/24/21 11:50 AM, Michael Kerrisk (man-pages) wrote:
> Hello Ahelenia
> 
> On 8/23/21 11:01 PM, наб wrote:
>> This demistifies the internals and removes outdated information
>> and needless glibc guts
> 
> Some of this patch seems fine, but it does more than I would like to see
> in one patch. Some comments below.
> 
>> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

Thanks for the patch!

Most of it looks good.  But as Michael said, it would be better to split 
this into small patches that change 1 thing.

And apart from what Michael (and Branden) already said, I have one 
question that has not been treated before it seems:

AFAIK, VLAs are 100% equivalent to alloca() (except for the obvious 
syntax differences).  And considering the VLA syntax is much nicer than 
alloca(), and is in the standard (IIRC, C99 added VLAs, and C11 declared 
them optional), what about adding a NOTES subsection that recommends (or 
at least mentions) VLAs?

And they both share the problem of smashing the stack if you try to 
allocate an array to big (and none of them has a way to check if it will 
happen, AFAIK).

Cheers,

Alex

>> ---
>>   man3/alloca.3 | 66 ++++++++++++++++-----------------------------------
>>   1 file changed, 21 insertions(+), 45 deletions(-)
>>
>> diff --git a/man3/alloca.3 b/man3/alloca.3
>> index 5bceeabe1..133ca6ab3 100644
>> --- a/man3/alloca.3
>> +++ b/man3/alloca.3
>> @@ -84,20 +84,14 @@ T}	Thread safety	MT-Safe
>>   .SH CONFORMING TO
>>   This function is not in POSIX.1.
>>   .PP
>> -There is evidence that the
>>   .BR alloca ()
>> -function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD.
>> -There is a man page for it in 4.3BSD.
>> -Linux uses the GNU version.
>> +originates from PWB and 32V, and appears in all their derivatives.
> 
> The patch subject says "rewrite NOTES", but here you change
> the CONFORMING TO. For the record, I think the change is fine;
> there was too much info here that isn't really helpful.
> But, I would prefer this change as a separate patch, with
> a commit message that notes that the CONFORMING TO is
> overly complex, so let's simplify.
> 
>>   .SH NOTES
>>   The
>>   .BR alloca ()
>>   function is machine- and compiler-dependent.
>> -For certain applications,
>> -its use can improve efficiency compared to the use of
>> -.BR malloc (3)
>> -plus
>> -.BR free (3).
>> +Because it allocates from the stack, it's always faster than

Minor wording question:

Do we really need _always_ for emphasis?  I think it would be the same 
without that word.

>> +.BR malloc (3)/ free (3).
> 
> Okay.
> 
>>   In certain cases,
>>   it can also simplify memory deallocation in applications that use
>>   .BR longjmp (3)
>> @@ -125,51 +119,33 @@ Do not attempt to
>>   .BR free (3)
>>   space allocated by
>>   .BR alloca ()!
>> -.SS Notes on the GNU version
>> -Normally,
>> -.BR gcc (1)
> 
> (Removing mention of gcc makes sense...)
> 
>> -translates calls to
>> +.PP
>> +By necessity,
>> +.BR alloca ()
>> +is a compiler built-in, also known as
>> +.BR __builtin_alloca ().
> 
> I'm not convinced about this change, or what follows. At the
> least, it needs some explanation.
> 
>> +By default, modern compilers automatically translate plain
> 
> What does "plain" mean here? It is not explained.
> 
>>   .BR alloca ()
>> -with inlined code.
>> -This is not done when either the
>> +calls, but this is forbidden if
> 
> Why lose the piece "with inlined code"?
> 
> And why the word "forbidden"? Who forbids it?
> 
>>   .IR "\-ansi" ,
>>   .IR "\-std=c89" ,
>>   .IR "\-std=c99" ,
>> -or the
>> +or
>>   .IR "\-std=c11"
> 
> Okay.
> 
>> -option is given
>> -.BR and
>> -the header
>> -.I <alloca.h>
>> -is not included.
>> -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
>> -.I <stdlib.h>
>> -includes
>> +are specified, in which case
>>   .I <alloca.h>
>> -and that contains the lines:
>> +is required, lest an actual symbol dependency is emitted.
> 
> (That last line seems like a useful addition!)
> 
>>   .PP
>> -.in +4n
>> -.EX
>> -#ifdef  __GNUC__
>> -#define alloca(size)   __builtin_alloca (size)
>> -#endif
>> -.EE
>> -.in
>> -.PP
>> -with messy consequences if one has a private version of this function.
>> -.PP
>> -The fact that the code is inlined means that it is impossible
>> -to take the address of this function, or to change its behavior
>> -by linking with a different library.
> 
> Why remove the preceding piece? This should be clarified in the
> commit message.
> 
> 
>> -.PP
>> -The inlined code often consists of a single instruction adjusting
>> -the stack pointer, and does not check for stack overflow.
>> -Thus, there is no NULL error return.
> 
> Why remove the preceding piece?
> 
>> +The fact that
>> +.BR alloca ()
>> +is a built-in means it is impossible to take its address
>> +or to change its behavior by linking with a different library.
>>   .SH BUGS
>> -There is no error indication if the stack frame cannot be extended.
>> -(However, after a failed allocation, the program is likely to receive a
>> +As it's untestable, there is no error indication if the allocation
> 
> It's not clear to me that adding "As it's untestable," really helps
> the reader. Why do you think it does? (This should be explained in
> the commit message.)
> 
>> +would overflow the space available for the stack.
>> +(However, the program is likely to receive a
>>   .B SIGSEGV
>> -signal if it attempts to access the unallocated space.)
>> +signal if it attempts to access that space.)
>>   .PP
>>   On many systems
>>   .BR alloca ()
> 
> My feelings about this patch:
> 
> * There's good stuff here, and stuff that I am less sure of.
> * This should be *at least* 2 patches, but possibly 3 or 4.
> * We need some meaningful commit messages. Your two line commit
>    message is too vague; think of people some years from now
>    looking at these changes, and asking: "what was the author's
>    motivation for these changes?"
> 
> Would you be willing to rework this patch in the light of
> the above please? Breaking it into a few pieces (if you can)
> would make it much easier to wave some pieces through and
> discuss the other pieces in detail.
> 
> Thanks,
> 
> Michael
> 
>   
> 
> 


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

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[Alejandro Colomar (man-pages)]

Hi, Ahelenia!

On 8/24/21 12:33 PM, Alejandro Colomar (man-pages) wrote:
> 
> And apart from what Michael (and Branden) already said, I have one 
> question that has not been treated before it seems:
> 
> AFAIK, VLAs are 100% equivalent to alloca() (except for the obvious 
> syntax differences).  And considering the VLA syntax is much nicer than 
> alloca(), and is in the standard (IIRC, C99 added VLAs, and C11 declared 
> them optional), what about adding a NOTES subsection that recommends (or 
> at least mentions) VLAs?
> 
> And they both share the problem of smashing the stack if you try to 
> allocate an array to big (and none of them has a way to check if it will 
> happen, AFAIK).

Now that I think, there's a slight difference, of course:  VLAs live in 
their block scope, while alloca() lives in the function scope, allowing 
to embed it in a macro such as strdupa().

But maybe still worth mentioning VLAs in alloca(3).

Cheers,

Alex


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

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[наб]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

On Tue, Aug 24, 2021 at 12:33:56PM +0200, Alejandro Colomar (man-pages) wrote:
> Hello Ahelenia, (do you prefer наб or Ahelenia?  What does наб mean, if I
> may ask? :)
Either works, prefer former, but this is neither the time nor the place
for nomenclatural epistemology.

> AFAIK, VLAs are 100% equivalent to alloca() (except for the obvious syntax
> differences).  And considering the VLA syntax is much nicer than alloca(),
> and is in the standard (IIRC, C99 added VLAs, and C11 declared them
> optional), what about adding a NOTES subsection that recommends (or at least
> mentions) VLAs?
> 
> And they both share the problem of smashing the stack if you try to allocate
> an array to big (and none of them has a way to check if it will happen,
> AFAIK).
Well, the fundamental difference is that VLAs are arrays of objects with
odd semantics and alloca() (a) has an allocator-like interface and
(b) returns uninitialised memory, that, as you note in your second mail,
(c) escapes into a larger (function) scope.

Plus, I've usually found VLAs to be used by accident because something
in the array dimension wasn't as constexpr as expected (the macros
surrounding unix(7) SCM_RIGHTS on Darwin come to mind, try explaining
that to a conformant C++ compiler), while alloca() makes
the potentially-unbounded allocation obvious (and portable).

That being said, you do have a point, I'll mention VLAs in v2.

Best,
наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] alloca.3: rewrite NOTES

[наб]

[-- Attachment #1: Type: text/plain, Size: 5496 bytes --]

Hi!

On Tue, Aug 24, 2021 at 11:50:57AM +0200, Michael Kerrisk (man-pages) wrote:
> On 8/23/21 11:01 PM, наб wrote:
> > Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> > ---
> >  man3/alloca.3 | 66 ++++++++++++++++-----------------------------------
> >  1 file changed, 21 insertions(+), 45 deletions(-)
> > 
> > diff --git a/man3/alloca.3 b/man3/alloca.3
> > index 5bceeabe1..133ca6ab3 100644
> > --- a/man3/alloca.3
> > +++ b/man3/alloca.3
> > @@ -84,20 +84,14 @@ T}	Thread safety	MT-Safe
> >  .SH CONFORMING TO
> >  This function is not in POSIX.1.
> >  .PP
> > -There is evidence that the
> >  .BR alloca ()
> > -function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD.
> > -There is a man page for it in 4.3BSD.
> > -Linux uses the GNU version.
> > +originates from PWB and 32V, and appears in all their derivatives.
> The patch subject says "rewrite NOTES", but here you change 
> the CONFORMING TO. For the record, I think the change is fine;
> there was too much info here that isn't really helpful.
> But, I would prefer this change as a separate patch, with
> a commit message that notes that the CONFORMING TO is
> overly complex, so let's simplify.
Will do.

> > -translates calls to
> > +.PP
> > +By necessity,
> > +.BR alloca ()
> > +is a compiler built-in, also known as
> > +.BR __builtin_alloca ().
> I'm not convinced about this change, or what follows. At the
> least, it needs some explanation.
How'd you mean? I think I'm missing what there's to be explained
in this particular hunk.

> > +By default, modern compilers automatically translate plain
> What does "plain" mean here? It is not explained.
How about "By default, modern compilers automatically translate all
uses of alloca() into the built-in, but this is forbidden if..."?
 
> >  .BR alloca ()
> > -with inlined code.
> > -This is not done when either the
> > +calls, but this is forbidden if
> Why lose the piece "with inlined code"?
Because... it isn't inlined code (indeed, code at all)?
It's an intrinsic. If you don't include alloca.h, aliasing alloca() to
__builtin_alloca() is also 100% magic.

PWB and 32V do actually implement this as a libc function and raze the
stack frame (PWB even pre-emptively crashes, as a feature, if it OOMed),
but those days are long gone.

> And why the word "forbidden"? Who forbids it?
The standards that are outlined in the following seven words.

> >  .IR "\-ansi" ,
> >  .IR "\-std=c89" ,
> >  .IR "\-std=c99" ,
> > -or the
> > +or
> >  .IR "\-std=c11"
> Okay.

> >  .PP
> > -.in +4n
> > -.EX
> > -#ifdef  __GNUC__
> > -#define alloca(size)   __builtin_alloca (size)
> > -#endif
> > -.EE
> > -.in
> > -.PP
> > -with messy consequences if one has a private version of this function.
> > -.PP
> > -The fact that the code is inlined means that it is impossible
> > -to take the address of this function, or to change its behavior
> > -by linking with a different library.
> Why remove the preceding piece? This should be clarified in the 
> commit message.
The first bit is glibc guts, and has no place in documentation of
alloca(3) as an interface ‒ this is noted.

The latter paragraph just moved down.

> > -.PP
> > -The inlined code often consists of a single instruction adjusting
> > -the stack pointer, and does not check for stack overflow.
> > -Thus, there is no NULL error return.
> Why remove the preceding piece? 
Because there /is/ no code, inlined or otherwise. The stack pointer or
lack thereof is beside this point, and the rest of this paragraph
lives in the hunk below.

> > +The fact that
> > +.BR alloca ()
> > +is a built-in means it is impossible to take its address
> > +or to change its behavior by linking with a different library.
> >  .SH BUGS
> > -There is no error indication if the stack frame cannot be extended.
> > -(However, after a failed allocation, the program is likely to receive a
> > +As it's untestable, there is no error indication if the allocation
> It's not clear to me that adding "As it's untestable," really helps 
> the reader. Why do you think it does? (This should be explained in
> the commit message.)
I kept it from the hunk you outlined above, I can drop it, but it is an
important difference from most regular allocators, which are able to
detect an OOM condition. By definition, you have stack until you hit an
unmapped or non-R/W-mapped page. How about something like
"Due to the nature of the stack, there is ..."?

> My feelings about this patch:
> * There's good stuff here, and stuff that I am less sure of.
> * This should be *at least* 2 patches, but possibly 3 or 4.
> * We need some meaningful commit messages. Your two line commit
>   message is too vague; think of people some years from now
>   looking at these changes, and asking: "what was the author's
>   motivation for these changes?"
> 
> Would you be willing to rework this patch in the light of 
> the above please? Breaking it into a few pieces (if you can)
> would make it much easier to wave some pieces through and
> discuss the other pieces in detail.
The CONFORMING TO split is trivial, but I hardly see a good cleave line
for anything beside it. If we can arrive at a consensus on some of the
bits you found problematic in this version, I'll split it two-fold and
resend with the new wording and commit message, then we can cleave it
further if you'd like?

Best,
наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael Kerrisk (man-pages)]

Hello Ahelenia,

On Mon, 23 Aug 2021 at 23:01, наб <nabijaczleweli@nabijaczleweli.xyz> wrote:
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

This patch could do with a short commit message I think. See below.

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

Thanks,

Michael

>  .SH RETURN VALUE
>  On success, the
>  .BR strdup ()
> --
> 2.20.1
>


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

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

[наб]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

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.

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

Best,
наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar (man-pages)]

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/
http://www.alejandro-colomar.es/

[PATCH v2 0/5] alloca(3) commentary re-write

[наб]

[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]

Hi!

This again, I think I cracked it into sensible chunks (see below)
and addressed most-all reviews (reviewers CC:d).

I also reduced the overly-verbose flag list (which was already missing
-std=c18) to "standards conformance (-ansi, -std=c*)", added a VLA
paragraph, and elucidated on the commit messages (#1 even has references
and everything).

наб (5):
  strdup.3: drop mention of "the GNU GCC suite"
  alloca.3: clarify origins in CONFORMING TO
  alloca.3: clarify reasoning for no error return in BUGS
  alloca.3: remove GCC faffling from NOTES
  alloca.3: simplfy malloc(3) suite comparison, note VLAs

 man3/alloca.3 | 76 +++++++++++++++++++--------------------------------
 man3/strdup.3 |  3 --
 2 files changed, 28 insertions(+), 51 deletions(-)

Interdiff against v1:
diff --git a/man3/alloca.3 b/man3/alloca.3
index 133ca6ab3..736182a7d 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -90,7 +90,7 @@ originates from PWB and 32V, and appears in all their derivatives.
 The
 .BR alloca ()
 function is machine- and compiler-dependent.
-Because it allocates from the stack, it's always faster than
+Because it allocates from the stack, it's faster than
 .BR malloc (3)/ free (3).
 In certain cases,
 it can also simplify memory deallocation in applications that use
@@ -124,28 +124,32 @@ By necessity,
 .BR alloca ()
 is a compiler built-in, also known as
 .BR __builtin_alloca ().
-By default, modern compilers automatically translate plain
+By default, modern compilers automatically translate all uses of
 .BR alloca ()
-calls, but this is forbidden if
-.IR "\-ansi" ,
-.IR "\-std=c89" ,
-.IR "\-std=c99" ,
-or
-.IR "\-std=c11"
-are specified, in which case
+into the built-in, but this is forbidden if standards conformance is requested
+.RI ( "\-ansi" ,
+.IR "\-std=c*" ),
+in which case
 .I <alloca.h>
-is required, lest an actual symbol dependency is emitted.
+is required, lest a symbol dependency be emitted.
 .PP
 The fact that
 .BR alloca ()
 is a built-in means it is impossible to take its address
 or to change its behavior by linking with a different library.
+.PP
+Variable length arrays (VLAs) are part of the C99 standard,
+optional since C11, and can be used for a similar purpose.
+However, they do not port to standard C++, and, being variables,
+live in their block scope and don't have an allocator-like interface,
+making them unfit for implementing functionality like
+.BR strdupa (3).
 .SH BUGS
-As it's untestable, there is no error indication if the allocation
-would overflow the space available for the stack.
+Due to the nature of the stack, it is impossible to check if the allocation
+would overflow the space available, and, hence, neither is indicating an error.
 (However, the program is likely to receive a
 .B SIGSEGV
-signal if it attempts to access that space.)
+signal if it attempts to access unavailable space.)
 .PP
 On many systems
 .BR alloca ()
-- 
2.20.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[наб]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

str[n]dupa() are available on every modern compiler platform,
incl. Clang, ICC, &c.

By shortening the third paragraph, it now reads
    strdupa() and strndupa() are similar,
    but use alloca(3) to allocate the buffer.
pointing squarely to alloca(3), which is scary enough,
so drop the extraneous warning, too ‒ athis 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.

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 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).
 .SH RETURN VALUE
 On success, the
 .BR strdup ()
-- 
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar (man-pages)]

On 9/14/21 2:40 PM, наб wrote:
> str[n]dupa() are available on every modern compiler platform,
> incl. Clang, ICC, &c.
> 
> By shortening the third paragraph, it now reads
>      strdupa() and strndupa() are similar,
>      but use alloca(3) to allocate the buffer.
> pointing squarely to alloca(3), which is scary enough,
> so drop the extraneous warning, too ‒ athis clearly points to

(I fixed s/athis/this/)

> "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.
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

наб, patch applied!

Thanks,

Alex

> ---
>   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).
>   .SH RETURN VALUE
>   On success, the
>   .BR strdup ()
> 


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

[PATCH v2 2/5] alloca.3: clarify origins in CONFORMING TO

[наб]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

alloca() is supported by PWB/UNIX[1] (V6) and UNIX/32V[2] (V7),
for the PDP-11 and VAX, respectively; the former trickles into
UNIX System III[3], and the latter into 3BSD[4] and later[5]

1: https://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/USDL/spencer_pwb.tar.gz
   sys/source/s4/util/alloca.s
2: https://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/USDL/32V/32v_usr.tar.gz
   usr/src/libc/sys/alloca.s
3: https://vetusware.com/download/UNIX%20System%20III%20Source%20Code%20SYSIII/?id=11576
4: https://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/UCB/
5: https://archive.org/details/The_CSRG_Archives_CD-ROM_3_August_1998_Marshall_Kirk_McKusick

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/alloca.3 | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 5bceeabe1..71348e609 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -84,11 +84,8 @@ T}	Thread safety	MT-Safe
 .SH CONFORMING TO
 This function is not in POSIX.1.
 .PP
-There is evidence that the
 .BR alloca ()
-function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD.
-There is a man page for it in 4.3BSD.
-Linux uses the GNU version.
+originates from PWB and 32V, and appears in all their derivatives.
 .SH NOTES
 The
 .BR alloca ()
-- 
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/5] alloca.3: clarify origins in CONFORMING TO

[Alejandro Colomar (man-pages)]

On 9/14/21 2:41 PM, наб wrote:
> alloca() is supported by PWB/UNIX[1] (V6) and UNIX/32V[2] (V7),
> for the PDP-11 and VAX, respectively; the former trickles into
> UNIX System III[3], and the latter into 3BSD[4] and later[5]
> 
> 1: https://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/USDL/spencer_pwb.tar.gz
>     sys/source/s4/util/alloca.s
> 2: https://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/USDL/32V/32v_usr.tar.gz
>     usr/src/libc/sys/alloca.s
> 3: https://vetusware.com/download/UNIX%20System%20III%20Source%20Code%20SYSIII/?id=11576
> 4: https://ftp.okass.net/pub/mirror/minnie.tuhs.org/Distributions/UCB/
> 5: https://archive.org/details/The_CSRG_Archives_CD-ROM_3_August_1998_Marshall_Kirk_McKusick
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

наб, patch applied!

Cheers,

Alex

> ---
>   man3/alloca.3 | 5 +----
>   1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/man3/alloca.3 b/man3/alloca.3
> index 5bceeabe1..71348e609 100644
> --- a/man3/alloca.3
> +++ b/man3/alloca.3
> @@ -84,11 +84,8 @@ T}	Thread safety	MT-Safe
>   .SH CONFORMING TO
>   This function is not in POSIX.1.
>   .PP
> -There is evidence that the
>   .BR alloca ()
> -function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD.
> -There is a man page for it in 4.3BSD.
> -Linux uses the GNU version.
> +originates from PWB and 32V, and appears in all their derivatives.
>   .SH NOTES
>   The
>   .BR alloca ()
> 


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

[PATCH v2 3/5] alloca.3: clarify reasoning for no error return in BUGS

[наб]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

A stack lasts from some high point until it runs off the back
of the pages allocated, making detecting errors impossible,
save for actually trying to access said unallocated page

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/alloca.3 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 71348e609..20761b079 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -163,10 +163,11 @@ The inlined code often consists of a single instruction adjusting
 the stack pointer, and does not check for stack overflow.
 Thus, there is no NULL error return.
 .SH BUGS
-There is no error indication if the stack frame cannot be extended.
-(However, after a failed allocation, the program is likely to receive a
+Due to the nature of the stack, it is impossible to check if the allocation
+would overflow the space available, and, hence, neither is indicating an error.
+(However, the program is likely to receive a
 .B SIGSEGV
-signal if it attempts to access the unallocated space.)
+signal if it attempts to access unavailable space.)
 .PP
 On many systems
 .BR alloca ()
-- 
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/5] alloca.3: clarify reasoning for no error return in BUGS

[Alejandro Colomar (man-pages)]

Hi, наб!

On 9/14/21 2:41 PM, наб wrote:
> A stack lasts from some high point until it runs off the back
> of the pages allocated, making detecting errors impossible,
> save for actually trying to access said unallocated page
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>   man3/alloca.3 | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/man3/alloca.3 b/man3/alloca.3
> index 71348e609..20761b079 100644
> --- a/man3/alloca.3
> +++ b/man3/alloca.3
> @@ -163,10 +163,11 @@ The inlined code often consists of a single instruction adjusting
>   the stack pointer, and does not check for stack overflow.
>   Thus, there is no NULL error return.
>   .SH BUGS
> -There is no error indication if the stack frame cannot be extended.
> -(However, after a failed allocation, the program is likely to receive a
> +Due to the nature of the stack, it is impossible to check if the allocation
> +would overflow the space available, and, hence, neither is indicating an error.

I'm not sure this use of neither (without a preceding "not") is valid 
English.  Is it?

Cheers,

Alex

> +(However, the program is likely to receive a
>   .B SIGSEGV
> -signal if it attempts to access the unallocated space.)
> +signal if it attempts to access unavailable space.)
>   .PP
>   On many systems
>   .BR alloca ()
> 


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

Re: [PATCH v2 3/5] alloca.3: clarify reasoning for no error return in BUGS

[наб]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Wed, Sep 15, 2021 at 09:42:26PM +0200, Alejandro Colomar (man-pages) wrote:
> On 9/14/21 2:41 PM, наб wrote:
> > diff --git a/man3/alloca.3 b/man3/alloca.3
> > index 71348e609..20761b079 100644
> > --- a/man3/alloca.3
> > +++ b/man3/alloca.3
> > -There is no error indication if the stack frame cannot be extended.
> > -(However, after a failed allocation, the program is likely to receive a
> > +Due to the nature of the stack, it is impossible to check if the allocation
> > +would overflow the space available, and, hence, neither is indicating an error.
> I'm not sure this use of neither (without a preceding "not") is valid
> English.  Is it?
I don't see why not: "impossible" provides the first negation
(the "not" is lives in the "in-" prefix
 (well, "im-" because it's before a bilabial plosive),
 and "neither" is in its "likewise not" adverbial use).

наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2 4/5] alloca.3: remove GCC faffling from NOTES

[наб]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

Chunks of glibc headers have no place in documenting an interface,
and (__builtin_)alloca() is an intrinsic, not code; those days are,
thankfully, long gone

Also, clarify standards behaviour (and remove the (outdated!)
list of cc(1) switches) regarding when alloca() is allowed to not be
ODR-usable

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/alloca.3 | 52 +++++++++++++++------------------------------------
 1 file changed, 15 insertions(+), 37 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 20761b079..936a15954 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -122,46 +122,24 @@ Do not attempt to
 .BR free (3)
 space allocated by
 .BR alloca ()!
-.SS Notes on the GNU version
-Normally,
-.BR gcc (1)
-translates calls to
+.PP
+By necessity,
 .BR alloca ()
-with inlined code.
-This is not done when either the
-.IR "\-ansi" ,
-.IR "\-std=c89" ,
-.IR "\-std=c99" ,
-or the
-.IR "\-std=c11"
-option is given
-.BR and
-the header
-.I <alloca.h>
-is not included.
-Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
-.I <stdlib.h>
-includes
+is a compiler built-in, also known as
+.BR __builtin_alloca ().
+By default, modern compilers automatically translate all uses of
+.BR alloca ()
+into the built-in, but this is forbidden if standards conformance is requested
+.RI ( "\-ansi" ,
+.IR "\-std=c*" ),
+in which case
 .I <alloca.h>
-and that contains the lines:
-.PP
-.in +4n
-.EX
-#ifdef  __GNUC__
-#define alloca(size)   __builtin_alloca (size)
-#endif
-.EE
-.in
+is required, lest a symbol dependency be emitted.
 .PP
-with messy consequences if one has a private version of this function.
-.PP
-The fact that the code is inlined means that it is impossible
-to take the address of this function, or to change its behavior
-by linking with a different library.
-.PP
-The inlined code often consists of a single instruction adjusting
-the stack pointer, and does not check for stack overflow.
-Thus, there is no NULL error return.
+The fact that
+.BR alloca ()
+is a built-in means it is impossible to take its address
+or to change its behavior by linking with a different library.
 .SH BUGS
 Due to the nature of the stack, it is impossible to check if the allocation
 would overflow the space available, and, hence, neither is indicating an error.
-- 
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 4/5] alloca.3: remove GCC faffling from NOTES

[Alejandro Colomar (man-pages)]

Hi, наб!

On 9/14/21 2:41 PM, наб wrote:
[...]
> +is required, lest a symbol dependency be emitted.

Sorry that I'm not a native English speaker.  I tried to learn what 
"lest" means, but it's difficult to me, and I'm not sure I understand 
this line.  Could you maybe please reword it?  :)

Thanks,

Alex


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

Re: [PATCH v2 4/5] alloca.3: remove GCC faffling from NOTES

[наб]

[-- Attachment #1: Type: text/plain, Size: 3079 bytes --]

On Wed, Sep 15, 2021 at 09:48:14PM +0200, Alejandro Colomar (man-pages) wrote:
> On 9/14/21 2:41 PM, наб wrote:
> [...]
> > +is required, lest a symbol dependency be emitted.
> Sorry that I'm not a native English speaker.  I tried to learn what "lest"
> means, but it's difficult to me, and I'm not sure I understand this line.
> Could you maybe please reword it?  :)

I stand by the "lest" version because it gets less noodly,
but rewritten as "in which case a symbol dependency will be emitted
unless <alloca.h> is included", see updated scissor-patch below.

And, well, neither am I, but that's hardly here or there.

-- >8 --
Chunks of glibc headers have no place in documenting an interface,
and (__builtin_)alloca() is an intrinsic, not code; those days are,
thankfully, long gone

Also, clarify standards behaviour (and remove the (outdated!)
list of cc(1) switches) regarding when alloca() is allowed to not be
ODR-usable

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/alloca.3 | 52 +++++++++++++++------------------------------------
 1 file changed, 15 insertions(+), 37 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 20761b079..913cbe56a 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -122,46 +122,24 @@ Do not attempt to
 .BR free (3)
 space allocated by
 .BR alloca ()!
-.SS Notes on the GNU version
-Normally,
-.BR gcc (1)
-translates calls to
+.PP
+By necessity,
 .BR alloca ()
-with inlined code.
-This is not done when either the
-.IR "\-ansi" ,
-.IR "\-std=c89" ,
-.IR "\-std=c99" ,
-or the
-.IR "\-std=c11"
-option is given
-.BR and
-the header
-.I <alloca.h>
-is not included.
-Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
-.I <stdlib.h>
-includes
+is a compiler built-in, also known as
+.BR __builtin_alloca ().
+By default, modern compilers automatically translate all uses of
+.BR alloca ()
+into the built-in, but this is forbidden if standards conformance is requested
+.RI ( "\-ansi" ,
+.IR "\-std=c*" ),
+in which case a symbol dependency will be emitted unless
 .I <alloca.h>
-and that contains the lines:
-.PP
-.in +4n
-.EX
-#ifdef  __GNUC__
-#define alloca(size)   __builtin_alloca (size)
-#endif
-.EE
-.in
+is included.
 .PP
-with messy consequences if one has a private version of this function.
-.PP
-The fact that the code is inlined means that it is impossible
-to take the address of this function, or to change its behavior
-by linking with a different library.
-.PP
-The inlined code often consists of a single instruction adjusting
-the stack pointer, and does not check for stack overflow.
-Thus, there is no NULL error return.
+The fact that
+.BR alloca ()
+is a built-in means it is impossible to take its address
+or to change its behavior by linking with a different library.
 .SH BUGS
 Due to the nature of the stack, it is impossible to check if the allocation
 would overflow the space available, and, hence, neither is indicating an error.
-- 
2.20.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 4/5] alloca.3: remove GCC faffling from NOTES

[Alejandro Colomar (man-pages)]

Hi наб,

On 9/17/21 10:45 PM, наб wrote:
> On Wed, Sep 15, 2021 at 09:48:14PM +0200, Alejandro Colomar (man-pages) wrote:
>> On 9/14/21 2:41 PM, наб wrote:
>> [...]
>>> +is required, lest a symbol dependency be emitted.
>> Sorry that I'm not a native English speaker.  I tried to learn what "lest"
>> means, but it's difficult to me, and I'm not sure I understand this line.
>> Could you maybe please reword it?  :)
> 
> I stand by the "lest" version because it gets less noodly,
> but rewritten as "in which case a symbol dependency will be emitted
> unless <alloca.h> is included", see updated scissor-patch below.


Hmm, the wording with 'lest' seems more precise, now that I learnt what 
it means.  I applied the first version.  I also applied the rest of the 
patches in this set (v1).

Thanks,

Alex

> 
> And, well, neither am I, but that's hardly here or there.
> 
> -- >8 --
> Chunks of glibc headers have no place in documenting an interface,
> and (__builtin_)alloca() is an intrinsic, not code; those days are,
> thankfully, long gone
> 
> Also, clarify standards behaviour (and remove the (outdated!)
> list of cc(1) switches) regarding when alloca() is allowed to not be
> ODR-usable
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>   man3/alloca.3 | 52 +++++++++++++++------------------------------------
>   1 file changed, 15 insertions(+), 37 deletions(-)
> 
> diff --git a/man3/alloca.3 b/man3/alloca.3
> index 20761b079..913cbe56a 100644
> --- a/man3/alloca.3
> +++ b/man3/alloca.3
> @@ -122,46 +122,24 @@ Do not attempt to
>   .BR free (3)
>   space allocated by
>   .BR alloca ()!
> -.SS Notes on the GNU version
> -Normally,
> -.BR gcc (1)
> -translates calls to
> +.PP
> +By necessity,
>   .BR alloca ()
> -with inlined code.
> -This is not done when either the
> -.IR "\-ansi" ,
> -.IR "\-std=c89" ,
> -.IR "\-std=c99" ,
> -or the
> -.IR "\-std=c11"
> -option is given
> -.BR and
> -the header
> -.I <alloca.h>
> -is not included.
> -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
> -.I <stdlib.h>
> -includes
> +is a compiler built-in, also known as
> +.BR __builtin_alloca ().
> +By default, modern compilers automatically translate all uses of
> +.BR alloca ()
> +into the built-in, but this is forbidden if standards conformance is requested
> +.RI ( "\-ansi" ,
> +.IR "\-std=c*" ),
> +in which case a symbol dependency will be emitted unless
>   .I <alloca.h>
> -and that contains the lines:
> -.PP
> -.in +4n
> -.EX
> -#ifdef  __GNUC__
> -#define alloca(size)   __builtin_alloca (size)
> -#endif
> -.EE
> -.in
> +is included.
>   .PP
> -with messy consequences if one has a private version of this function.
> -.PP
> -The fact that the code is inlined means that it is impossible
> -to take the address of this function, or to change its behavior
> -by linking with a different library.
> -.PP
> -The inlined code often consists of a single instruction adjusting
> -the stack pointer, and does not check for stack overflow.
> -Thus, there is no NULL error return.
> +The fact that
> +.BR alloca ()
> +is a built-in means it is impossible to take its address
> +or to change its behavior by linking with a different library.
>   .SH BUGS
>   Due to the nature of the stack, it is impossible to check if the allocation
>   would overflow the space available, and, hence, neither is indicating an error.
> 


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

[PATCH v2 5/5] alloca.3: simplfy malloc(3) suite comparison, note VLAs

[наб]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

alloca() is, ex definitione, always faster than any allocator that
actually, well, allocates

Like Alejandro noted, VLAs can provide a less-flexible but sometimes
better-suited solution to the same problem class

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/alloca.3 | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 936a15954..736182a7d 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -90,11 +90,8 @@ originates from PWB and 32V, and appears in all their derivatives.
 The
 .BR alloca ()
 function is machine- and compiler-dependent.
-For certain applications,
-its use can improve efficiency compared to the use of
-.BR malloc (3)
-plus
-.BR free (3).
+Because it allocates from the stack, it's faster than
+.BR malloc (3)/ free (3).
 In certain cases,
 it can also simplify memory deallocation in applications that use
 .BR longjmp (3)
@@ -140,6 +137,13 @@ The fact that
 .BR alloca ()
 is a built-in means it is impossible to take its address
 or to change its behavior by linking with a different library.
+.PP
+Variable length arrays (VLAs) are part of the C99 standard,
+optional since C11, and can be used for a similar purpose.
+However, they do not port to standard C++, and, being variables,
+live in their block scope and don't have an allocator-like interface,
+making them unfit for implementing functionality like
+.BR strdupa (3).
 .SH BUGS
 Due to the nature of the stack, it is impossible to check if the allocation
 would overflow the space available, and, hence, neither is indicating an error.
-- 
2.20.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]