6 ms·

I wrote and still maintain an open source C project for 20+ years. Once a year I get a new guy coming in and telling me I am doing it wrong: you should typedef

by lsh123 3y ago

I wrote and still maintain an open source C project for 20+ years. Once a year I get a new guy coming in and telling me I am doing it wrong: you should typedef all data types, you should stop using const, and so on. It stopped being funny after the first couple times.

laserbeam 3y ago
I'm getting an "I don't use const, and here's my view on it" vibe from the author much more than "you shouldn't use const". I'm really not getting any demand that you change your coding style, just someone reflecting on their work and explaining it to others. And... Whether I agree with their choices or not, I find that very cool and informative.
- SoftTalker 3y ago
  And, he also says "I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style."
- outsomnia 3y ago
  It wasn't clear to me if he's talking about const as a variable declaration qualifier - I never used it - or const in pointer types, which is very useful.
  - jstimpfle 3y ago
    For me it's the other way around -- I use const for global variables because it makes a real difference, the data will be put in a .ro section. Pointer-to-const on the other hand (as in "const Foo *x") is a bit of a fluff and it spreads like cancer. I agree with the author that const is a waste of time. And it breaks in situations like showcased by strstr(). I use pointer-to-const in function parameter lists though (most of the time it does not actually break like in strstr()): as documentation, and to be compatible with code that zealously attaches const everywhere where there (currently) is no need to mutate. But overall my use of const is very very little and I generally do not waste my time (anymore) with it. I almost never have to use "const casts" so I suppose I can manage to keep it in check. In C++ it is a bit worse, when implementing interfaces, like const_iterator etc. That requires annotating constness much more religiously, and that can lead to quite a bit of cruft and repetition.
    - outsomnia 3y ago
      You're right, I also mark array definitions as const to control the section they go in, I was thinking about things like const int a = 5; ... anything I want a simple const var for is done with #define for me. const is indeed viral when eg, used in apis, but it's a strong indication at a glance for api users what they can expect to happen to the memory the pointer points to, whether it's just for input or is modified... and the virality is only a pain (it can be a pain) if you didn't use it from the start so all the things it might call are already kitted out with it.
      - jstimpfle 3y ago
        const makes sense and rarely causes problems when used in function parameter lists. However, when used for members in datastructures, it's more often than not problematic.
    - deleted 3y ago
      [deleted]
  - P_I_Staker 3y ago
    It's kinda both for me. If you have certainty from top to bottom that something will always be const, then maybe. This is often not true, and even if you think so, you're often wrong. I can't recall all the consequences of the flaws in the system (promote/demote const), but it's not fun to deal with. I've seen so many things wind up passed to a function or going through an interface eventually that's non-const (or lets not forget is "const'd for safety"). This is where some would say you should give up on practical grounds... if the mission is to determine which const scenarios can be ensured, you argue this is not practically possible and throw the whole thing out.
- P_I_Staker 3y ago
  I will say that using const can make a huge mess of code, especially if you care about adhering to (very reasonable) guidelines. There's a really good chance you will either have to promote or cast away the const, which I hate. I tend to agree regarding not using const. It's been a while, so I don't have an example off the top of my head, but it's incredibly easy to break the const mechanism and have to deal with these annoying flaws. I've just seen this go really bad with any kind of code that has a split responsibility between teams. Eventually you will have to pass to a non-const interface, that you aren't supposed to change. So perhaps it makes sense if you have control from the top down and can ensure that the constness is maintained, or completely not, if it ends up non-const (then you could also try to move the interface to const, if it truly is)... ... I also suspect in many projects you'd just have to come to the conclusion that nothing can be const'd, because it ends up non-const anyway. Thus leading to the conclusion "just don't use const". P.S. I'm a bad boy that didn't read TA yet. This is just based on my past experience where we didn't really have the authority to change stuff in the stack... often times there was eg an MCU interface at the end that was non-const... guess we could contact the silica manufacturer... sure they'll get right on that.
rewgs 3y ago
I'm not a C developer, so I have to ask: why in the world would you not use const?
- jstimpfle 3y ago
  It's more work. Not only to put all the annotations correctly, but only because it causes some real headaches. It's easy (implicit) to transition from non-const to const 1 pointer level deep. But the other way around -- it's really awkward to "remove" a const. The strstr() signature is probably the shortest example / explanation why. To implement strstr(), you have to hack the const away to create the return value. Alternatively, create a mutable_strstr() variant that does the exact same thing. This is the kind of boilerplate that we don't want in C (and that C is bad at generating automatically). Think about it this way: Real const data doesn't exist. It always gets created (written) somewhere, and usually removed later. One way where this works cleanly is where the data is created at compile time, so the data can be "truly" const, and be put in .ro section, and automatically destroyed when the process terminates. But often, we have situations where some part of the code needs to mutate the data that is only consumed as read only by other parts of the code. One man's const data is another man's mutable data. In C, the support for making this transition work fluently is just very limited (but I think it's not great in most other languages, either).
  - mmoll 3y ago
    > Real const data doesn't exist Ever seen a ROM? And the C library‘s hacks around not being able to overload functions (which is the only reason for strstr et al‘s weird signature) wouldn‘t stop me from using const. It can be really useful both for documentation and for correctness. Think memcpy, not strstr.
    - jstimpfle 3y ago
      > Ever seen a ROM? How does the data get onto the ROM? But read 2 sentences further, where I had addressed this already. > Think memcpy, not strstr. See my other comments, I do think that making const function parameters is generally good for documentation and compatibility. strstr() is only a showcase for the limitations. Typically, const works for function parameters but not data structures.
f1shy 3y ago
Funny enough, the take on const in the only thing I agree with in the whole post…
- rurban 3y ago
  I"m even not agreeing with the const part. The standard did define const API"s, so why shouldn"t we follow? I know that C const are only half of C++ consts, but still. Still catching const errors somewhere because I do use const in APIs. I only agree with "Declare all functions static except for entry points". s8(s) is only for literal strings, it should be called s8_c instead and keep s8 for the default ctor. The struct return part is okay, but I"ve never used. This is not Common Lisp.
  - AdamH12113 3y ago
    Can you explain the static functions thing? What’s the benefit of declaring all functions static if you’re compiling them as a single translation unit anyway?
    - f1shy 3y ago
      Static means only visible for that translation unit. So they are not global. Only global inside the file.
    - lelanthran 3y ago
      You don't get the linker complain of multiply defined symbols when your code is linked in as a library to some other project. If you're writing code that never gets reused, then it's fine, no need for static functions.

by lsh123 3y ago

laserbeam 3y ago

I'm getting an "I don't use const, and here's my view on it" vibe from the author much more than "you shouldn't use const". I'm really not getting any demand that you change your coding style, just someone reflecting on their work and explaining it to others. And... Whether I agree with their choices or not, I find that very cool and informative.

SoftTalker 3y ago
And, he also says "I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style."
outsomnia 3y ago
It wasn't clear to me if he's talking about const as a variable declaration qualifier - I never used it - or const in pointer types, which is very useful.
- jstimpfle 3y ago
  For me it's the other way around -- I use const for global variables because it makes a real difference, the data will be put in a .ro section. Pointer-to-const on the other hand (as in "const Foo *x") is a bit of a fluff and it spreads like cancer. I agree with the author that const is a waste of time. And it breaks in situations like showcased by strstr(). I use pointer-to-const in function parameter lists though (most of the time it does not actually break like in strstr()): as documentation, and to be compatible with code that zealously attaches const everywhere where there (currently) is no need to mutate. But overall my use of const is very very little and I generally do not waste my time (anymore) with it. I almost never have to use "const casts" so I suppose I can manage to keep it in check. In C++ it is a bit worse, when implementing interfaces, like const_iterator etc. That requires annotating constness much more religiously, and that can lead to quite a bit of cruft and repetition.
  - outsomnia 3y ago
    You're right, I also mark array definitions as const to control the section they go in, I was thinking about things like const int a = 5; ... anything I want a simple const var for is done with #define for me. const is indeed viral when eg, used in apis, but it's a strong indication at a glance for api users what they can expect to happen to the memory the pointer points to, whether it's just for input or is modified... and the virality is only a pain (it can be a pain) if you didn't use it from the start so all the things it might call are already kitted out with it.
    - jstimpfle 3y ago
      const makes sense and rarely causes problems when used in function parameter lists. However, when used for members in datastructures, it's more often than not problematic.
  - deleted 3y ago
    [deleted]
- P_I_Staker 3y ago
  It's kinda both for me. If you have certainty from top to bottom that something will always be const, then maybe. This is often not true, and even if you think so, you're often wrong. I can't recall all the consequences of the flaws in the system (promote/demote const), but it's not fun to deal with. I've seen so many things wind up passed to a function or going through an interface eventually that's non-const (or lets not forget is "const'd for safety"). This is where some would say you should give up on practical grounds... if the mission is to determine which const scenarios can be ensured, you argue this is not practically possible and throw the whole thing out.
P_I_Staker 3y ago
I will say that using const can make a huge mess of code, especially if you care about adhering to (very reasonable) guidelines. There's a really good chance you will either have to promote or cast away the const, which I hate. I tend to agree regarding not using const. It's been a while, so I don't have an example off the top of my head, but it's incredibly easy to break the const mechanism and have to deal with these annoying flaws. I've just seen this go really bad with any kind of code that has a split responsibility between teams. Eventually you will have to pass to a non-const interface, that you aren't supposed to change. So perhaps it makes sense if you have control from the top down and can ensure that the constness is maintained, or completely not, if it ends up non-const (then you could also try to move the interface to const, if it truly is)... ... I also suspect in many projects you'd just have to come to the conclusion that nothing can be const'd, because it ends up non-const anyway. Thus leading to the conclusion "just don't use const". P.S. I'm a bad boy that didn't read TA yet. This is just based on my past experience where we didn't really have the authority to change stuff in the stack... often times there was eg an MCU interface at the end that was non-const... guess we could contact the silica manufacturer... sure they'll get right on that.

rewgs 3y ago

I'm not a C developer, so I have to ask: why in the world would you not use const?

jstimpfle 3y ago
It's more work. Not only to put all the annotations correctly, but only because it causes some real headaches. It's easy (implicit) to transition from non-const to const 1 pointer level deep. But the other way around -- it's really awkward to "remove" a const. The strstr() signature is probably the shortest example / explanation why. To implement strstr(), you have to hack the const away to create the return value. Alternatively, create a mutable_strstr() variant that does the exact same thing. This is the kind of boilerplate that we don't want in C (and that C is bad at generating automatically). Think about it this way: Real const data doesn't exist. It always gets created (written) somewhere, and usually removed later. One way where this works cleanly is where the data is created at compile time, so the data can be "truly" const, and be put in .ro section, and automatically destroyed when the process terminates. But often, we have situations where some part of the code needs to mutate the data that is only consumed as read only by other parts of the code. One man's const data is another man's mutable data. In C, the support for making this transition work fluently is just very limited (but I think it's not great in most other languages, either).
- mmoll 3y ago
  > Real const data doesn't exist Ever seen a ROM? And the C library‘s hacks around not being able to overload functions (which is the only reason for strstr et al‘s weird signature) wouldn‘t stop me from using const. It can be really useful both for documentation and for correctness. Think memcpy, not strstr.
  - jstimpfle 3y ago
    > Ever seen a ROM? How does the data get onto the ROM? But read 2 sentences further, where I had addressed this already. > Think memcpy, not strstr. See my other comments, I do think that making const function parameters is generally good for documentation and compatibility. strstr() is only a showcase for the limitations. Typically, const works for function parameters but not data structures.

f1shy 3y ago

Funny enough, the take on const in the only thing I agree with in the whole post…

rurban 3y ago
I"m even not agreeing with the const part. The standard did define const API"s, so why shouldn"t we follow? I know that C const are only half of C++ consts, but still. Still catching const errors somewhere because I do use const in APIs. I only agree with "Declare all functions static except for entry points". s8(s) is only for literal strings, it should be called s8_c instead and keep s8 for the default ctor. The struct return part is okay, but I"ve never used. This is not Common Lisp.
- AdamH12113 3y ago
  Can you explain the static functions thing? What’s the benefit of declaring all functions static if you’re compiling them as a single translation unit anyway?
  - f1shy 3y ago
    Static means only visible for that translation unit. So they are not global. Only global inside the file.
  - lelanthran 3y ago
    You don't get the linker complain of multiply defined symbols when your code is linked in as a library to some other project. If you're writing code that never gets reused, then it's fine, no need for static functions.