I am the author of a C library for parsing INI files. So far I have delegated the task of parsing values as numbers to the standard atoi() family of functions. However I think time has come that I provide my specific functions for parsing numbers, since in INI files a number can be notated in octal, hexadecimal, etc., and there are a few more things in which I would like to specialize my own code.

Everything good so far. I have written two functions that are nearly-identical except for the data type. One parses integers, the other one parses fractional numbers. I have no doubts that the one that parses integers should return an intmax_t type. But what about the one that parses fractional numbers? Should that return a double or a long double?

Mine is a very general purpose library, it can be used in all kind of contexts, from embedded systems to desktop applications, and the INI files can be of all kinds. Whatever I choose now I will have to stick to it for a while, since changing the data type will break the binary compatibility.

So the question is: double or long double for parsing fractional INI values?

  • Having a look into the lib's documentation, it seems it provides already ini_get_int() for int values, ini_get_lint() for long int values and ini_get_double() for double values, Why don't you consequently add another function ini_get_ldouble() in case someone requires it?
    – Doc Brown
    Oct 18, 2020 at 8:19
  • Hi Doc. These are all the old functions that rely on the atoi(), atof(), etc. function family. My current intention is to deprecate those and provide two novel functions, one that returns an intmax_t and one that returns a long double. These two new functions will have much more power than the previous ones. For example they will be able to parse hexadecimal (e.g. 0xfe214), octal (e.g. 01401) and binary (e.g. 0b11001) numbers, there will be an error object for the overflow/underflow cases, and they will have a few more additional skills.
    – madmurphy
    Oct 18, 2020 at 10:49
  • Do the old functions cause any real issues, or are you just deprecating those older functions because they are old?
    – Doc Brown
    Oct 18, 2020 at 12:07
  • Well, there are a couple of critiques that can be raised. First, they are not functions, but function pointers to the C standard atoi(), atol(), atoll() and atof(). And as the latter belong to the C Standard Library there is really no need that I provide aliases. The second critique is that my library has generally developed the ability to work with raw INI strings without the need to parse them (namely removing quotes and unescaping). I would like that my number parsing functions be able to do the same. Third, as I said I would like to be able to parse hexadecimals and other bases.
    – madmurphy
    Oct 18, 2020 at 12:31
  • 1
    Well, I would heavily recommend to get some feedback by your lib's users - only they can tell you what they really need.
    – Doc Brown
    Oct 19, 2020 at 8:09

1 Answer 1


Neither double nor long double are suitable for expressing fractional numbers. They are for floating point numbers, not fractional numbers.

You should use a fractional number data type, something like this:

struct fraction {
    intmax_t  numerator;
    uintmax_t denominator;

Instead of intmax_t / uintmax_t, you should probably use an arbitrary sized integer type.

  • Strictly speaking you are right, Jörg. But they are only INI files, wouldn't implementing a true ratio data type as in your example be too much in this case? I want a floating point data type, I just cannot choose which one.
    – madmurphy
    Oct 17, 2020 at 9:06
  • 4
    It really depends on what you'll be doing with the numbers. Since you provide a library and are not the principal user, it would be best if you would provide users with options. Double versus long double would probably not make an important difference, but decimal fractions are sufficiently different that providing an option to read a configuration value as a decimal fraction makes sense. Oct 17, 2020 at 9:42
  • Decimal fractions are an idea, and it is always possible to expand the library to provide this functionality. However the ability to parse a string as a floating point data type is really a must in this context. The two things do not exclude each other. But going back to my question (which is specific to when I want to return a floating poing type), which one would be the optimal solution according to you between a double and a long double in a general purpose library? I would opt for the long double, since it is always possible to reduce the precision required, but not the opposite.
    – madmurphy
    Oct 17, 2020 at 15:45
  • I am partially changing my mind and moving towards arbitrary size numbers together with integers and floating point types. I am rewriting my code in that direction. Thank you guys for helping me clear my mind.
    – madmurphy
    Oct 18, 2020 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.