From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,PLING_QUERY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public From: kaz@helios.crest.nt.com (Kaz Kylheku) Subject: Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Date: 1997/11/06 Message-ID: <63sp49$ihu$1@helios.crest.nt.com> X-Deja-AN: 287434367 References: <34557f2b.1934172@news.mindspring.com> <63r09q$q5h$1@helios.crest.nt.com> <01bcea71$74603f40$5e20430c@Rogers> Organization: A poorly-installed InterNetNews site Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy,comp.lang.c,comp.lang.c++ Date: 1997-11-06T00:00:00+00:00 List-Id: In article <01bcea71$74603f40$5e20430c@Rogers>, James S. Rogers wrote: >Kaz Kylheku wrote in article >> No. What I stated is in the C standard, so it's true for all conforming >> implementations. It defines the minimum ranges that all arithmetic types >must >> have. I wasn't making any claim about the relative sizes of the integral >types, >> just repeating the minimum range requirements. > >This is still an interesting answer to the initial question. What you have >is not >a definition of the size of an int, only a definition of its smallest >possible size. >So, how big is it, exactly? You have quoted the C standard which in effect I don't know! How tall is a tree? ;) >says that an int is larger than a bread-box, and even describes the size of >a bread-box. From this I can logically, and I believe correctly, assume >that >a 64 bit int is every bit as conforming as a 32 bit int. Yes. >The claim has been made that this produces completely portable code. This >claim can be supported only if the programmer is prevented from using any >int value which cannot be represented by a 32 bit int. Thus, if a system >of That is correct. >hardware and compiler uses a 64 bit int, only the first 32 bits can ever be > >used. If more than the first 32 bits are used the program, although using >a That is true. C89 is effectively a 32 bit language, as far as writing maximally portable programs goes. The C9X language will have support for larger integers. >conforming compiler, will be completely non-portable to a system using a >32 bit int. >What does the C standard say about the behavior of an int at the margin of >its ranges? Does 1 + INT_MAX always result in INT_MIN? How about when Absolutely not! INT_MAX + 1 is an overflow which results in---guess what---undefined behavior. >using an unsigned int? Does 1 + UINT_MAX always result in 0? If not, then Only the unsigned types have wrapping properties, thus 1 + UINT_MAX produces zero, (UINT_MAX is always a Mersenne number). To simulate modulo 65536 arithmetic in a portable way, you would use the unsigned int type, and logically AND your results with 65535. If you don't, you get modulo whatever the implementation gives you. >what is the portable definition of the behavior of an int at its range >limits? If you try to compute an int value that tries to violate the limits, the behavior is no longer well defined. On two's complement systems, wrapping occurs. But this is not defined by the language. Correctly written programs avoid such an error. >Without a well defined set of such conditions no C program could be >considered portable for its entire range of int values. > >Even with such a set of well defined rules, how many C programmers test >addition, for instance, to determine that X + 1 is greater than X? Failure I do not know how many, but I do. In non trivial programs, I use the assert() facility to detect such errors, ensuring that the preconditions to an operation are satisfied. >to >perform such a test can clearly lead to catastrophic behavior at the limits >of >the range of an int. Your program will then be entirely portable and Come on, use your imagination. You do not have to perform the test assert (x + 1 <= INT_MAX) in order to satisfy the condition that x is be less than INT_MAX! You rewrite the test by moving the 1 to the other side of the equation: assert (x <= INT_MAX - 1) In general, the abstract algebraic pre-condition assertions that are written in the design of a program cannot be directly translated into program statements because they themselves may violate the constraints of the machine's arithmetic. However, that doesn't mean that the machine can't be used to test for these conditions. The tests just have to be rewritten in less straightforward ways to avoid the overflow. For example, how would you test whether the sum a + b is within the range [INT_MAX,INT_MIN], without ever producing an intermediate result that falls outside of this range? The solution is to divide into cases. If a and b have opposite sign, then the result clearly cannot violate the bounds, so no check is required. If a and b are both negative, then you only need to check that their sum is not below INT_MIN. The remaining case, a and b are both positive, is checked against INT_MAX. The last two cases are rewritten to avoid overflow, of course. Thus: int a, b; /*...*/ if (a > 0 && b > 0) { assert(a <= INT_MAX - b); } else if (b < 0 && a < 0) { assert(a >= INT_MIN - b); } c = a + b; This could be written as one big assertion in one line so that it does not distract the reader of the program. It's nice to have range-checking built into the language; however, this does not give you coverage of all conditions, such as loop invariants or generally andy relationships among variables that are not expressed in the data declarations. I think it's better to learn assertive programming first, and then go to a language that can do many of the tedious checks for you. -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton