Re: conflict of separator and missing

[Ethan A M. <sf...@us...>]

On Friday, 17 June, 2016 08:42:46 pl...@pi... wrote:

> Can you comment on whether there is a reason to strip leading WS but not 
> strip trailing WS ( as is currently done )?  This seems a little odd and 
> is unlikely to be a combination that one would expect.
> 
> Unless there is a positive reason for this choice or downside that I'm 
> missing, It would seem more consistent to strip both ends.

You may be over-thinking this.
Gnuplot does no "stripping" or other pre-processing of the input line.
Successive fields are read by standard calls to the C library.

For a numeric field this is either atod() or sscanf().
In either case the C language formatted input routine 
1) skips over any leading whitespace, 
2) parses the number, and
3) stops at the first character that is not part of the number.
That next character could be anything.
In other words, skipping any leading whitespace and ignoring any 
trailing garbage is all normal behaviour for the libc input routines.

For a string field (e.g. 'plot with labels') it's a bit more complicated.
In this case yes, unquoted leading and trailing whitespace is eventually
stripped but this happens at a later stage, not while parsing the input.
Also some escape-character sequences are translated.

For detection of a "missing" flag? Well, that's what we're discussing.
This thread started with the example of using a numeric value as a
"missing" flag, which adds an additional layer of ambiguity.  
If you think of it as substituting for a number, then trailing characters
should be ignored.  If you think of it as a string, then trailing 
characters including whitespace are potentially significant.  If it
really were a string then at a later stage any trailing whitespace would
be deleted but nothing in the current input layer (datafile.c) does this,
and this is the layer that has to decide whether the current record
is missing or not.

> It seems that this choice may have been motived by the comment issue and 
> maybe making the comment behaviour more consistent, as outlined above, 
> would neatly resolve both.

The only comment issue I see is that the documentation could be more
clear that it is talking about command lines rather than data files.
That much is easy to fix.

	Ethan