const char* typedefs

[Paige DePol <lual@...>]

I was doing a bit of a code audit when I had a thought...

Why not create a typedef for 'const char*' to save some space in the code:

typedef const char* l_str

There were already some functions that began with 'l_str' for conversion or
for Lua versions of C string utility functions, so it seemed logical.

As there were 697 matches in my current code base and the typedef is 6 or 7
letters shorter, depending on the position of the *, that saves nearly 5000
characters. Yes, not really a big deal, but what it does do is help things
fit into 80 columns better by providing extra space in functions with a lot
of 'const char*' parameters, or variables, or typecasts. I have made this
change to my code base and it really does make a number of functions tidier
due to the extra space.

I did some searching and generally it is advised to not hide pointers behind
typedefs, unless the data type is opaque. I would say that C strings should
qualify for this treatment and in my opinion it really works well.

I also note that Lua itself has a typedef that also hides the pointer:

typedef TValue *StkId;

I don't see any reason why this shouldn't be an okay thing to do, but in
my searching I mostly found warnings about not doing it... usually for other
data types, and not const char*... so thought I'd check to see what opinions
there were, or to see if I am violating some unwritten coding style rule! ;)


I also found a potential missing 'const' in gc_state() from 'ltests.c':

  static const char *statenames[] = {"propagate", "atomic", "sweepallgc",

Shouldn't that be as follows to match all other static lists of C strings:

  static const char *const statenames[] = {"propagate", "atomic", "sweepallgc",


Unless there is some serious reason for not typedefing 'const char*' I think
I will go with it as I do think it is an improvement in code readability!

~Paige