From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 50DD93858D3C for ; Sun, 4 Feb 2024 08:18:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 50DD93858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 50DD93858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707034725; cv=none; b=awYJsar+IS5G2eTY60Ts2he5a9Gfv/VW9OlKh3GvLtgKNqpdS9ZB57miCkhvl320fm/+h/ieEbb8hLm5CKpA5VOIjpZ69eheE4U29VwKNe/cQ+5l2Ypv+Ekx3R4AGdbwzvPcwwr/QT2pxk36scVjlJ4f2YUp3O2lTxx7Bmea0G0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707034725; c=relaxed/simple; bh=h+0S9xeJ3KXBtGfZujrQxvw0awolLoaEq+7kjoQ7nUE=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=I1296DWBRB9Q3Q3jZcDGAqh9lsso0POtj8vNx2gIZh5rH6QNcfRoAOwSotpUdJ76RlVmXbnORsp644q66jPqnPn5P1E44iKjdBe4VM+s+WfgvXuedL6sT0V0G3vwZ4dZqBQn1NFSjfa3Y1JUK7XknvaJ9Tf3k5VBNwNT6Bdm6eQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-511396ec8c7so3166761e87.0 for ; Sun, 04 Feb 2024 00:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707034722; x=1707639522; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MYfl9vyJuxRtXdqMBewQXzFa0WrK/o0Dvj/4r64VxH4=; b=ktlCx++8pHI0/bsbAz2QgTstJsM554DEIbP6vLjr8OLyWXrprv1mllNGwDSBmWapJ1 sBNfLBvyj/YmpwdNEJfyJDyBVJ9GZKe+NN1NMi637YWS8oMnMyBDJOPGPlvdGnIc/qz7 UeMukS1AQU7jESyzdOSHndVePGDt8Vx/dR9/jVk8EIzPZx++k6zQIi5VaWKgmQ8Thli1 JhzYG5mANShN/H1B5jL72eweKfE4dbXqMh2GNDETP5foyvvQ3XiqI46HoVF4jF3Fzkgp qTDi88d1NiSmiP11vxGN8eC/1+LB4UT4LX0qMHopuhTF9gaX2n2rI5agIQzqZ3YtsqZy KB5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707034722; x=1707639522; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MYfl9vyJuxRtXdqMBewQXzFa0WrK/o0Dvj/4r64VxH4=; b=k1Qr4EpPbuocMmOvoDCmGexs4EUzC7kENWuH7iAklc3BBgcvy1gS4Ze2eIhxZZ1Dpo nloYUPwtnHG9m7hywgo9h5MeOHpnfMb0hfGvcMJgXkUZulyZ0p7OhYzMs0OmfLOd6p/u 9zvSNAJJhFR0ELEObHipa9dA3z1EMgODOV5qyaXeCH2TsksDHE2smqAZtXb0/9wYbL9h 9nH5Lf8WpKcxzf6yDIcvv9fAZL8YqNi9Px2yV8uFYTzVuzZPLGyUcRdbMQ0XD4o6lU1a PtvmeI1eKCAtvmcOv3Ci67Q/JYCCUHKcnXDHMSIhUlmsnEOq/3tP98KGO/8Eq1bm5D6N 2WSg== X-Gm-Message-State: AOJu0YwzEgglKov3sIgZ1bZRZEdvIcIUHFc1GcKvdag6h82eEUAS95hb MeU8VgI1b8AIhOirBxrzA8G1xQ062Lr858Sw82NhWFyoqBiOgeJJj7klH2IReDtlLouPoggE3/Q mqicL8mqsEkSNvxog/XuYTXOPDLA= X-Google-Smtp-Source: AGHT+IGYInmayoLABmVxgrXywtIVc8mzHvGmYCwYdIb4KBTofnnMTDyS6B/Zs8CKolc9fwNq8RlSEihLrCRMgvyGHKA= X-Received: by 2002:ac2:58cd:0:b0:511:49f8:b42f with SMTP id u13-20020ac258cd000000b0051149f8b42fmr1115163lfo.8.1707034721423; Sun, 04 Feb 2024 00:18:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amol Surati Date: Sun, 4 Feb 2024 13:48:22 +0530 Message-ID: Subject: Re: Assignment of union containing const-qualifier member To: Alejandro Colomar Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 Sun, 4 Feb 2024 at 13:03, Amol Surati wrote: > > On Wed, 31 Jan 2024 at 23:46, Alejandro Colomar via Gcc-help > wrote: > > > > On Tue, Jan 30, 2024 at 10:45:11PM +0100, Alejandro Colomar wrote: > > > Hi, > > > > > [ ... ] > > > structure, that doesn't help. memcpy(3) does help, but it looses all > > type safety. > > > > Maybe this could be allowed as an extension. Any thoughts? > > > > Does it make sense to propose that, if the first top-level member of a > union is completely (i.e. recursively) writable, then a non-const union > object as a whole is writable? If so, then, for union objects a and b of > a union that has such const members, a = b can be expected to not > raise errors about const-correctness. This doesn't look okay- what if the last written-to member was not the first member of the union? The assignment can either copy the full size of the union (i.e. sizeof (b)) or copy just the member that was last written to within b. The latter requires the compiler to maintain an 'active' member of unions, which I believe isn't expected from the compilers. I believe the compiler performs an assignment a=b through memcpy (or through statements that have similar effects as that of memcpy) that, as you noticed, ignores type-safety. It may be because of such obstacles that the presence of a const member in the union prevents a union object from being a modifiable lvalue. > > It seems that a union only provides a view of the object. The union > object doesn't automatically become const qualified if a member > of the union is const-qualified. This seems to be the reason v.w = u.w > works; otherwise, that modification can also be viewed as the > modification of an object (v.r) defined with a const-qualified type through > the use of an lvalue (v.w) with non-const-qualified type - something that's > forbidden by the std. > > More towards the use of the string as described: > If there are multiple such union objects that point to the same string, > and if a piece of code decides to modify the string, other consumers of > this string remain unaware of the modification, unless they check for it, > for e.g., by keeping a copy, calc. hash, etc., to ensure that the string was > indeed not silently modified behind their backs. > > I think it is better to have a 'class' and associated APIs. > See [1], for e.g., or the implementation of c++ std::string. > > The ownership of an object of such a class can be passed by passing > a non-const pointer to the object. > > Functions that are not supposed to own the object can be passed a > const pointer. Despite that, if such functions need to modify it for local > needs, they can create a copy to work with. > > One can additionally maintain a ref-count on the char pointer, to avoid > having to unnecessarily copy a string if it is going to be placed in several > stay-resident-after-return data-structures. > > -Amol > > [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3210.pdf > > > Cheers, > > Alex > > > > -- > > > > Looking for a remote C programming job at the moment.