Potential side-effects/stability of deliberately inconsistent use of const, in C

[Nikhil Nair]

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.