Comment by agalunar | Hacker News Reader

Comment by agalunar | Hacker News Reader

I've become somewhat convinced that no one has written a correct nontrivial C or C++ program since 1989.* My go-to example in C++ is examining a floating-point number as an integer:

• Cast a (pointer to a float) to a (pointer to a uint32_t). No; even if you make sure the size of a float on your target platform is 32 bits, this is undefined behavior.

• Make a union of a float and uint32_t. No; this works in C (since C99...?), but in C++ "it is undefined behavior to read from the member of the union that wasn't most recently written." [1]

• Use reinterpret_cast<uint32_t>. No; this violates the type aliasing rules, and the behavior is undefined. [2]

• Use reinterpret_cast<unsigned char> or reinterpret_cast<std::byte> and then reassemble these into a uint32_t. Yes! this works, although slightly laborious.

• Use std::memcpy. Yes! This is perhaps the "right" answer. The compiler should recognize the idiom and elide any actual copy.

I'm not even confident that I have that correct. It's an enormous language to fit into one's head; the language specification runs about 500 pages long and the standard library another 1500. [3]

[1] https://en.cppreference.com/w/cpp/language/union [2] https://en.cppreference.com/w/cpp/language/reinterpret_cast [3] https://github.com/cplusplus/draft/releases/tag/n4917

*This is a joke, but only barely so.

Since C++20 the correct, constexpr-friendly approach to your specific problem is std::bit_cast: https://en.cppreference.com/w/cpp/numeric/bit_cast.

Ah, yes, thank you for catching my omission!

> My go-to example in C++ is examining a floating-point number as an integer

Which is something that hardly makes any sense and most professional will never need in their entire career.

It depends on what you do! The reason I use this as my go-to example is that I came across the incorrect use of reinterpret_cast for this exact purpose in a previous job (which was firmware-adjacent).

edit: are you also expressing disagreement with the claim that few C++ programs are correct (and the implied claim that this is because many people's first-guess approaches are actually incorrect), or just saying that you think this is a bad example of the language being complex or misleading?

Serialization of floating point number makes some sense. Even if you can't reliably read it on other machine, reading it on the same machine should be possible.

Yes, being able to fwrite() dump floats to binaries is invaluable when working with large datasets. It's common to see binary 'cache' file being created for ASCII inputs (e.g. CSV) when there is any chance of it being fed repeatedly.

> fwrite() dump floats to binaries

That requires a cast from float* to void*. Reading the floating point number as an integer is not necessary.

AFAIK the underlying mechanism and undefined behaviour is the same.

No, it isn't!

Casting any object pointer to (and from) void* or char* is guaranteed to work, while float to integer incurs in the undefined behaviour curse.

Do I understand you right that

  for (int i=0; i<4; i++) 
    buf[i] = ((char*)&my_float)[i];

is not undefined behavior? But that

  for (int i=0; i<4; i++)
    buf[i] = ((char*)(int32_t*)&my_float)[i];

is undefined?

I'm not sure 100%, but your second example does not imply UB. UB is caused by the act of accessing an object via a pointer of the wrong type, but just casting a pointer as you do should not be a problem.

On the other side, this would incur UB:

   int32_t my_int = *((int32_t*)&my_float);

Serialization of floating point number makes a lot of sense. But you don't need to read it as an integer.

What if you need to do an endianness conversion?

In that case, you need a cast from float* to char*, which is guaranteed to work.

There is no sane reason to want to access a float as an integer.

I'll just leave this here: https://en.wikipedia.org/wiki/Fast_inverse_square_root

They said sane reason and that most programmers would never need to do it. I don't think the magic inverse square root contradicts that.

I stand corrected: there is one very good reason to want to treat a float like an integer. But if you can come up with such a solution, you are definitely not one to stop at their first guess, and you'll double-check the standard before the final commit.

Ok, what about: https://leonardschuetz.ch/blog/nan-boxing/

Another use is doing radix sort of floating point numbers. Since the exponent is in the most significant bits you can almost treat them as integers for radix sort (you just need to be a bit careful with negative values): http://www.codercorner.com/RadixSortRevisited.htm

If you are interested in the actual bits, then that's what this is. Hence in Rust the method on f32 and f64 to do this is named "to_bits"

No, sorry, you are wrong. If you are interested in the actual bits, char* is the way to go.

That's bytes, if you want bytes you need to specify what order you think the bytes are in, Rust's to_be_bytes, to_ne_bytes and to_le_bytes gives you bytes (in Big, Network, or Little endian)

I'm not sure that I understand your point.

Actually, I wonder if you do ;-)

Rust provides methods to get your f32 (a 32-bit IEEE floating point number) or f64 (the 64-bit one) as, appropriately, a u32 or u64. Rust calls these methods to_bits because that's what you get. Conveniently Rust doesn't need to care about byte order for these operations because no extant computer makes a different choice for its integer and float representations. Good.

You insisted you want char *, by which I understood you meant bytes. Rust can do that too, but now you need to care about byte order. Seeing another answer in this sub-thread I realise you actually meant you wanted a string which is doubly hilarious in a C++ thread. The char * is a pointer to a byte, C++ has actual strings (and, these days, even a passable fat pointer style string reference called std::string_view) and they're different.

It seems reasonable to pass around 32 bits in a u32 or 64 bits in a u64 rather than using arrays.

It is reasonable, but you must pay attention not to incur into undefined behaviour (which the post is about). An array of chars is the way to go for the C++ committee.

Here's one reason you might want to do this https://stackoverflow.com/questions/53882855/simple-explanat...

This bugs me as well, since there still isn't a general enough official solution, even with C++20's bit_cast. Unofficially, the C way of type punning(pointer conversions and unions) still works in probably all C++ compilers, but it's UB, so potentially dangerous.

I think most use cases for type punning fall in 2 categories: conversions between types with same size in memory, for writing or reading as a new type(ex. read an f32 as an u32) or accessing only a part of the data, like the first or the last 2 bytes in a u32.

Ideally, there would be a way to specify that a union is used for type punning and what conversion types are allowed (using something similar to concepts or constraints). That would probably solve most use cases and also allow the compiler to easily detect it.

>[type punning via enum] No; this works in C (since C99...?), but in C++ "it is undefined behavior to read from the member of the union that wasn't most recently written.

it is technically UB, but it works as a documented extension on pretty much every compiler.

It looks like it's okay even technically! From a section marked "(since C99)":

> If the member used to access the contents of a union is not the same as the member last used to store a value, the object representation of the value that was stored is reinterpreted as an object representation of the new type (this is known as type punning). [...] Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.

https://en.cppreference.com/w/c/language/union

I'm new to learning C. What exactly is the problem with uint32_t my_int = (uint32_t)my_float?

That is not a problem, it simply converts the float value to uint32. What the post mentions is `uint32_t my_int = (uint32_t)&my_float;`

That's a different problem: that simply convert a pointer to float to an uint32 (probably truncating it). What the post mentions is 'uint32_t my_int = *(uint32_t*)&my_float;

(Of course you had it right, and HN ate your formatting, but it is funnier this way)

That does a different thing. It converts the actual number represented by the float to an integer. We want to get an integer that contains the same bit pattern as the float.

Reply on news.ycombinator.com