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 321893858D37 for ; Mon, 18 Mar 2024 17:11:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 321893858D37 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 321893858D37 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=1710781876; cv=none; b=nK8kXg7KuzXPDHmx2bR711v1igzA42laDcduh5on/W3X1xQMrqn0MIP+Ze/DcQ8vrgSXlhG/LFHpRJCGL0S8dwin/RYQapub7xsJZTilmcZwKRB/vHwFC1Dzu4zg5yCim9tm4W8F9Geltt9mTxWygqoEGoIfviI539lyIv4xIdQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710781876; c=relaxed/simple; bh=cqGrKnf4P94nmhwdvfRGtJj0EjXAcIj3XDJzzN28MOg=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=WXOx2A5BnIyz2f1vdHOYQcKiRtRnF4l9HACBx4XezdBOyzBqit9B0ABMvT+3VWkmtt6pcoUXOOsZqK7b9bRKDj/AX+CFmS4gxFqRfLuDo2jnS8xHUGWI1pOPQMVv0bJ6G9zgB7Joj96AM2jKs5PH5SvBnPcTAa0l2RvcVZ2zi6o= 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 855f9c01-e54a-11ee-98be-506b8dfa0e58; Mon, 18 Mar 2024 18:11:12 +0100 (CET) Message-ID: <906fdf23-47c4-f069-fe75-7db54f0a0a78@hesbynett.no> Date: Mon, 18 Mar 2024 18:11:11 +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: Martin Uecker , David Brown Cc: gcc@gcc.gnu.org References: <089a1300d266a3921feab4efb911987ca465e5c9.camel@tugraz.at> <6bff9afd-3e84-4260-9d05-8faec5f3ebe2@hesbynett.no> <09f7c87f08fc25083975dd9fd5250cdcbb02993e.camel@tugraz.at> From: David Brown In-Reply-To: <09f7c87f08fc25083975dd9fd5250cdcbb02993e.camel@tugraz.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 16:00, Martin Uecker via Gcc wrote: > Am Montag, dem 18.03.2024 um 14:29 +0100 schrieb David Brown: >> >> On 18/03/2024 12:41, Martin Uecker wrote: >>> >>> >>> Hi David, >>> >>> Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown: >>>> Hi, >>>> >>>> I would very glad to see this change in the standards. >>>> >>>> >>>> Should "byte type" include all character types (signed, unsigned and >>>> plain), or should it be restricted to "unsigned char" since that is the >>>> "byte" type ? (I think allowing all character types makes sense, but >>>> only unsigned char is guaranteed to be suitable for general object >>>> backing store.) >>> >>> At the moment, the special type that can access all others are >>> all non-atomic character types. So for symmetry reasons, it >>> seems that this is also what we want for backing store. >>> >>> I am not sure what you mean by "only unsigned char". Are you talking >>> about C++? "unsigned char" has no special role in C. >>> >> >> "unsigned char" does have a special role in C - in 6.2.6.1p4 it >> describes any object as being able to be copied to an array of unsigned >> char to get the "object representation". >> The same is not true for an >> array of "signed char". 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. I am not >> sure of the consequences of such an implementation (assuming I am even >> correct in it being allowed). > > Yes, but with C23 this is not possible anymore. I think signed > char or char should work equally well now. I have just noticed that in C23, the SCHAR_MIN is -128 (or -2 ^ (N-1) in general), eliminating the possibility of having a trap value for signed char (or any other integer type without padding bits). There's always a bit of jumping around in the C standards to get the complete picture! But as I said in another post, I still worry a little about the unsigned to signed conversion being implementation-defined, and therefore not guaranteed to work in a way that preserves the underlying object representation. I think it should be possible to make a small change to the description of unsigned to signed conversions to eliminate that. >> >> I see people making a lot of assumptions in their embedded programming >> that are not fully justified in the C standards. Sometimes the >> assumptions are just bad, or it would be easy to write code without the >> assumptions. But at other times it would be very awkward or inefficient >> to write code that is completely "safe" (in terms of having fully >> defined behaviour from the C standards or from implementation-dependent >> behaviour). Making your own dynamic memory allocation functions is one >> such case. So I have a tendency to jump on any suggestion of changes to >> the C (or C++) standards that could let people write such essential code >> in a safer or more efficient manner. > > That something is undefined does not automatically mean it is > forbidden or unsafe. It simply means it is not portable. That is the case for things that are not defined in the C standards, but defined elsewhere. If the behaviour of a piece of code is not defined anywhere for the toolchain you are using, then it is inherently unsafe to use. ("Forbidden" is another matter. It might be "forbidden" by your coding standards, or your boss, but the language and tools don't forbid things!) Something that is not defined in the C standards, but defined in your compiler manual or additional standards (such as POSIX) is safe to use but limited in portability. And of course something that is "inherently unsafe" may be considered safe in practice, by analysing the generated object code or doing exhaustive testing. > I think > in the embedded space it will be difficult to make everything well > defined. Yes, that is absolutely true. (And it is even more difficult if you try to restrict yourself to things with full definitions in the C standards or explicit implementation-defined behaviour documented by toolchains. You almost invariably need some degree of compiler extensions for parts of the code.) But I want to reduce to the smallest practical level the amount of code that "works in practice" rather than "known to work by design". > But I fully agree that widely used techniques should > ideally be based on defined behavior and we should change the > standard accordingly. > Yes, where possible and practical, the standard provide the guarantees that programmers need. Failing that, compiler extensions are good too - I'd be very happy with a GCC variable __attribute__ "backing_store" that could be applied to allocator backing stores and provide the aliasing guarantees needed. (It might even be needed anyway, to work well with the "malloc" attribute, even with your change to the standard.) David