[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Karl DeBisschop]

Yves Mettier wrote:

>>Ben Clewett wrote:
>>
>>
>>>Looking back at suggestions from my original email and discussion:
>>>
>>>4.  Addition of macro's.  NaN = No value.  -INF and +INF to be used in
>>>range specification.  Agreed.  (?)
>>
>>I do still think some token to indicate it is a macro is appropriate
> 
> For INF and NaN, I don't consider them as macros, but as values.
> Look at the ethymology: macro stands for macro command. And INF and NaN are not commands !

Not my term. To me, it doesn't matter whether they are called macros or 
something else. Only that most programming languages will not scan the 
line and automatically create the corresponding value in a float variable.

> Any reason not to use $ like nagios does ? $TIMET$ :)

Perfectly fine by me.

>>Or is there a general reason why some sort of tokens won't work?
> ls 
> Back to the debate. For me, there are now 2 questions.
> 1/ Are NaN and INF macros ? I consider that they are values, and should be recognized as
> values, like some strtod() implementations do. I also suggest to use the values that
> glibc uses:
> printf("%lf %lf\n", (0./0.), (1./0.));
> I'm not sure (I have no glibc here), but the result is something like this:
> NaN inf

SUSv3 (i.e.,, POSIX) says:

These functions shall convert the initial portion of the string pointed 
to by
nptr to double, float, and long double representation, respectively. 
First, they
decompose the input string into three parts:

    1. An initial, possibly empty, sequence of white-space characters 
(as specified by isspace())
    2. A subject sequence interpreted as a floating-point constant or 
representing infinity or NaN
    3. A final string of one or more unrecognized characters, including 
the terminating null byte of the input string

Then they shall attempt to convert the subject sequence to a 
floating-point number, and return the result.

The expected form of the subject sequence is an optional plus or minus 
sign, then one of the following:

     * A non-empty sequence of decimal digits optionally containing a 
radix character, then an optional exponent part
     * A 0x or 0X, then a non-empty sequence of hexadecimal digits 
optionally containing a radix character, then an optional binary 
exponent part
     * One of INF or INFINITY, ignoring case
     * One of NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part,

If we follow POSIX, case does not matter.

> If we consider them as values, there are only "NaN" and "inf" to recognize before using
> strtod. We don't need an identifier.

POSIX strtod is required to recognize NAN and INF, so I'm willing to 
follow POSIX and forgo any other indicators

If NAN and INF are the only tokens we are concerned with, my concerns 
can be put aside so long as the guideline we produce does not otherwise 
prohibit string data.

-- 
Karl