From 1696886385151743544 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,c5e1f3188bfb5123 X-Google-Attributes: gidf78e5,public X-Google-Thread: 1149ec,c5e1f3188bfb5123 X-Google-Attributes: gid1149ec,public X-Google-ArrivalTime: 2000-10-30 14:25:04 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!news.tele.dk!212.74.64.35!colt.net!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: Mon, 30 Oct 2000 22:23:56 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 972944644 mail2news:15492 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) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: slrn/0.9.6.2 (Linux) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id JAA12384 Lines: 59 Xref: supernews.google.com comp.std.c++:1771 comp.std.c:1463 On Mon, 30 Oct 2000 18:47:33 GMT, kanze@gabi-soft.de = wrote: [=B7=B7=B7] > I don't think that there was ever a vote, or anything, to exclude signe= d > char. It just so happens that it was never included. If I understand > Clive correctly, a legal implementation with ten bit bytes could define= : >=20 > UCHAR_MAX =3D=3D 1023 > SCHAR_MIN =3D=3D -256 > SCHAR_MAX =3D=3D 255 >=20 > I certainly don't see any words in the C standard, either C90 or C99, > which would forbid this. For that matter, I don't think it would be > illegal in C++, as long as all copy operations on signed char's copied > all ten bits, without trapping. >=20 > In both languages (and both versions of C), or course, the actual numbe= r > of bits of the two types must be identical. And in both languages, > memcpy may not fault -- in practice, it must work as if the copy took > place through an unsigned copy. >=20 > There is an interesting case, however. Consider the following code: >=20 > struct X { char buf[ 16 ] ; } ; >=20 > struct X src ; > strcpy( src.buf, "a" ) ; > struct X dst ; > dst =3D src ; >=20 > Is this guaranteed To work? It's not (in C). The uninitialized chars may have trap values (for the type char), and structure assignment is performed by value (with the respective type). Another consequence is that if the char values stored in buf[] are valid and have padding bits, the padding bits need not to remain the same when the values are copied. Similarly, whether int f() { char c1 =3D 'a'; char c2 =3D c1; return memcmp(&c1, &c2, 1); } returns 0, a positive or a negative value is implementation-defined, and may differ for different invocations of f(). -- 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. ]