recursive typedefs
Eric McQueen
ERICMC at USU.BITNET
Thu May 12 15:47:00 AEST 1988
Right to the point: Is
typedef char byte;
typedef unsigned byte u_byte;
ANSI-conforming? In the January Draft of ANSI C: Section 3.5.2, page 60,
requires that "Each list of type specifiers shall be one of the following...
|void|, |char|, |signed char|, ... |long double|, struct-or-union-specifier,
enum-specifier, or typedef-name". No provision is made for "|unsigned|
typedef-name" or any such "combination." I'm confident that
typedef char byte;
typedef unsigned char u_byte;
is valid but the first version above is the first version I tried. It seemed
more "maintainable," requiring only one change if I decide to change how signed
and unsigned bytes are represented. (I use the type "byte" to indicate values
that can fit in 8 bits but that I am doing arithmetic on, not text operations
-- this way I can redeclare "byte" to be "int" to get better speed in certain
situations.) VAX C (DEC's name for VMS C) didn't like the first version while
VAX C (DEC's name for Ultrix C) did. (Of course, they both liked the second
version.)
My best guess is that the first version is not ANSI-conforming. Does the
standard REQUIRE that the first form be rejected by a conforming compiler? My
gut feeling is that many pre-ANSI compilers allow the first form. I'll also
bet that this is a source of a few compiler bugs. Sounds much too much like
the old problem, when function prototypes were fairly new, of
typedef int arg;
int func( arg )
where the compiler writers couldn't decide whether they should interpret the
last "arg" as the name of a variable or as a type. So, does anyone KNOW
whether allowing "typedef char byte; typedef unsigned byte u_byte;" creates
nasty problems for a parser? (or does it just make it too hard to write a
nice concise standard?) Maybe I'll go back to using
#define byte char
#define u_byte unsigned byte
then I can use "#ifndef byte" and "-Dbyte=char" (/DEFINE:"byte=char" for you
VMS types).
I hate to threaten the long-standing tradition of knee-jerk posting to
produce 23 answers to my questions, most of which are only marginally correct,
but I *will* summarize responses I receive via E-mail to reduce the amount of
effort expended in the universe on sorting through "Re: recursive typedefs"
(maybe we'll slow down the irreversible increase in entropy?) (-:
[smiley included in attempt to avoid a long, heated discussion of physics in
the C group] I understand we're not a mainstream node, off on some obscure
network called BitNet, but we're trying -- we're even on Arpa now (just ask
Gehri) but no one knows it. Maybe I should give you the numeric address...
Anyway, if you're that sure you know THE answer and 40% of the network doesn't
feel the same way and know that you can't get here from there, go ahead and
post, what the hey. It wouldn't be the first time. I think we're all used to
it by now.
P.S. I agree with Julius A Cisek (jac423 at leah.Albany.Edu) from a while back:
> I just wanted to say that some of you are really a bunch of boneheads! I
> sparked off more replies by saying "The UNIX" and "The VAX" then by
> asking for help!!!
Thanks Julius, it needed saying. And so concisely too!
Don't get me wrong; I like usenet. I just wish people would notice what group
they are posting to and at least include *something* that is really relavent
to that group (and non-trivial and non-redundant) in the posting.
*sigh*
[smiley faces do not appear near all (admittedly poor) attempts at humor]
Thanks,
Eric Tye McQueen 220 N 200 E Also at (after some
ericmc at usu.bitnet P.O. Box 159 time in March[June?!]):
(801) 753-4683 Logan, Utah 84322 ericmc at cc.usu.edu
UUCP: ...{psuvax1,uunet}!usu.bitnet!ericmc "And now... The Toad Elevating
Arpa: ericmc%usu.bitnet at cunyvm.cuny.edu moment..." - M. Python
More information about the Comp.lang.c
mailing list