Thanks for the insight! The stated rational in the replies, and the quote from
The Practice of Programming make sense - using enum to create constants sounds
like a good practice to adopt, even outside of the Plan 9 code base.
After Alexander's reply, I ran grep over the Plan 9 code to search for source
where an enum is defined with a tags and its quite interesting how constants
are handled in the different ways, even within the same source file.
Take for example the source code for sed, linked above by Alexander. The sed
source makes use of untagged enum, tagged enum, and defined constants in the
same file! My best guess is this is due to historical reasons (code ported over
from the Unix days)?
*/sys/src/cnd/sed.c:9*
**enum {
DEPTH = 20, /* max nesting depth of {} */
MAXCMDS = 512, /* max sed commands */
ADDSIZE = 10000, /* size of add & read buffer */
MAXADDS = 20, /* max pending adds and reads */
LBSIZE = 8192, /* input line size */
LABSIZE = 50, /* max number of labels */
MAXSUB = 10, /* max number of sub reg exp */
MAXFILES = 120, /* max output files */
};
*/sys/src/cnd/sed.c:55*
*#define ACOM 01
#define BCOM 020
#define CCOM 02
#define CDCOM 025
#define CNCOM 022
#define COCOM 017
*
*/sys/src/cnd/sed.c:109* (provided above by Alexander)
* enum PTYPE { /* Either on command line or in file */
P_ARG,
P_FILE,
} type;*
The Plan 9 kernel sources (and Ken's C compiler) look more consistent - they
only make use of untagged enum.
However, even those files mix #define with enum for defining constants. I know
in ANSI C, if one wants an enum with a particular type (say, long instead of
int or short), the only way to force this is via a #define with a cast of 'L'
'LL' prefix (in ANSI C the type of an enum is implementation dependent, and
must fit within within int).
I assume the Plan 9 Compiler doesn't have this problem, or never needs to worry
about it? Are the instances of #define just an oversight, or is there an
underlying reason for the inconsistency?
While I don't wish to trouble the mailing list with numerous questions about
opinions and design decisions that were made over 20 years ago, I must admit
the more I read through the source code of Plan 9 and it's compiler the more
intrigued I am, the more questions and curiosity I uncover : )
The Plan 9 documentation contains ample information on extensions made to, and
omissions from, ANSI C - but I can't find any documentation (or even mailing
list posts) about the rational/motivations for some of those extensions, and
any retrospective on what worked well and what didn't if such a thing exists.
For example, one can assume struct (and union) embedding proved to be a useful
and elegant solution to some class of problems, given the feature makes a
reappearance in Go. Is the the original problem that sparked idea/use case of
embedding types lost to history?
There are further curiosities in Ken's compiler, for example the signof
operator's sole purpose (as far as I can tell via grepping the code) is for
type checking by the linker - but did the authors have in mind other uses for
signof, such as a weak version of the Go's reflect package, or would this be
seen as a perversion of the signof operator?
I suppose its unlikely the answers and retrospectives to these questions were
ever documented back in the day regarding Plan 9 and it's C dialect ? Of
course, I don't expect Rob et al. to spend their time answering all these now -
I'm grateful enough to have received a reply to on of my questions above : )
Thanks again,
- Ankush
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T17a31ae1d8c1feb4-M284419fb4433eeece6adc6df
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
