ERICMC@USU.BITNET (Eric McQueen) (05/12/88)
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@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@usu.bitnet P.O. Box 159 time in March[June?!]):
(801) 753-4683 Logan, Utah 84322 ericmc@cc.usu.edu
UUCP: ...{psuvax1,uunet}!usu.bitnet!ericmc "And now... The Toad Elevating
Arpa: ericmc%usu.bitnet@cunyvm.cuny.edu moment..." - M. PythonERICMC@USU.BITNET (Eric McQueen) (05/18/88)
In a previous article I asked: > Is > typedef char byte; > typedef unsigned byte u_byte; > ANSI-conforming? (The answer is "No") Two responses came by mail. Since the first is so short, both follow in almost their entirety. ) From: chris%MIMSY.UMD.EDU@UMD2.BITNET 12-MAY-1988 06:04 ) ) My own feeling is that it should be legal. The argument against ) it is that it is not obvious what this means: ) ) typedef int (*pfi)(); ) typedef unsigned pfi upfi; ) ) and I believe that because of this argument, it is explicitly ) illegal. Certainly the `#define's are safer. ) ) Chris ] From: Scott Daniels <daniels%teklds.tek.com@RELAY.CS.NET> 14-MAY-1988 04:49 ] Organization: Tektronix, Inc., Beaverton, OR. ] ] As to opinions with any "real" knowlege: I expect "typedef unsigned byte x;" ] is not acceptable ANSI C. It is certainly not a necessary feature, and it ] complicates the life of some methods of implementing a type system. The ] problem might be a bit clearer with the following example: ] typedef char CHAR; ] typedef unsigned char UCHAR; ] typedef signed char SCHAR; ] ] typedef unsigned CHAR uC; ] typedef unsigned UCHAR uUC; ] typedef unsigned SCHAR uSC; ] If the final three typedefs above are not all illegal, which ones are? ] It might be much easier on a compiler to use the same representation for CHAR ] and SCHAR on a signed char machine, and the same representation for CHAR and ] UCHAR on an unsigned char implementation. By the way, I would define your ] types as follows: ] typedef signed char byte; ] typedef unsigned char u_byte; ] typedef char u_tiny; /* use these for 0-127 */ ] ] As to whether a complaint should be issued, I am sure the X3J11 response ] would be "that is a quality of implementation issue". I would argue (and ] have argued) that a C compiler that correctly compiles conforming source and ] does something bizarre (like emitting bad code with no output text) for non- ] conforming source could be called an ANSI-C conforming compiler. C has been ] used in several (make that many) language experiment projects as a kind of ] portable assembly language. I would certainly buy a "no error messages" C ] compiler if I were using it as the back end of my fancy _functional_object- ] oriented_constraint-based_expert_system_. In such a system I would rather ] not spend the compilation time or "core" for producing human-comprehensible ] error messages about human-incomprehensible code. ] ] -Scott (the long-winded) Daniels ] daniels@teklds.UUCP or daniels@teklds.TEK.COM By the way, I agree that there is no point in complaining to the comittee (it's not much a complaint). I think they have done a good job even considering the many small and very few large compromises I would have had to make if I were on the committee. I won't use "signed char" anywhere yet because many of the compilers I use regularly don't support "signed" yet. Thanks to Chris and Scott for the responses. Thanks to all of the rest of you for the complete lack of irrelevent nonsense that none of you posted. Sincerely, Eric Tye McQueen Mathematics Department Also at (after some ericmc@usu.bitnet Utah State University time in March[June?!]): (801) 753-4683 Logan, Utah 84322-3900 ericmc@cc.usu.edu UUCP: ...{psuvax1,uunet}!usu.bitnet!ericmc "Are you in dutch with logically deep Arpa: ericmc%usu.bitnet@cunyvm.cuny.edu information?" Wetware - Rudy Rucker
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/19/88)
You get into problems with typedefs when you try to modify them, such as
using unsigned, but you should be able to use them recursively... I hope
dpANS doesn't invalidate something like:
typedef int *pi; /* pointer to int */
typedef pi frpi(); /* function returning ptr to int*/
typedef frpi *pfrpi; /* ptr to func ret ptr int */
This is useful to people who don't instantly think of
typedef int *(*fprpi)();
as the obvious way to do this.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mekarzes@mfci.UUCP (Tom Karzes) (05/19/88)
In article <8805180221.AA15564@jade.berkeley.edu> ERICMC@USU.BITNET (Eric McQueen) writes: >) From: chris%MIMSY.UMD.EDU@UMD2.BITNET 12-MAY-1988 06:04 >) >) My own feeling is that it should be legal. The argument against >) it is that it is not obvious what this means: >) >) typedef int (*pfi)(); >) typedef unsigned pfi upfi; >) >) and I believe that because of this argument, it is explicitly >) illegal. Certainly the `#define's are safer. >) >) Chris I think it's extremely bad practice to try to "modify" typedef types as if they were mere macros. It's much better to simply create the set of "machine" typedefs you need at the start, constructed from primitive data types, rather than to try to modify them later. Furthermore, trying to support this sort of thing causes problems in many lexers/parsers, making it harder to support legal C in cases like the following: typedef int foo; double xxx() { double foo; foo = 123.456; return foo; } Try this on a pcc-based C compiler. It's legal C, but it doesn't work on most compilers, particularly those that allow unsigned to be applied to typedef types, because they try to lex "foo" in the declaration in xxx as if it were a type, rather than a symbol. A reasonably debugged C compiler will handle the above code.