From -3565818297579835931 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,f5cbd811817fe301 X-Google-Attributes: gidf78e5,public X-Google-Thread: 1149ec,31cf72263f3acc6d X-Google-Attributes: gid1149ec,public From: kanze@gabi-soft.fr (J. Kanze) Subject: Re: `long long' (was: Re: Where next for Standard C++?) Date: 1997/10/24 Message-ID: X-Deja-AN: 284746587 References: <3447ABB6.1C33@pratique.fr> <623mk9$mpu$1@cdn-news.telecom.com.au> <330204553wnr@ma.ccngroup.com> <62fkpp$f04@mulga.cs.mu.OZ.AU> <344B5E96.485B@pratique.fr> <344E1109.4684408E@ArtQuest.fr> <344E4712.41C6@wizard.net> <62o48f$as2@mulga.cs.mu.OZ.AU> X-Original-Date: 24 Oct 1997 10:13:57 +0200 Organization: GABI Software, S`rl. X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANFDIiOEDnX0m9pzZAQFhtAF9E0zxVhnoYp4qIM4XDx7IIxvkVpBoPfIW 8RAxDg169TP/4v6GE1fRaEaizgCV7f+T =yzlN Newsgroups: comp.std.c++,comp.std.c fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: |> My question to the people who are so worried about code like the above |> breaking is this: do you check every addition and multiplication |> for overflow, in cases were it might possibly overflow? No? |> Then your code isn't strictly conforming anyway. This seems obvious: you don't release code where there is a possibility of overflow. Period. You don't check every operation, but you do validate all input values, and use value induction to prove that overflow can't occur. (And yes, it sometimes means formulating expressions in strange ways, to ensure that signed integer arithmetic won't generate illegal intermediate values, even though you know that on 99.9% of all implementations, the final results will be correct anyway. It's just a question of being professional.) |> Consider the hypothetical system with 64 bit pointers and 32 bit long. |> For the code above to fail, you must somehow have computed a value |> of type `size_t' which doesn't fit in 32 bits, which you then pass to |> func(). But if you have done that, then (unless you are very careful |> about checking for overflow, and I've never seen C code that is) |> your program would fail anyway, if the implementation had 32 bit size_t. No. Because at some point in entry, you have compared values with a value derived from (size_t)( -1 ). This is pretty much standard procedure, and I can't imagine anyone releasing a program without having done it. |> So although the complaint is that C9X will break strictly conforming C89 |> constructs, when you look at real programs it seems to me that the |> actuality is this: for programs which were not strictly conforming to C89, |> and which didn't work on some hypothetical implementations which don't |> yet exist, with C9X these programs will now not work on some different |> hypothetical implementations which also don't yet exist. |> To me, this does not seem worth getting so fussed up about! |> |> >(it might still accidentally work for values that fit in 32 bits, |> >depending upon the endianess). |> |> No, for values that fit in 32 bits, it will continue to work regardless |> of endianness. This is actually the worst aspect of it. It is necessary to modify existing code. OK, that's progress. But the change is silent -- the compiler will not tell me what has to be modified. So there is a non-0 risk that something gets missed. Of course, like any serious programmer, I will run regression tests after the modification. Now: you tell me what is the probability of my regression test catching the error. The result is that the change generates errors which will only appear in the field, much later. |> >The |> >same difficulty applies to any other integer-valued standard typedef. |> >Automated searches for cases affected by this problem is very difficult, |> >bordering on impossible, rendering conversion of large projects to C9x |> >significantly more difficult than it would otherwise need to be. |> |> Automated searches for cases affected by this problem are not |> "bordering on impossible", they are quite achievable with current |> technology. All you need to do is compile your code on a system |> which has `long long' size_t (or perhaps just using header files |> modified for this purpose), and use a compiler that warns about |> conversions from `long long' to `long'. Such warnings are very |> easy for a compiler writer to implement. |> |> Now it is true that not everyone has such a compiler. |> However, if you want to convert a large program to C9X, |> and you don't have such a compiler, there is a simple solution: |> just add `assert(sizeof(size_t) <= sizeof(long))' or equivalent |> at the start of main(). Your program will be no less portable |> than it was before. And when the time comes to port to a system |> which violates that assertion, the compiler for that system |> will no doubt offer such warnings, if there is any demand for it. Finally, something I can agree with:-). I just hope compiler implementers are listening. (There is a long tradition in C/C++ that a compiler NEVER generate a warning when there is an explicit cast. An explicit cast says that the programmer knows what he is doing. In this case, he knew what he was doing when he wrote the code, but someone changed the deck.) |> >There is also a parsing problem, about which I know very little, caused |> >by the fact that 'long long' is the only type whose recognition requires |> >a count of duplicate tokens. |> |> This problem is insignificant. Parsing `long long' is trivial. I don't know about trivial, but solved, anyway:-). The main (only?) argument for "long long" is existing practice. -- James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France I'm looking for a job -- Je recherche du travail --- [ comp.std.c++ is moderated. To submit articles: try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]