Hi folks,
I'm using C's "const" in its real meaning of "read-only" in a slightly
nonstandard way, to make certain global variables read/write in their own
file (and any other specific files I choose), while read-only elsewhere.
A specific example:
In file1.c (outside any functions):
int tablelength = 0;
char **stringtable = NULL;
(stringtable is then pointed to a block of memory allocated by
malloc/realloc, tablelength is updated with the number of char * pointers
in that table, and each pointer is pointed to a relevant string).
In file2.c:
extern const int tablelength;
extern const char * const * const stringtable;
(In this file, we can read tablelength, we can read the table at
*stringtable, we can read strings
stringtable[0]...stringtable[tablesize-1], but we get a friendly
compile-time error if we accidentally attempt to write to any of these.)
That's the setup I'm after, and I have it working at present using GCC
4.6.3 on Ubuntu.
I've verified that, if a function in file1.c called from file2.c has the
side-effect of changing one of these "const" variables, the code after the
function call does pick that up (the compiler isn't assuming they won't
change).
So, am I on reasonably solid ground doing this? Or am I inviting
pitfalls...? Can I rely on changes to those "const" global variables
being picked up at the next read, despite optimisations?
(This program is not threaded, and I don't expect it to be in future, so
that isn't a concern - though I'd be interested to hear if this raises
thread-related issues. I'd rather not have to use "volatile const" all
over the place, though that is possible, if need be.)
As a less important side question, is this likely to be non-portable?
Of course, if this is covered in documentation or in a previous question,
I'd be more than happy to look it up, if someone would be so kind as to
point me in the right direction.
Thanks,
Nikhil.
