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-gnu...@gnu.org as well as any information on the versions of MinGW affected?
