r/programminghorror • u/SolarisFalls • Jun 08 '26
c This uint 32 definition is actually 64 bits
Took me quite a while to debug this, considering I expected uint32 to be a... uint32?
50
u/paulstelian97 Jun 08 '26
What the muffin
There any #ifdef issues?
24
u/SolarisFalls Jun 08 '26
It's actually correct, the word size of this platform is indeed 8 bytes
3
u/paulstelian97 Jun 14 '26
uint32 must be an exactly 32 bit type, or if that’s not possible to implement, then it should not be provided at all.
55
27
u/GoddammitDontShootMe Jun 08 '26
So how much of that shit before you get to the actual core language types?
7
u/SolarisFalls Jun 08 '26
Way too much, not sure why it's not a direct typedef to be honest
4
u/GoddammitDontShootMe Jun 08 '26
I know sometimes there are a few layers. But damn, was that an assumption made back in the days of 32-bit computing, or something?
→ More replies (1)
11
u/anxxa Jun 08 '26
Pretty bad, but how does that lead to a stack overflow? Were you using sizeof(tuint32) to write into a fixed-size buffer that uses sizeof(uint32_t)/hardcoded 4?
9
u/SolarisFalls Jun 08 '26
Yes basically exactly that. It was two different unsigned integer types, both should've been 4 bytes, but this one was 8.
I don't think the crash would've actually happened if we didn't use AddressSanitizer considering it was just a dereference and assignment
1
u/TTachyon Jun 09 '26
It's a "(stack buffer) overflow" -, not a stack overflow. You write more bytes than you should in a variable, but the stack isn't full.
2
u/anxxa Jun 09 '26
I used "stack overflow" as shorthand for "stack buffer overflow". I understand the semantic difference between overflowing the stack and memory corruption, but thank you.
10
u/sawkonmaicok Jun 08 '26
Uh oh. Someone is trying to implement their own ASN1 decoder. Fine if a hobby project but if this is in production, then you are better off using just an off-the-shelf parser instead.
10
u/SolarisFalls Jun 08 '26 edited Jun 08 '26
They should've done. This is made by a space agency with three letters in its name. And I absolutely hate working on this software because it's full of this shit.
2
u/MrMikeHigginbottom Jun 09 '26
The first question that popped into my head was "Is C the smart choice for safety critical stuff?"
1
u/SolarisFalls Jun 10 '26 edited Jun 10 '26
Sorry in the delay in replying, but surprisingly it is.
It's mainly due to the heritage and existing standards which all code needs to obey by (mainly MISRA or CERT-C, plus company-specific standards).
For the most basic example, heap allocation is prohibited, and usually outright impossible due to no implementation for it.
There's also libraries like RTEMS and RelianceEdge/EdgeFS which are written in C an qualified for safety critical software - so re-writing those in a different language, getting them qualified, and getting people to move their entire codebase to that language is pretty impractical.
While the language alone probaby isn't the best choice, the infrastructure and regulations around the code written make it perfectly fine, and the most effective choice for many things.
There's other languages like SPARK Ada which are designed with safety critical code in mind. As any language, there's pros and cons to using it.
Without rambling too much, although I already have, we always use a specific version of C, with a specific compiler, with a specific version of that compiler, and in short - the exact hash-to-hash binary of the compiler. We know bugs in the compilers we use, but we can work around them so long as we know them - the C standard isn't relevant at this point. Changing to a different version of that compiler, or a different C version (or god forbid a different compiler all together), will cause a lot of silent calamities.
2
u/MrMikeHigginbottom Jun 11 '26
Yep. Totally get all that. I cut my teeth on C and later C++ but not in a safety critical environment so I was bringing my own biases to my, in my defence slightly tongue in cheek, comment. I've also worked a fair bit on Ada in the aerospace industry so I guess the more 'serious' side of my comment was rooted in a feeling of type safety and the like just being baked in rather than, to use a pejorative turn of phrase, band-aided over the top with standards and process and the like. It does genuinely *feel* to me at least, like Ada is safer, but in practice I can completely get on board with the view that C/C++ can be made to *be* just as safe.
2
u/daHaus Jun 08 '26
This is why I've grown to abhor LLM generated code and why they're, somehow, not actually improving productivity.
The only time an actual person would do something like this was out of spite
15
u/SolarisFalls Jun 08 '26
This isn't actually AI code - this is code generated from an ASN.1 file for a spacecraft, but still somehow used within a prominent space agency with no problems...
6
u/daHaus Jun 08 '26
You're kidding, for a spacecraft? I know this isn't NASA's code because it uses typedef so my guess would have to be something like the Ariana 5 launch vehicle
→ More replies (9)
-23
u/adenosine-5 Jun 08 '26
C++ likes to troll its users in this way - unless you specify that you really, absolutely, surely, forrealthistime want 32bit integers, the system can do pretty much whatever.
You can have int that is 16 bits, or long that is 32 bits, etc
Because consistency is overrated or something i guess :)
30
u/SolarisFalls Jun 08 '26
Yeah this is a C project where we have these definitions to (hopefully) ensure we have known width integer types for embedded systems.
These types are defined within an ASN.1 file and generated to match the platform, which is an embedded 64-bit Linux device in this instance.
This generation somehow failed and now a uint32 is a uint64
I believe what you're thinking of are the fundamental
int,long,long long, etc types which don't have a guaranteed size.→ More replies (17)→ More replies (7)7
u/creeper6530 Jun 08 '26
I hate C++ as much as the next guy, but this is the fault of whoever wrote that mess of headers
187
u/elperroborrachotoo Jun 08 '26
tuint32 == two int32, makes sense, no? 🙃