Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!bruce!cechew From: cechew@bruce.OZ (Earl Chew) Newsgroups: comp.os.minix Subject: Re: comment on 1.4b limits.h Message-ID: <1677@bruce.OZ> Date: 9 Nov 89 09:44:27 GMT References: Organization: Monash Uni. Computer Science, Australia Lines: 51 From article , by rbthomas@athos.rutgers.edu (Rick Thomas): >> > Would it be too much to ask these be changed to, for example, >> > >> > #define UINT_MAX ( (unsigned int) -1 ) >> >> I think that: >> >> #define USHRT_MAX ( (unsigned short) (~0) ) >> #define UINT_MAX ( (unsigned int) (~0) ) >> >> might be a better idea. > > portable without having to worry about such details. It's *supposed* to > be non-portable so that other modules can be portable. Ummm... I think that you're right. As Bruce Evans told me, the cast is probably not allowed in the #define otherwise things like #if UINT_MAX > 1 won't work. However, I would be very surprised if: (unsigned int) UINT_MAX != (unsigned int) (~0) I suppose the underlying question is when you use ~, & and | --- are the bit operations performed on the underlying internal machine representation, or are they performed on the binary representation of the number? If the former, then you can't trust: (8 | 7) != 15 since you can dream up a weird machine with some weird number representation in which the `bits' are not interpreted in the `conventional' manner (ie four bits `on' might be interpreted as 42). If the latter then what about -ve numbers? You can't impose twos complement on everybody. Does this mean that, in general, you can't trust the bitwise operations to do anything portably? Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 ARPA: cechew%bruce.cs.monash.oz.au@uunet.uu.net ACS : cechew@bruce.oz ----------------------------------------------------------------------