6
  • Does calloc() of a double field always evaluate to 0.0?

Furthermore:

  • Does calloc() of a float field always evaluate to 0.0f?
  • Does calloc() of an int or unsigned int field always evaluate to 0?

That is, will the assert() below always succeed on all platforms? 

double* d = calloc(1, sizeof(double));
assert(*d == 0.0);
free(d);
u17
  • 2,776
  • 4
  • 31
  • 43

4 Answers4

7

C11 documentation has this explicit notice for calloc

Footnotes

  1. Note that this need not be the same as the representation of floating-point zero or a null pointer constant.

In practice, all zero bits is a (or the) representation for 0.0 on all major platforms as they use IEEE 754 representation. Yes, this will hold on Intel, ARM, Linux, Windows, Mac, Raspberry PI, the smartphones.

Antti Haapala -- Слава Україні
  • 129,958
  • 22
  • 279
  • 321
6

The calloc sets all bytes of the allocated memory to zero.

As it happens, that's also the valid IEEE754 (which is the most common format for floating point values on computers) representation for 0.0.

IIRC there's no part of the C specification that requires an implementation to use IEEE754, so to be picky it's not portable. In reality though, it is (and if you're ever going to work on a non-IEEE754 system then you should have gathered enough experience to already know this and how to solve such problems).

Also note that this also is valid for pointers. On all systems you're likely to come in contact with, a null pointer should be equal to 0. But there might be systems where it isn't, but if you work on such systems you should already know about it (and if you use NULL then it should not be a problem).

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • Thanks for the IEEE 754 reference. – u17 Dec 14 '18 at 16:22
  • I'm not sure about your null pointer explanation. After all, the C language guarantees that a null pointer will equal `0`, even on those unusual systems where `calloc` is not guaranteed to initialize a pointer-sized object to a null pointer value. I'm not sure what you mean by "(and if you use `NULL` then it should not be a problem)". – Ian Abbott Dec 14 '18 at 18:13
  • @IanAbbott It might be that the integer literal `0` have been recognized as a null pointer (as it is in C++, but then it must be the actual literal `0` not an integer variable with all zero bits) in later revisions of the C standard, but the portable null pointer is, has, and always will be the macro `NULL`. – Some programmer dude Dec 14 '18 at 20:49
  • @Someprogrammerdude It doesn't need to be a literal `0`. It just needs to be an *integer constant expression* with value 0, or such an expression cast to `void *`. You are correct that a value 0 stored in an *lvalue* of integer type cannot be compared to a pointer value. – Ian Abbott Dec 17 '18 at 16:20
2

All bytes zero for a float does not mean 0.0. From here

Initialization to all bits zero does not guarantee that a floating-point or a pointer would be initialized to 0.0 and the null pointer value, respectively (although that is true on all common platforms)

Gaurav Sehgal
  • 7,422
  • 2
  • 18
  • 34
  • I should have read cppreference.com for `calloc()` before asking the question. I had looked at cplusplus.com only. :-) – u17 Dec 14 '18 at 16:24
2

C standard deliberately avoids specifying the way that float and double are represented:

6.2.6.1 General

  1. The representations of all types are unspecified except as stated in this subclause.

Therefore, you have no guarantee that calloc would produce 0.0 values.

Representation of unsigned integers, on the other hand, is specified as follows:

If there are N value bits, each bit shall represent a different power of 2 between 1 and 2N−1, so that objects of that type shall be capable of representing values from 0 to 2N − 1 using a pure binary representation.

Therefore, the value of calloc-ed unsugned int is guaranteed to be zero.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523