[PATCH] stdio-common: Add test for vfscanf with matches longer than INT_MAX [BZ #27650]

[Maciej W. Rozycki]

On Fri, 7 Jun 2024, Florian Weimer wrote:

> * Maciej W. Rozycki:
> 
> > +/* Produce a stream of more than MAX_INT characters to stdout of which
> > +   none is the new line character.  This is executed as a subprocess
> > +   and the caller wants a void callee, upon the return from which the
> > +   process will terminate successfully, so in the case of a failure we
> > +   need to explicitly call exit with the failure status.  */
> > +
> > +static void
> > +do_write (void *arg)
> > +{
> > +  static const char s[] = { [0 ... 4095] = 'a' };
> > +  size_t i;
> > +
> > +  for (i = 0; i <= INT_MAX / sizeof (s); i++)
> > +    if (fwrite (s, 1, sizeof (s), stdout) != sizeof (s))
> > +      {
> > +	int err = errno;
> > +
> > +	/* Close our stdout so that there's no risk for us to block
> > +	   while `fscanf' is waiting on our stdout in `do_read' and
> > +	   nothing checking our stderr.  If closing has failed, then
> > +	   refrain from reporting anything, for the same reason.  */
> > +	if (fclose (stdout) == 0)
> > +	  error (0, err, "%s: fwrite: output error", __func__);
> > +	exit (EXIT_FAILURE);
> > +      }
> 
> Is there a reason for using stdout or stream I/O for writing the file?
> You could use create_temp_file from <support/temp_file.h> and write
> directly to the file descriptor.

 A pipe is used because over 2GiB of data has to be transferred.  It could 
be a bit of a stress for the target board if such a large amount was to be 
actually stored in a filesystem (even in the presence of LFS).  There may 
be limited storage available too.

 My choice to use the `fwrite' interface over raw `write' was mostly 
symmetry with the rest of code and also less hassle in handling, as with 
`fwrite' you don't have to take care of partial writes.  Besides, `stdout' 
is readily available, there's no need for an extra library call (and an 
error to handle) to extract the underlying file descriptor.  Not a big 
deal overall, just a matter of style.

> It may be faster to use <support/blob_repeat.h> to create a string in
> memory because it uses alias mappings, and parse that string using
> sscanf or fmemopen+vfscanf.

 Neat!  However with 32-bit targets the size of the allocation required 
may exceed the limit of the user VM supported by hardware or the OS (some 
targets give room for manoeuvre to the OS as to the user/kernel VM split 
while other ones have it hardwired).  As a quick check I have run 
stdlib/tst-strtod-overflow with my 74Kf target and, lo and behold:

UNSUPPORTED: stdlib/tst-strtod-overflow
original exit status 77
warning: memory allocation failed, cannot test for overflow

And I think we do want to have coverage for scanning INT_MAX+ characters 
especially with 32-bit targets, where it may be hitting more than just the 
limit of the `int' type and the specific issue reported with BZ #27650.

 Do my answers address your concerns?

  Maciej