From -727421343935075717 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,386ad3d115455fbe X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-12-09 10:41:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: markus.mauhart@nospamm.chello.at ("Markus Mauhart") Newsgroups: comp.std.c++ Subject: Re: properties of scalar objects w/ indeterminate value //Re: iterator defect or feature? Date: Mon, 9 Dec 2002 18:41:18 +0000 (UTC) Organization: Customers chello Austria Lines: 78 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <3de29db4.7069828@news.earthlink.net> <3defdcd5.44116609@news.earthlink.net> <3DF15F04.1000801@wizard.net> X-Trace: mail2news.demon.co.uk 1039459278 12242 10.0.0.1 (9 Dec 2002 18:41:18 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 9 Dec 2002 18:41:18 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18LSqC-0003B7-00 for mail2news@news.news.demon.net; Mon, 09 Dec 2002 18:41:17 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA05269; Tue, 10 Dec 2002 05:40:22 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-NNTP-Posting-Date: Mon, 09 Dec 2002 18:39:04 MET X-Spam-Status: No, hits=-5.2 required=5.0 tests=INVALID_MSGID,NOSPAM_INC,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.41 Xref: archiver1.google.com comp.std.c++:15873 "James Kuyper Jr." wrote ... > > Yes. In fact, C99 is far clearer about this. C99 adds the concept of > trap representations. For any type that can have trap representations, > an uninitialized object of that type might contain a trap > representation. The effect of this is pretty much the same as the rules > for the use of uninitialized objects in C++. However, C99 makes it clear > which types are allowed to have trap representations; it's perfectly > safe to read, copy, and compare uninitialized objects of the types that > can't have trap representations. All signed integer types, pointer > types, and floating point types are allowed to have trap > representations. So are all of the unsigned integer types except > unsigned char and the new exact-width typedefs such as uint32_t. Very interesting ! Originally I thought of that C that is/was relevant for c++98, but C99 probably has more details on complicated issues. I'm just trying to summerize: c++98: [sub-]objects initialized with 'indeterminate' value are considered 'uninitialized', especially they can contain 'invalid' values, and 'initialized' objects can contain 'uninitialized' subobjects. All we can do with them: Assign valid values to them, call their pseudo-destructor. They may be source and/or dest of memcopy or any byte-access ? (probably C9x should give the answer) C99 has specs that c++98 is missing: C99.3.17.2 indeterminate value either an unspecified value or a trap representation C99.3.17.3 unspecified value valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance NOTE An unspecified value cannot be a trap representation. -> 'indeterminate' value can be 'invalid' = 'trap' (and probably c++0x should get a corresponding update) AFAICS [C99.conversions] has no restrictions for them, instead [C99.Representations of types] contains the only restrictions: "If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.41)" "41) Thus, an automatic variable can be initialized to a trap representation without causing undefined behavior, but the value of the variable cannot be used until a proper value is stored in it." Especially 41) tells us we can assign valid values to them. Otherwise AFAICS the bytes of such objects can be source and destination of memcopy or any other byte-access (?) BTW, from C99 I couldnt find out how conversion (-> copy, assignment) between compound type objects is done: recursive copying of members (like c++) or "memcopy(dst,src,sizeof(both))" ? Especially the code of 'old' C[++] programmers using memcopy to assign/copy between POD structs is save, while the modern style of relying on the compiler generated copy for assignment/copy of POD structs is unsave. Kind regards, Markus. --- [ 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 ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]