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