On Mon, Jan 7, 2013 at 10:31 AM, Nikhil Nair <nnair@xxxxxxxxx> wrote: > > 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. Referring to the same variable using different types in different compilation units is undefined behaviour. You can't rely on this working, and it is not portable. The compiler is free to assume that a variable declared with type "extern const T" will never change; any change to that object is undefined behaviour. For example, the compiler may load the value into a register and reuse that register across function calls. Ian
