Re: [PATCH] stdio: fix vfscanf with matches longer than INT_MAX (bug 27650)

[Florian Weimer <fw@deneb.enyo.de>]

* Alyssa Ross:

>>> I have not done a copyright assignment yet, but I think this change
>>> should be small enough to be exempt?
>>
>> Yes, I think it's small enough.
>>
>> The test case wouldn't be, though.  I think the one on the bug needs
>> some large (infinite) input on the stdin, though.  A real test case
>> for glibc should probably involve pipe, fork, and fdopen.  fopencookie
>> could work, too.
>
> Oh, thanks for telling me about fopencookie!  I'd never have known about
> that otherwise.  I've started having a go at a test case using it and it
> seems like it'll work well.

Or you could test sscanf via <support/blob_repeat.h> on 64-bit
architectures.  It would avoid the repeated memcpy calls, at the cost
of an initial strlen on the entire buffer.

> One question about the test: fscanf-ing through INT_MAX characters on a
> trivial memcpy-based fopencookie stream takes 20 seconds on my
> (admittedly fairly old) machine.  How slow is too slow for a test?

Opinions on that vary.  Twenty seconds is stretching things as far as
I'm concerned.  I guess it depends what you mean by “fairly old”.

We have a second category of tests, xtests, that only run with “make
xcheck”.  We could put the test there if it takes too long to run
otherwise.