> -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Wednesday, January 19, 2011 5:52 AM > To: Tomcat Users List > Subject: Re: [OT] Setting HTTP response headers caching for 1 year > doesn't work > > Christopher Schultz wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > André, > > > > (You always make me write so much code!) > > I don't /make/ you write code, I just provide the inspiration. > I'm quite good at that, when I don't have to do the work myself. > Thanks for writing the code in question though, it is nice getting to > the bottom of an issue. > > About this : > > Note that it's the Java compiler not the runtime that fails to > deliver > > an error. The compiled C code happily overflows without any warning. > Had > > I written the code using an array to store the operands and used an > int > > to store the temporary result, you'd see the same truncation > behavior > > with no compiler warnings. The fact that constants are being used > are > > allowing the compiler to complain in this case. > > Nitpick: > I am not sure that it is the use of constants that allows the compiler > to complain. > Let's check that with a sample freely adapted from yours: > > #include <stdio.h> > > int main(int argc, char *argv[]) { > > int thousand = 1000; > int sixty = 60; > int twentyfour = 24; > int hundred = 100; > int three = 3; > > int cacheTime1 = (1000 * 60 * 60 * 24 * 100 * 3); > long cacheTime2 = ((long)1000 * 60 * 60 * 24 * 100 * 3); > long long cacheTime3 = ((long long)1000 * 60 * 60 * 24 * 100 * 3); > long long cacheTime4 = (1000 * 60 * 60 * 24 * 100 * (long long)3); > long long cacheTime5 = (thousand * sixty * sixty * twentyfour * > hundred * three); > > printf("%d\n%ld\n%lld\n%lld\n%lld\n", cacheTime1, cacheTime2, > cacheTime3, > cacheTime4,cacheTime5); > > return 0; > } > > aw@arthur:~/tests$ cc -ansi -pedantic -Wall -o longtime2 longtime2.c && > ./longtime2 > longtime2.c: In function 'main': > longtime2.c:11: warning: integer overflow in expression > longtime2.c:12: warning: integer overflow in expression > longtime2.c:13: warning: ISO C90 does not support 'long long' > longtime2.c:13: warning: ISO C90 does not support 'long long' > longtime2.c:14: warning: ISO C90 does not support 'long long' > longtime2.c:14: warning: integer overflow in expression <=== > **** > longtime2.c:14: warning: ISO C90 does not support 'long long' > longtime2.c:15: warning: ISO C90 does not support 'long long' > longtime2.c:18: warning: ISO C90 does not support the 'll' printf > length modifier > longtime2.c:18: warning: ISO C90 does not support the 'll' printf > length modifier > longtime2.c:18: warning: ISO C90 does not support the 'll' printf > length modifier > 150196224 > 150196224 > 25920000000 > 150196224 > 150196224 > > Aha. So, it seems that the C compiler is smart enough to see that, > potentially, > multiplying an int variable by an int /might/ generate an overflow. > Or else, it is smart enough to see that the defined int variables are > in fact never > modified in the scope of the function, and it internally optimises them > as int constants, > and then complains. > Either way, it is smart. > > Maybe the Java compiler cannot afford to do that, because it is used in > "just-in-time" > compilations ? >
The reason the C compiler "catches" this overflow is actually due to the built-in optimization. Whenever it comes across a constant expression, it actually executes the expression at compile time (based on assumed or explicit typing) and then stores the result a single referenced constant. You should be able to verify this by having the compiler generate the assembler listing it's going to use to generate the machine code. This is a common optimization "trick" used by a number of compilers for decades. Does the Java compiler do this? One would think so, but judging from the results you guys are displaying, it seems not. I've been out the coding biz too long, so I don't remember everything, but I think there are options you can turn on when compiling C that will add overflow checks for you to generate error at runtime. I seem to remember they were defaulted on for the last compiler I used. Then again, maybe it is generating the exception, by the default run-time catch is to ignore and return. Jeff __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
