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

[Alyssa Ross <hi@alyssa.is>]

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

Florian Weimer <fw@deneb.enyo.de> writes:

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

Would that be a problem on 32-bit?  We'd only need to map
INT_MAX bytes + 1 page, so the other half of the address space would be
enough for everything else, wouldn't it?

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

That machine is a laptop from 2012.  On my other laptop, from 2017, it
takes <5 seconds, and the fopencookie and blob_repeat versions aren't
really distinguishable from each other in terms of time taken.  I would
like to go with the blob_repeat version if it'll work everywhere,
though, because not having to write a custom stream implementation makes
the test a lot shorter and easier to understand.

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