From -7053560009785375199 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 From: "Douglas A. Gwyn" Subject: Re: C and C++ Standard incompatibility for signed character type Date: 2000/10/22 Message-ID: <39F254C8.510803FB@null.net>#1/1 X-Deja-AN: 684409099 Content-Transfer-Encoding: 7bit Approved: Fergus Henderson , moderator of comp.std.c++ References: X-Accept-Language: en,pdf X-Authentication-Warning: backdraft.briar.org: smap set sender to using -f Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Trace: mail2news.demon.co.uk 972216025 mail2news:19875 mail2news mail2news.demon.co.uk Organization: @Home Network X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) MIME-Version: 1.0 NNTP-Posting-Date: Sat, 21 Oct 2000 19:44:56 PDT Newsgroups: comp.std.c++,comp.std.c "Clive D.W. Feather" wrote: > >C99 6.2.6.2 paragraph 2: > >There is specifically no contrary wording for signed char, so under > >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 char > 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. --- [ 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. ]