From 373724717202169017 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1149ec,c5e1f3188bfb5123 X-Google-Attributes: gid1149ec,public X-Google-Thread: f78e5,c5e1f3188bfb5123 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2000-10-31 17:09:09 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!europa.netcrusader.net!194.159.255.21!dispose.news.demon.net!demon!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: Team-Rocket@gmx.net (Niklas Matthies) Newsgroups: comp.std.c++,comp.std.c Subject: Re: C and C++ Standard incompatibility for signed character type Date: Wed, 1 Nov 2000 01:08:09 GMT Organization: Team Rocket Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <39F254C8.510803FB@null.net> <8666mkbq7h.fsf@gabi-soft.de> X-Trace: mail2news.demon.co.uk 973040896 mail2news:16378 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) User-Agent: slrn/0.9.6.2 (Linux) Lines: 52 Xref: supernews.google.com comp.std.c++:1828 comp.std.c:1505 On Tue, 31 Oct 2000 18:02:10 GMT, Francis Glassborow wrote: > In article , > Niklas Matthies writes > >On Mon, 30 Oct 2000 23:51:03 GMT, Francis Glassborow >d.com> wrote: > >> In article , > >> Niklas Matthies writes > >> >It's not (in C). The uninitialized chars may have trap values (for the > >> >type char) > >> > >> Please quote text to support this claim > > > >It's the other way round. The standard does not specify such a guarantee > >(unless I missed something), therefore there is none. > > The C standard requires that unsigned char has no trap values (that can > be deduced from the rules for type punning etc.) It also requires that > char can be exactly accessed as an unsigned char though the negative > values will be mapped to positive values beyond the maximum value for > char (assuming it is a signed version). I do not see how these > requirements can allow for the existence of trap values. Trap values are a property of the type. A trap value of type T only causes undefined behavior when accessed through an lvalue of type T. If an object ("object" in the sense that the C standard uses) of type T1 is accessed through an lvalue of type T2, then it doesn't matter whether the bit pattern of the object constitutes a trap representation of type T1, it only matters whether it constitutes a trap representation of type T2 (the type through which it is accessed). So, since unsigned char does not have trap values, it is of course absolutely valid to access chars as unsigned chars. But: char c, c2; unsigned char u; uc = *(unsigned char *) &c; /* ok */ c2 = c; /* could constitute behavior */ The question is whether a structure consisting of an array of chars may be copied by accesses through lvalues of type char. I believe this is valid. And if it is, and char can have trap values, and the array contains such trap values, then copying that structure will constitute undefined behavior. -- Niklas --- [ 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.research.att.com/~austern/csc/faq.html ] [ Note that the FAQ URL has changed! Please update your bookmarks. ]