From 598878456252127071 X-Google-Language: ENGLISH,ASCII 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-30 10:48:06 PST Path: supernews.google.com!sn-xit-02!supernews.com!sienna.impulse.net!63.208.208.143.MISMATCH!feed2.onemain.com!feed1.onemain.com!feeder.qis.net!btnet-peer!btnet-peer0!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: kanze@gabi-soft.de Newsgroups: comp.std.c++,comp.std.c Subject: Re: C and C++ Standard incompatibility for signed character type Date: Mon, 30 Oct 2000 18:47:33 GMT Organization: Customer of UUNET Deutschland GmbH Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <8666mkbq7h.fsf@gabi-soft.de> References: <39F254C8.510803FB@null.net> X-Trace: mail2news.demon.co.uk 972931660 mail2news:7112 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: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id FAA02329 Lines: 65 Xref: supernews.google.com comp.std.c++:1713 comp.std.c:1445 "Douglas A. Gwyn" writes: |> "Clive D.W. Feather" wrote: |> > >C99 6.2.6.2 paragraph 2: |> > >There is specifically no contrary wording for signed char, so unde= r |> > >this standard signed char can have both padding bits and trap |> > >representations. |> > Correct. This means that WG14 and WG21 made different decisions. |> > In particular, a system with (say) 10 bit bytes might want signed c= har |> > to be [-256,255]. |> I frankly was surprised to discover that such a decision had been |> made. Maybe it occurred at one of the overseas meetings (which I |> couldn't attend). Anyway, I think it is a mistake to allow an |> operational width (sign + value bits) for signed char that differs |> from the width (value bits) for unsigned char. I was pretty sure we |> had agreed that these widths must match for every corresponding |> (signed/unsigned) pair of integer types. I don't think that there was ever a vote, or anything, to exclude signed char. It just so happens that it was never included. If I understand Clive correctly, a legal implementation with ten bit bytes could define: UCHAR_MAX =3D=3D 1023 SCHAR_MIN =3D=3D -256 SCHAR_MAX =3D=3D 255 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. In both languages (and both versions of C), or course, the actual number 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. There is an interesting case, however. Consider the following code: struct X { char buf[ 16 ] ; } ; struct X src ; strcpy( src.buf, "a" ) ; struct X dst ; dst =3D src ; Is this guaranteed To work? If so, why, since it potentially involves copying uninitialized char's. (It *is* guaranteed in C++, but you can easily create the same problem in C++ by using wchar_t instead of char.) --=20 James Kanze mailto:kanze@gabi-soft.de Conseils en informatique orient=E9e objet/ Beratung in objektorientierter Datenverarbeitung Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627 --- [ 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. ]