Handling of standard C NaN and Inf will be always better and easier for programmers, so this change is welcome.

Just some hints, floating point support is problematic for me, because every architecture and compiler impleents them differently. Yes, there is C standard and an IEEE 754 but not all parts are mandatory and not all compilers obey them. And there is IEEE 488 and SCPI defining something different or some subset.

So, please, take this into account.

I have created some macros to test nans and infs in the past (useing native support or fallback to naive implementation). Please, use them or extend/fix them as needed.

Please use native compilers definitions of NaN an Inf where possible and not some single precision constants defined in SCPI. I would like to support double precision numbers even if they are not defined in SCPI.

Please also take into account, that it should work on e.g. 8-bit AVR, where in AVRGCC only float exists (doube is mapped to float), it should be agnostic to Little and Big endian architectures and it should be possible to exted the support to some other compilers, like C compilers for PIC16/24, proprietary compilers for ARM, NI LabWindows/CVI, MS Visual C etc.

Wow, this sounds like a much bigger task than I had originally imagined. I was simply thinking I could change the SCPI_dtostre function (here) to return floats instead of "NAN" and "INF". You've alerted me to the fact that there are systems that don't use that function.

However, looking at it again, it seems that I could still simply insert a comparison into each of the SCPI_FloatToStr and SCPI_DoubleToStr functions to compare the float value against INF or NAN, and short circuit the function when these values are found by returning the appropriate string for each value (i.e. "9.9e+37", "-9.9e+37", and 9.91e+37").

So the implementation of SCPI_DoubleToStr would look like this:

size_t SCPI_DoubleToStr(double val, char * str, size_t len) {
    if(SCPIDEFINE_isfinite(val))
        SCPIDEFINE_doubleToStr(val, str, len);
    }else{
        if (SCPIDEFINE_isnan(val)) {
            strcpy(str, "9.91E+37");
        } else {
            strcpy(str, "9.9E+37");
        }
    }
    
    return strlen(str);
}

Would this do it, or am I missing something?

It seems that it is not so easy.

1. Please, don't use these constants in functions using Double in name an leave them as nonstandard extension to SCPI. Change only functions using Float in name.

2. SCPI_ResultFloat should be fixed to return these specific values instead of nan and inf. It should also return any number larger then these as inf. SCPI constants are completely nonstandard from IEEE 754 point of view and may be confusing nowadays. I must investigate, if it is legal to return mnemonic INF and NAN instead.
   Modification of SCPI_FloatToStr may or may not bee good place to solve this.
   Please use "safe" versions of
   funcions like strcpy vs. strncpy.
   I'm not sure if SCPIDEFINE_isfinite is false for NaN.

3. SCPI_ParamIsNumber should be fixed to handle inf and nan as number

4. SCPI_ParamToFloat should handle inf and nan properly. It should also limit the range of larger numbers. It should convert 9.9e37 to native IEEE 754 inf and so on.

5. SCPI_ParamToDouble should correctly handle inf and nan but should not obey the SCPI limits. It should be highlighted in the doc as nonstandard extension to SCPI.

6. SCPI_ParamNumber should be probably reworked, but it can't simply use Float versions of functions instead of Double ones because of limited range of float numbers. (or can? It needs some investigation)

7. SCPI_NumberToStr should be reworked to properly limit range, handle nans and infs, etc. Using just Float version instead of Double version is not a solution for this.