Re: gnuplot slow on BIG files

[<br...@ph...>]

Ethan Merritt wrote:

> It turns out that different ANSI revisions describe
> the behavior of %n differently, so it is not portable.  

Even the (Linux) libc man page isn't sure of itself in this regars. 
They only say the TC "seems to say otherwise".  I think they're 
misguided.  The description of %n in C90 is very easy to misinterpret. 
I'm reasonably sure the update they mention was only meant to clarify, 
not change the standardized behaviour.  The tricky bit is that %n is not 
a "conversion", so it's not supposed to affect the return value.

 > Here is an
> excerpt from the current man page:
>   "Probably  it  is  wise not  to  make any assumptions on the
>    effect of %n conversions on the return value."

That comment doesn't necessarily concern the case of gnuplot.  We don't 
have to know whether our sscanf("%lf%n",...) returned 1 or 2, which is 
all this is talking about.  We only need to know if it's zero (because 
the %lf failed), EOF (empty input, shouldn't happen) or anything else 
(so the %lf succeeded).

> The current code assumes that 
> 	count = sscanf(s, "%lf%n", ...)
> will set count to 1 if successful, but on some systems it will instead
> set count to 2.  I do not know if this is the specific problem with OSK.

No. I dimly recall the problem with OS-9 (which #defines OSK) was that 
%n simply didn't work at all.  I.e. it didn't put anything into the 
'used' variable.

> strtod() is more portable than %n, 

Unless we have somebody verify to us that strtod() implements the same 
ANSI standard more correctly than sscanf(), on OS-9, we don't know that.

 > and allows more complete
> error reporting than sscanf().

No, it doesn't.  It tells us nothing that sscanf()'s return value, 
combined with the output of %n, wouldn't.