From -7609818456156214828 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1149ec,31cf72263f3acc6d X-Google-Attributes: gid1149ec,public X-Google-Thread: f78e5,f5cbd811817fe301 X-Google-Attributes: gidf78e5,public From: ecl6rsh@leeds.ac.uk (R S Haigh) Subject: Re: `long long' (was: Re: Where next for Standard C++?) Date: 1997/10/26 Message-ID: <1997Oct24.194943.29393@leeds.ac.uk>#1/1 X-Deja-AN: 285035454 References: <3447ABB6.1C33@pratique.fr> <62oc8e$jd$1@shade.twinsun.com> <1997Oct24.113038.16972@leeds.ac.uk> <3450D609.2D67@pratique.fr> X-Original-Date: Fri, 24 Oct 1997 20:49:42 +0100 (BST) Organization: University of Leeds, UK X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANFMAGuEDnX0m9pzZAQHQkwGAgVoAzHvW/fHlPJGbDVEF0AXDA4DaWfHw iqNhtHmnNqndxQ6RotckrjAHl6tN4+hX =8UXh Reply-To: ecl6rsh@leeds.ac.uk Newsgroups: comp.std.c++,comp.std.c In article <3450D609.2D67@pratique.fr>, Valentin Bonnard writes: > Passing _any_ value which fit in size_t to a function taking a size_t > is strictly conforming. In particular, passing any sizeof (something), > any size_t returned by a library function, or ((size_t)-1). There is > no reasons for these values to fit in some prefefined range. Maybe it's different in C++. But in C, a program isn't strictly conforming if its output depends on anything that's implementation-defined. And the value at which size_t wraps round is implementation-defined, so if you exceed the legal minimum and the effect is observable in the output, the program isn't strictly conforming. Putting it another way, if you expect the output of a program to vary between implementations (and printfing (size_t)-1 obviously will), there is no way the program can be strictly conforming no matter how you write it. The first prerequisite for a strictly conforming program is that the description of its observable behaviour isn't a function of the implementation. No I don't like it either -- if the use of "implementation defined" were subject to more useful criteria (from the point of view of portability) then I believe the definition of "strictly conforming" could be usefully relaxed. At present it only covers a small subset of the programs that a conforming compiler is required (by other wording) to do the right thing with (which might be seen as a more general concept of "maximally portable"). > Actually the ONLY reason for having size_t (except self documentation) > is that you are wrong. As for why size_t exists, I've been wondering about that. I see three possibilities: 1) nothing to do with future-proofing, in which case the existing guarantees should be retained 2) for future-proofing, with the intention that it should always be not wider than unsigned long. That can't have been the intent, since (a) it would have pre-empted the whole 64-bit issue, and (b) a new type name would have been superfluous 3) for future-proofing, with the intent that it may get wider than unsigned long. A more plausible idea, but it does take more than a typedef. A portable and future-proof printf specifier, or at least a portable macro kludge, is needed to get this kind of scheme very far off the ground. I don't claim that the situation isn't a mess; but the problems are inherent in C89 and not affected by anything since. The facilities for portably future-proofing code are incomplete, making the need to modify source for 64-bit inevitable. Widening long wouldn't have changed that: it would have changed the details of updating code, but not the need to do it. -- --- [ 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 ]