From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152]) by sourceware.org (Postfix) with ESMTP id CCAD23858D37 for ; Mon, 18 Mar 2024 16:55:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CCAD23858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CCAD23858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=81.29.32.152 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710780936; cv=none; b=TwwNzDAQqB1KRaqIUlqeftMv/QtaJ0aCg+RU9nolu3Qh75yZyqTZ+7msQ6RD5/0c2dB/ejEO5+WdFsY/OXybb9ahBbCTa6gUmzLPkqKnrChvtH5HtBLFIWKEQit5eVxgxt+8aZDwBF9mY13lffmynZZYCowaB/DD0bLAfScikrw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710780936; c=relaxed/simple; bh=+1dEvcq+T1khHE8Y85hQKNmn9t3tN+L2iC9kzpqyjAg=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=iJTtzEae38AGh4lO3DQ5VF/LFAa0kCsANECyjwpuJe+Ykte4Ci19vS6iAFH2TnhAqqcNbdXSVFM+nOx0ZDbWIR6O5pCeHnoNLrW8WksDpuYrmZsFVcZgF9jGR44pM6HytPtVn0BIA333juP3l2b/0b3TPPKdlOveG+5ti1Nsrs8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.63] (unknown [79.161.10.130]) by spam02.hesby.net (Halon) with ESMTPSA id 538b504b-e548-11ee-98be-506b8dfa0e58; Mon, 18 Mar 2024 17:55:29 +0100 (CET) Message-ID: Date: Mon, 18 Mar 2024 17:55:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: aliasing Content-Language: en-GB To: gcc@gcc.gnu.org References: <089a1300d266a3921feab4efb911987ca465e5c9.camel@tugraz.at> <6bff9afd-3e84-4260-9d05-8faec5f3ebe2@hesbynett.no> From: David Brown In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3033.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 18/03/2024 17:46, David Brown via Gcc wrote: > On 18/03/2024 14:54, Andreas Schwab via Gcc wrote: >> On Mär 18 2024, David Brown wrote: >> >>> I think it would be possible to have an implementation where "signed >>> char" was 8-bit two's complement except that 0x80 would be a trap >>> representation rather than -128. >> >> signed char cannot have padding bits, thus it cannot have a trap >> representation. >> > > The premise is correct (no padding bits are allowed in signed char), but > does it follow that it cannot have a trap representation? 5.2.4.2.1p3 in C23 makes the range of a signed integer type go from - (2 ^ (N-1)) to (2 ^ (N-1)) - 1, which means all values are valid and there can be no trap value if there are no padding bits. > I don't think > the standards are clear either way here - I think the committee missed a > chance to tidy up the description a bit more when C23 removed formats > other than two's complement for signed integer types. > > I also feel slightly uneasy using signed char for accessing object > representations since the object representation is defined in terms of > an unsigned char array, and conversion from unsigned char to signed char > is implementation-defined.  (This too could have been tightened in C23, > as there is unlikely to be any implementation that does not do the > conversion in the obvious manner.) > > But I am perhaps worrying too much here. > > > > >