'0' not a float or double

[ielo]

I'm sorry if this sounds totaly amateurish (and I guess easy to answer), but can't '0' be considered as a float or double? I'm parsing input lines to make sure all tokens are valid floats (e.g. 0.00001e+002). I do this by checking the returned value of 'atof' for each scanned token 'string'. If atof returns anything but 0, it's valid. However, in some cases values are zero (i.e. 0.00000e+000); if I use 'atof', I'll get '0'. Is there no way of distinguishing '0' from gibberish (e.g. 0.00????e+000)?

This isn't critical, as I can always skip this input checking procedure by later setting to '0' any token string that atof doesn't recognize as a float ... but I'd like to know all the same. The other way would be to mimick something like atof which would admit '0' as being valid.

Thanks in advance

 

[Salem]

       double strtod(const char *nptr, char **endptr);
       float strtof(const char *nptr, char **endptr);
       long double strtold(const char *nptr, char **endptr);

Use these routines if you want to meaningfully validate the input.

--

 

[ielo]

Thanks Salem!

I had come across strtof in the atof man pages, but apparently hadn't tested it enough to get a better sense of its worth.

Consider the strtof prototype in Salem's response. If nptr is, let's say '0.0000e+000', then strtof returns '0' (meaning there is no conversion), yet *endptr remains NUL (ASCII "0"). On the other hand, if nptr contains garbage (e.g. 0.00?1e+00!), strtof will still return '0', yet *endptr will reference the first faulty character, in this case '?'. This difference allows to distinguish correctly-formatted '0's from otherwise invalid input.

 

[chipperMDW]

If nptr is, let's say '0.0000e+000', then strtof returns '0' (meaning there is no conversion), yet *endptr remains NUL (ASCII "0").

Not necessarily NUL, but whatever comes immediately after the part of the string that looks like a float. That could also be whitespace or a newline depending on where and how you got the string.

Don't forget to check [tt]errno[/tt], as well.

 

[ielo]

hmmmm ... if the string contains gibberish that can't be part of a valid float, then you're right: *endptr will refer to the first non-valid character. Yet if it's '0', then *endptr seems to be NUL - always. I've tried with preceding white spaces, tabs, etc. it's still NUL. I'm guessing here that no single character in such a string (e.g. '0.0000e+000') prevents float conversion, but that '0' can't be a valid float, hence *endptr remaining at NUL. However, I wouldn't mind being proven wrong on this - would get rid of some doubt on using strtof.

 

[Salem]

But [tt]0.00?1e+00![/tt] is a valid floating point number in it's own right (as far as any conversion function is concerned).

But if you're saying that all valid numbers must have say 11 characters (0.0000e+000), then you could do something like this

char s[] = "0.0000e+000";
char *endptr;
double answer = strtod ( s, &endptr );
if ( errno == 0 && (endptr-s) == 11 ) {
  /* it's valid */
}

--

 

[ielo]

Thanks Salem, maybe I'm not getting something ... in no way am I interested in setting the maximum number of characters in a scanned string. The string could be '0.1' or '0.001e+000'. All I want to do is avoid unexpected behavior if ever some gibberish gets inserted in some way in an ASCII file. Whether I use 'atof' or 'strtof', '0.00?1e+00' will return '0', meaning no conversion occurs (and *endptr will reference the '?'). So I'm not sure what you mean by 'valid [...] (as far as any conversion function is concerned)'.

For the moment, I'm assuming that when strtof returns '0' and that *endptr equals '0', then the string should be '0'.

 

[chipperMDW]

[tt]0.00?1e+00[/tt]

is valid in the same way that

[tt]4.69blujhaslkdd[/tt]

is valid.


It parses out as much as it can as a float, then it stops as soon as it hits an invalid character. ([tt]?[/tt] in the first case, and [tt]b[/tt] in the second case).