dcw@icdoc.UUCP (04/10/87)
In Article 1154 of comp.lang.c, ron@brl-sem.ARPA, mentions, in a discussion on portability : > 3. Saying int when you mean long... > Of course there is no way to determine this really portably, > but you can make a small machine header file that sets up > typedefs appropriately. One thing which always irritates me with C is that there is no way to define data sizes portably... When I just want an integer variable, on the assumption "oh well, it had BETTER be big enough", then I just use 'int' Otherwise, there is a (known) specific size/range of data which I want to store. So, I want to use 'byte' 8 bits 'word' 16 bits 'long' 32 bits 'megalong' 64 bits (ok, so I made this one up :-) (occasionally with 'unsigned' preceding it) So, what earthly USE is the current definition of 'short', 'int' and 'long' ? Are there cases (the simpler the better :-) when the existing method is useful ? 2). In Article 1155 of comp.lang.c, bright@dataio.Data-IO.COM, says : > How about allowing numbers to be specified in binary radix, > as in 0b00110101 ? No existing code would be broken, and it > would be very useful to those of us writing graphics code, > ... > As a corollary, support %b in printf and scanf. I agree completely. It would also be nice to allow someone to add new 'printf-able' objects. [ But this is, of course, a much more complex matter than just adding binary.. ] 3). In the same article, he also suggested : > specifying floating numbers in hex radix. Presumably just like VAX assembler ? Seems like a good-ish idea. Probably wouldn't be used much, but would be very useful when it is needed ! Duncan.