Martin Uecker has started a new initiative to ensure a better const contract for C2y: change the type of string literals to a const-qualified base type, much as it is already the case in C++. Compilers support this since a very long time; some of them have this as default, some provide command line switches for that model.
Nevertheless, this would be normative change and might be some burden for existing code. So, before doing this and writing papers, it would be good if we had an idea of the impact of such a change in existing code bases. I would be very grateful if we’d receive feedback from you along the lines of
- You have a project that already uses options such as gcc’s
-Wwrite-strings(or even a compiler with such a default) to have all string literalsconst-qualified. - You have a project and you tested it with such options and introducing this change would be easy. (If so does this change expose some qualification bugs in your code base?)
- You have a project and you tested it with such options, but introducing this permanently into your code base would be a real pain.
- Your project does not care about
constand you wouldn’t even know where to begin. If it were introduced in a future version of C, you probably you would have to use the command line to switch such a feature off.
The goal here is not to have an opinion poll or similar; I am not convinced that such polls on some random blog like mine have any particular meaning. I really like to have facts first, not opinions:
- If it is open source, please give a pointer to your project. Otherwise, please describe your project e.g if it is a commercial product of your company or employer. But please, do not share confident information that could get you in trouble.
- Report on your experience with these kind of options for
constqualification. - Don’t speculate about what could happen, restrict yourself to facts.
Jens Gustedt's Blog 
7 responses to “Make C string literals const?”
I used writable strings in my 1988 ioccc submission [1],
before i was even aware that string literals could be anything other than writable.
it not made my program a little shorter, allowing a much more aesthetically pleasing layout,
but of course also helped to obfuscate it.
[1] https://tromp.github.io/pearls.html#maze
@gustedt.wordpress.com I tested this on gwsh (a fork of dash), <https://github.com/hvdijk/gwsh>, introducing this would be a bit of a pain without matching POSIX library changes. In calling execve(), the second argument is a pointer to an array of char*. Some elements of this array are string literals. Unless execve() is changed to accept an array of const char*, calling execve() with string literals would require casting away const, and would prevent -Wcast-qual from being used.
@gustedt.wordpress.com
Just checked -Wwrite-strings w/ PostgreSQL.
Pobably doable, but it'd rather painful.
Main sources of pain:
– external APIs that where introducing const would cause warnings in users of postgres, which we don't control
– gettext("translateme") returns char *, but if localization is disabled, it ends up as a bare "translateme", we'd have to cast const away
– lots of "cascading" changes, where adding const in one corner requires lots of others
@gustedt.wordpress.com
– reasonably common pattern of assigning sometimes a constant string, sometimes a dynamically formatted string. In the latter case string is freed, as tracked by a separate var.
I'd guesstimate it'd end up a ~~5kloc change. Most of the affected code would be older, newer code tends to be more const careful.
@gustedt.wordpress.com Samba has had wrire-strings in developer builds for the last 11 years. Don't recall it being an issue. http://www.damba.org
@gustedt.wordpress.com sigh https://samba.org
I tried the flag on the OCaml compiler. This mostly lead to adding const to functions taking char * parameters that we gave string literals to, and constify-ing static data. See Constify function parameters and other variables #13470 and its d11b492. I haven’t turned the warning globally because of some unresolved issue: Fix memory leaks in bytecode backtraces debug information #13385.