Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some C habits I employ for the modern day

unix.dog

Post reply on HN
Print view View original

61–70 of 162 posts

Re: Some C habits I employ for the modern day

#61

Post by _zagj »

tom_ wrote: post #17

If you really insist on not having a distinction between "u8"/"i8" and "unsigned char"/"signed char", and you've gone to the trouble of refusing to accept CHAR_BIT!=8, I'm pretty sure it'd be safer to typedef unsigned char u8 and typedef signed char i8. uint8_t/int8_t are not necessarily character types (see 6.2.5.20 and 7.22.1.1) and there are ramifications (see, e.g., 6.2.6.1, 6.3.2.3, 6.5.1).

> and you've gone to the trouble of refusing to accept CHAR_BIT!=8

This one was a head-scratcher for me. Yeah, there's no cost to check for it, but architectures where CHAR_BIT != 8 are rarer even than 24-bit architectures.

Re: Some C habits I employ for the modern day

#62

Post by pjmlp »

procaryote wrote: post #59
pjmlp wrote: post #48

Earlier quoted context omitted.

I started doing that in 1993 on MS-DOS already, thanks to C++ RAII, C felt outdated already on those days.

Arguably, 1993's C has survived better than 1993's C++.

Well in 33 years it has learnt nothing about memory safe programming, at least C++ provides the tooling for those that care, before even goverments decided to act upon it.

Re: Some C habits I employ for the modern day

#64

Post by procaryote »

jcalvinowens wrote: post #14

#if CHAR_BIT != 8 #error "CHAR_BIT != 8" #endif In modern C you can use static_assert to make this a bit nicer. static_assert(CHAR_BIT == 8, "CHAR_BIT is not 8"); ...although it would be a bit of a shame IMHO to add that reflexively in code that doesn't necessarily require it. https://en.cppreference.com/w/c/language/_Static_assert.html

Even if the code might not end up requiring it, if you write it with the assumption that bytes are 8 bits, it's good to document that with a static assert so someone porting things knows there will be dragons

It's a pretty neat way to drop some corner cases from your mental load without building subtle traps

Re: Some C habits I employ for the modern day

#65

Post by pjmlp »

lelanthran wrote: post #56
pjmlp wrote: post #49

Earlier quoted context omitted.

C23 + is hardly simpler as people advocate.

> C23 + is hardly simpler as people advocate. Well, certainly simpler than C++, at any rate. I mean, just knowing the assignment rules in C++ is worthy of an entire book on its own. Understandably, the single rule of "assignment is a bitwise copy of the source variable into the destination variable" is inflexible, but at least the person reading the local code can, just from the current scope, determine whether some…

Where do you think the first generations from C++ programmers come from?

There is this urban myth C is simple, from folks that never read either ISO C manual, can't read legalese, never spent much time browsing the compiler reference manual.

Mostly learnt K&R C, assume the world is simple, until the code gets ported into another platform or compiler.

Yet in such a simple language, I keep waiting to meet the magical developer that never wrote memory corruption errors with pointer arithmetic, string and memory library functions.

Re: Some C habits I employ for the modern day

#67

Post by danhau »

moth-fuzz wrote: post #60

I'm a huge fan of the 'parse, don't validate' idiom, but it feels like a bit of a hurdle to use it in C - in order to really encapsulate and avoid errors, you'd need to use opaque pointers to hidden types, which requires the use of malloc (or an object pool per-type or some other scaffolding, that would get quite repetitive after a while, but I digress). You basically have to trade performance for correctness, wherea…

> But then anyone could just instantiate an invalid Name without calling the parse_name function and pass it around wherever

This is nothing new in C. This problem has always existed by virtue of all struct members being public. Generally, programmers know to search the header file / documentation for constructor functions, instead of doing raw struct instantiation. Don‘t underestimate how good documentation can drive correct programming choices.

C++ is worse in this regard, as constructors don‘t really allow this pattern, since they can‘t return a None / false. The alternative is to throw an exception, which requires a runtime similar to malloc.

Re: Some C habits I employ for the modern day

#68

Post by lelanthran »

pjmlp wrote: post #65
lelanthran wrote: post #56

Earlier quoted context omitted.

> C23 + is hardly simpler as people advocate. Well, certainly simpler than C++, at any rate. I mean, just knowing the assignment rules in C++ is worthy of an entire book on its own. Understandably, the single rule of "assignment is a bitwise copy of the source variable into the destination variable" is inflexible, but at least the person reading the local code can, just from the current scope, determine whether some…

Where do you think the first generations from C++ programmers come from? There is this urban myth C is simple, from folks that never read either ISO C manual, can't read legalese, never spent much time browsing the compiler reference manual. Mostly learnt K&R C, assume the world is simple, until the code gets ported into another platform or compiler. Yet in such a simple language, I keep waiting to meet the magical d…

> There is this urban myth C is simple, from folks that never read either ISO C manual, can't read legalese, never spent much time browsing the compiler reference manual.

And yet you know from previous discussion with folks like Uecker and myself have done all those things, and still walked away from C++.

In my case, I stepped back even after having a decade of work experience in it. Anything needing more abstraction than C, C++ is not going to be a good fit anyway (there's better languages).

> Yet in such a simple language, I keep waiting to meet the magical developer that never wrote memory corruption errors with pointer arithmetic, string and memory library functions.

Who made that claim? This sounds like a strawman - "If you use C you'll never make this class of errors", which no one said in this conversation.

In any case, the point is even more true of C++ - I have yet to meet this magical C++ programmer that never hits the few dozens of footguns it has that C doesn't.

Re: Some C habits I employ for the modern day

#69

Post by apaprocki »

_zagj wrote: post #58
apaprocki wrote: post #33

Please don’t buy into “no const”. If you’ve ever worked with a lot of C/C++ code, you really appreciate proper const usage and it’s very obvious if a prototype is written incorrectly because now any callers will have errors. No serious reusable library would expose functions taking char* without proper const usage. You would never be able to pass a C++ string c_str() to such a C function without a const_cast if that…

Where is the author advocating not using const or casting it away?

“modified 2026-01-17T23:20:00Z”

Seems it was cast away

Re: Some C habits I employ for the modern day

#70

Post by SkiFire13 »

> Additionally, the intent of whether the buffer is used as “raw” memory chunks versus a meaningful u8 is pretty clear from the code that it gets used in, so I’m not worried about confusing intent with it.

It's generally not clear to the compiler, and that can result in missed optimization opportunities.

Post reply on HN