Re: Texinfo 7.0.93 pretest available

[Gavin Smith]

On Sun, Oct 08, 2023 at 04:38:46PM +0300, Eli Zaretskii wrote:
> > According to the documentation for getline,
> > 
> >      If you set ‘*LINEPTR’ to a null pointer, and ‘*N’ to zero, before
> >      the call, then ‘getline’ allocates the initial buffer for you by
> >      calling ‘malloc’.  This buffer remains allocated even if ‘getline’
> >      encounters errors and is unable to read any bytes.
> > 
> > Hence, I propose to initialise n to 0, rather than 120 as in the patch
> > below.
> 
> No, the value must be positive, otherwise it still crashes.  It's a
> bug in MinGW implementation.

Can you refer to any discussion of this bug online anywhere?

I see on the POSIX specification:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/getdelim.html

the wording is slightly different to the glibc manual:

   If *n is non-zero, the application shall ensure that *lineptr either
   points to an object of size at least *n bytes, or is a null pointer.
   
   If *lineptr is a null pointer or if the object pointed to by *lineptr
   is of insufficient size, an object shall be allocated...

This implies that it is ok to have null *LINEPTR and positive *N.

I don't like using the value 120 as this is slightly larger than a
default line length of 80, which is confusing as you might think it
was that number for a reason and that we were supporting input line
lengths up to 120 bytes, when in fact any positive number would have
done.

I will change it to be 1 with a comment that it should be any positive
number.  If we can get any other information on this MinGW bug, we can
reference that too.

This bug sounds like something that should be worked around with gnulib.
Would you be able to send details of the bug to bug-gnulib@gnu.org as
well as any information on the versions of MinGW affected?