0

It's hard to see code snippets and real code using const pointers in C.

By example:

FILE *fopen(const char *filename, const char *mode);

My question is. Why it appears to me, I may be worg in affirming this, that people usually don't use const pointers even when would make sense to use it? In my example fopen may have const pointers in both parameters.

I know how to use const and I know how it works. My question is more from an software engineering perspective and why people who write big libraries don't use it so much. Is there a reason not to use const pointers in professional code? Usually I only see a lot about const in books and code snippets.

chqrlie
  • 131,814
  • 10
  • 121
  • 189
Rodolfo
  • 149
  • 1
  • 9
  • 3
    use const whenever you can. But I suppose that we cannot rewrite the whole C library here at Stack Overflow. – Jean-François Fabre Feb 11 '17 at 22:22
  • Possible duplicate of [Use of 'const' for function parameters](http://stackoverflow.com/questions/117293/use-of-const-for-function-parameters) – cadaniluk Feb 11 '17 at 22:24
  • My question is. Is there a reason not to use const pointers in real and professional code? – Rodolfo Feb 11 '17 at 22:34
  • 1
    Backwards compatibility with pre-ANSI C? – ad absurdum Feb 11 '17 at 22:37
  • 2
    I'd say `const` does get used a lot, because it can be very useful, and many programmers appreciate that. It's not used everywhere it could be, it's true, because sometimes it's significantly more work, especially since when you start making some things const, you typically have to make lots more things const to compensate, and sometimes, one of them can't be, so you're stuck. (I think this is what people sometimes call "const poisoning".) – Steve Summit Feb 11 '17 at 22:39
  • @Rodolfo, nowdays there is no reason. – sheikh_anton Feb 11 '17 at 22:39
  • In your example, it would make no difference. Making `filename` and `mode` `const` is an implementation detail, not part of the API. So why add a pointless keyword to the declaration? – melpomene Feb 11 '17 at 22:44
  • In your example they are not const pointers. They are pointers to a const char – Fredrik Feb 11 '17 at 22:51
  • To make const pointers you write "char * const filename" – Fredrik Feb 11 '17 at 22:54
  • Some useful commentary at http://stackoverflow.com/questions/136880/sell-me-on-const-correctness, if you haven't seen it. – Steve Summit Feb 11 '17 at 23:28
  • @melponeme: of course it makes a difference: if the arguments are not `const` qualified, passing `const` strings triggers a well deserved warning. As a matter of fact, string literals should be `const` and most compilers can be configured to make them const. `-Wwrite-strings` for both gcc and clang does that. – chqrlie Feb 11 '17 at 23:37
  • In fact, the declaration of `fopen` from the C standard is `FILE *fopen(const char * restrict filename, const char * restrict mode);`; it seems like there are commenters implying that standard C has some other definition. – rici Feb 12 '17 at 00:16

1 Answers1

4

Early versions of C (well before the first ANSI standard in 1989) did not support const at all. So functions in the standard library, like fopen() were originally specified without the const qualifier.

In some professional settings, using old code and old compilers is still sometimes required for reasons of backward compatibility (although such cases are getting rarer as time advances, they still do exist, and for various reasons will continue to exist for some time). This requires that libraries used in those settings remain backward compatible.

Unless there is a specific constraint like this, it is preferable to write modern code using const appropriately (for example, to indicate that a function does not change an argument passed by pointer). That provides more opportunities to detect programmer error (e.g. a function that changes an argument, which the caller assumes is unchanged).

A common reason for code that doesn't use const is programmer (or, worse, customers) caring more about quick delivery - getting code delivered that compiles and passes a few test cases without error is priority number 1, but getting the code working properly in every possible contingency is considered much less important (or someone else's problem). In such a setting const causes more compilation errors (e.g. due to a function changing something tagged const) and therefore requires more effort and time to get the code compiling. Whereas omitting const means the code compiles more easily. Removing all instances of const in a code base (unless it uses third party libraries that are not available as source) is quite easy with modern text editors and IDEs - and can superficially cause the number of compilation errors to drop. Conversely, it is more difficult to identify all the places in code where const is useful, and the most likely immediate reward for increasing usage of const in a code base is needing to do more work to fix code that then doesn't compile.

In other words, the benefits of const are not immediate, so do not matter to developers/managers/customers with a short term "deliver or die" mentality, who will not have to subsequently fix the problems they leave behind.

Peter
  • 35,646
  • 4
  • 32
  • 74
  • 1
    Quick fix for die hard obsolete compilers: `#define const`. There is no decent reason to not use `const` qualified pointers. Declaring `const` local variables and arguments such as `const int i = 3` or `const char * const filename` is much less useful and leads to unnecessary clutter. – chqrlie Feb 11 '17 at 23:42
  • You're thinking in the wrong direction. If the code only targets a hardware platform for which there is one compiler that doesn't support `const`, things like `#define const` give no benefit. Most such examples are in a regulated application domain, so it would be necessary to also document a justification that such a macro doesn't change the behaviour of any code in the system. Forcing people in tight regulatory domains to use `const` when it actually has no meaning to their compiler, will make the regulatory burden of that software higher. – Peter Feb 12 '17 at 00:07
  • the `#define const` would only be defined if the compiler does not support the `const` keyword. As long as the code does not use `const` as an identifier nor elide type information as in `const a = 1;`, it should be OK to remove the effect of `const` with the preprocessor. A command line definition `-Dconst=` would have the same effect without the need to patch the source files. C compilers that do not support `const` are bound to be so out of date that the language they implement is a distant cousin of C. I wouldn't want to work in such a constrained environment... – chqrlie Feb 12 '17 at 16:20