Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!USU.BITNET!ERICMC
From: ERICMC@USU.BITNET (Eric McQueen)
Newsgroups: comp.lang.c
Subject: Re: recursive typedefs
Message-ID: <8805180221.AA15564@jade.berkeley.edu>
Date: 18 May 88 02:19:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 75

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