How to represent currency or money in C

ccurrency

TL;DR¹ What is an accurate and maintainable approach for representing currency or money in C?

Background to the question:
This has been answered for a number of other languages, but I could not find a solid answer for the C language.

C# What data type should I use to represent money in C#?
Java Why not use Double or Float to represent currency?
Objective-C How to represent money in Objective-C / iOS?

_{Note: There's plenty more similar questions for other languages, I just pulled a few for representational purposes.}

All of those questions can be distilled down to "use a decimal data type" where the specific type may vary based upon the language.

There is a related question that ends up suggesting using a "fixed point" approach, but none of the answers address using a specific data type in C.

Likewise, I have looked at arbitrary precision libraries such as GMP, but it's not clear to me if this is the best approach to use or not.

Simplifying Assumptions:

Presume an x86 or x64 based architecture, but please call out any assumptions that would impact a RISC based architecture such as a Power chip or an Arm chip.
Accuracy in calculations is the primary requirement. Ease of maintenance would be the next requirement. Speed of calculations is important, but is tertiary to the other requirements.
Calculations need to be able to safely support operations accurate to the mill as well as supporting values ranging up to the trillions (10^9)

Differences from other questions:

As noted above, this type of question has been asked before for multiple other languages. This question is different from the other questions for a couple of reasons.

Using the accepted answer from: Why not use Double or Float to represent currency?, let's highlight the differences.

(Solution 1) A solution that works in just about any language is to use integers instead, and count cents. For instance, 1025 would be $10.25. Several languages also have built-in types to deal with money. (Solution 2) Among others, Java has the BigDecimal class, and C# has the decimal type.

_{Emphasis added to highlight the two suggested solutions}

The first solution is essentially a variant of the "fixed point" approach. There is a problem with this solution in that the suggested range (tracking cents) is insufficient for mill based calculations and significant information will be lost on rounding.

The other solution is to use a native decimal class which is not available within C.

Likewise, the answer doesn't consider other options such as creating a struct for handling these calculations or using an arbitrary precision library. Those are understandable differences as Java doesn't have structs and why consider a 3rd party library when there is native support within the language.

This question is different from that question and other related questions because C doesn't have the same level of native type support and has language features that the other languages don't. And I haven't seen any of the other questions address the multiple ways that this could be approached in C.

The Question:
From my research, it seems that float is not an appropriate data type to use to represent currency within a C program due to floating point error.

What should I use to represent money in C, and why is that approach better than other approaches?

¹ _{This question started in a shorter form, but feedback received indicated the need to clarify the question.}

Best Answer

Never use floating point for storing currency. Floating point numbers cannot represent tenths or hundredths, only diadic rationals, i.e. numbers of the form p/q where p and q are integers and q is a power of 2. Thus, any attempt to represent cents others than 0, 25, 50, or 75 cents will require an approximation, and these approximations translate into vulnerabilities that can be exploited to make you lose money.

Instead, store integer values in cents (or whatever the smallest division of the currency is). When reading values formatted with a radix point, simply read the whole currency units and cents as separate fields, then multiply by 100 (or the appropriate power of 10) and add.

Setting a bit

Use the bitwise OR operator (|) to set a bit.

number |= 1UL << n;

That will set the nth bit of number. n should be zero, if you want to set the 1st bit and so on upto n-1, if you want to set the nth bit.

Use 1ULL if number is wider than unsigned long; promotion of 1UL << n doesn't happen until after evaluating 1UL << n where it's undefined behaviour to shift by more than the width of a long. The same applies to all the rest of the examples.

Clearing a bit

Use the bitwise AND operator (&) to clear a bit.

number &= ~(1UL << n);

That will clear the nth bit of number. You must invert the bit string with the bitwise NOT operator (~), then AND it.

Toggling a bit

The XOR operator (^) can be used to toggle a bit.

number ^= 1UL << n;

That will toggle the nth bit of number.

Checking a bit

You didn't ask for this, but I might as well add it.

To check a bit, shift the number n to the right, then bitwise AND it:

bit = (number >> n) & 1U;

That will put the value of the nth bit of number into the variable bit.

Changing the nth bit to x

Setting the nth bit to either 1 or 0 can be achieved with the following on a 2's complement C++ implementation:

number ^= (-x ^ number) & (1UL << n);

Bit n will be set if x is 1, and cleared if x is 0. If x has some other value, you get garbage. x = !!x will booleanize it to 0 or 1.

To make this independent of 2's complement negation behaviour (where -1 has all bits set, unlike on a 1's complement or sign/magnitude C++ implementation), use unsigned negation.

number ^= (-(unsigned long)x ^ number) & (1UL << n);

unsigned long newbit = !!x;    // Also booleanize to force 0 or 1
number ^= (-newbit ^ number) & (1UL << n);

It's generally a good idea to use unsigned types for portable bit manipulation.

number = (number & ~(1UL << n)) | (x << n);

(number & ~(1UL << n)) will clear the nth bit and (x << n) will set the nth bit to x.

It's also generally a good idea to not to copy/paste code in general and so many people use preprocessor macros (like the community wiki answer further down) or some sort of encapsulation.

Javascript – How to format numbers as currency strings

Intl.NumberFormat

JavaScript has a number formatter (part of the Internationalization API).

// Create our number formatter.
var formatter = new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD',

  // These options are needed to round to whole numbers if that's what you want.
  //minimumFractionDigits: 0, // (this suffices for whole numbers, but will print 2500.10 as $2,500.1)
  //maximumFractionDigits: 0, // (causes 2500.99 to be printed as $2,501)
});

formatter.format(2500); /* $2,500.00 */

Use undefined in place of the first argument ('en-US' in the example) to use the system locale (the user locale in case the code is running in a browser). Further explanation of the locale code.

Here's a list of the currency codes.

Intl.NumberFormat vs Number.prototype.toLocaleString

A final note comparing this to the older .toLocaleString. They both offer essentially the same functionality. However, toLocaleString in its older incarnations (pre-Intl) does not actually support locales: it uses the system locale. So when debugging old browsers, be sure that you're using the correct version (MDN suggests to check for the existence of Intl). There isn't any need to worry about this at all if you don't care about old browsers or just use the shim.

Also, the performance of both is the same for a single item, but if you have a lot of numbers to format, using Intl.NumberFormat is ~70 times faster. Therefore, it's usually best to use Intl.NumberFormat and instantiate only once per page load. Anyway, here's the equivalent usage of toLocaleString:

(2500).toLocaleString('en-US', {
  style: 'currency',
  currency: 'USD',
}); /* $2,500.00 */

Some notes on browser support and Node.js

Browser support is no longer an issue nowadays with 98% support globally, 99% in the US and 99+% in the EU
There is a shim to support it on fossilized browsers (like Internet Explorer 8), should you really need to
Node.js before v13 only supports en-US out of the box. One solution is to install full-icu, see here for more information
Have a look at CanIUse for more information