jlm@amdahl.UUCP (John Marshall) (11/16/84)
Who said typedefs don't have scope? Typedef names are identifiers,
and as such have a scope. Section 8.8 (Appendix A, K&R)
makes this clear.
Also see section 11.1, page 206, which even includes a
specific example:
typedef float distance;
...
{
auto int distance;
...
Pcc has a problem in this area, but
Amdahl's UTS C compiler handles these constructions correctly.
Incidently, I believe the following is even correct:
....
typedef int foo;
{
typedef float foo;
....
where the identifier refers to type int in the outer block,
but to type float in the inner block.cottrell@NBS-VMS.ARPA (COTTRELL, JAMES) (10/16/85)
/* > > typedef long int60 ; /* or whatever the type is for 60 bit ints */ > > My point is, if more than 32 bits are needed then this code is > not going to port anyway, no matter what typedefs you use. You mean not going to port *everywhere*. At least it will say under *what* conditions it *will* port. > > Likewise, if *your* code uses int8/int16/whatever correctly, specifying the > > number of bits needed, then there file of typedefs will get them a > > reasonable type for those variables. > > If you use the proper C data types, there will be no need to worry > about this at all; the code will work on all standard-conforming > implementations without any change whatsoever. Yes it will work. But how well? Some systems (notably BSD) ignore register short definitions for example. This style allows (& requires in certain cases) the porter to choose his tradeoffs globally. > There is no need > to invent system-specific typedefs for any integer type through 32 > bits, and for longer integer types typedefs are not sufficient. Man does not do everything out of need. There is no need for floats either since we have doubles, but the subject occupies space in this group often enuf. You still haven';t addressed my other point. At least the guy gave some thought to what he did. Would you rather port his code or someone who doesn't even know the difference? jim cottrell@nbs */ ------
ron@brl-sem.ARPA (Ron Natalie <ron>) (10/16/85)
> Yes it will work. But how well? Some systems (notably BSD) ignore > register short definitions for example. This style allows (& requires > in certain cases) the porter to choose his tradeoffs globally. It doesn't ignore register short definitions, it mearly does not put them in registers because registers can only be applied to types int and long on VAX. Or whould you have sizeof (int) return different numbers depending on whether it's in a register or not?
chris@umcp-cs.UUCP (Chris Torek) (10/17/85)
> It doesn't ignore register short definitions, it mearly does not put them > in registers because registers can only be applied to types int and long > on VAX. Or whould you have sizeof (int) return different numbers depending > on whether it's in a register or not? Ah, Ron, how could you make such an error? You can indeed apply registers to `short's and `char's and even `float's and `double's; it is merely much more difficult to get the code generation right. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
guy@sun.uucp (Guy Harris) (10/17/85)
> (The 4.x BSD C compiler) doesn't ignore register short definitions, it > mearly does not put them in registers because registers can only be > applied to types int and long on VAX. It also puts pointers into registers as well; the rule is "if it's not 32 bits wide, ignore the 'register' declaration." The reason, according to the 4.1BSD manual page for "cc": BUGS The compiler currently ignores advice to put "char", "unsigned char", "short", or "unsigned short" variables into registers. It previously produced poor, and in some cases incorrect, code for such declarations. I remember running code through the System III VAX PCC and the 4.1BSD VAX PCC (which is the S3 VAX PCC with long variable name support added, register variables < 32 bits wide subtracted, and some other minor changes). If I remember correctly, the S3 compiler did, indeed, produces some less-than-wonderful code for some constructs involving "register short" variables. The S5 VAX PCC will put types shorter than 32 bits into registers; it has been claimed that it does not produce the same poor code. I've provoked it into producing code which widens things into registers and narrows them again (or *vice versa*; it's been a while). This may have been necessary to preserve the semantics of C; I don't remember the exact circumstances. > Or whould you have sizeof (int) return different numbers depending > on whether it's in a register or not? Huh? The compiler keeps track of the type of all variables, so the code that handles "sizeof" doesn't look at whether it's in a register or not. Besides, an "int" on a VAX takes 32 bits whether it's in a register or not. Guy Harris