From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by sourceware.org (Postfix) with ESMTPS id D2B7E3858D32 for ; Mon, 12 Feb 2024 10:45:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D2B7E3858D32 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 D2B7E3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707734759; cv=none; b=IkxP9SlgOb5jdPMvFTUV4Eg+SuPLxfoJfAli0mTC5OSrdhSprZ9UdtVCqk2ZlFALStxkAv/wubRd8qdpCWE+e+F/7+Np7IP10WasY8JNiYAsJTG2kSbmDaM9Ct5iSjG7a8tqM8JbmzoT/HLVg0v64ET3il+zHdzF+JR+pbnP/RU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707734759; c=relaxed/simple; bh=6C8ZIKycS2zS5Kc8jrpMIpPL2S5k0IdOJ9VPmgU5knI=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=RSKzIBiodHu7mus+wsquL0QOZyBsnNTYBDfB+I2vkJSGFb027C3EFyH7l2EsRW0g9YuWtQBIq+HjQ5UGrPDMm6N5sbgW+p4eSszymM8jLTim7+F61rh4knSBfRF1NGNmbpKeQ169uJKGt48I8dCQG75Fra+YXniDuBvgsq1Yc7M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-51186925925so1313380e87.0 for ; Mon, 12 Feb 2024 02:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707734755; x=1708339555; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=v5ofHL2aRusnuDYiN3zyvAIg5TWZuBnLu7a23wtMlHY=; b=YBt/RQzdWH6K8VAl5mCvHqjhjVf9ivH7mbSiC5C9EVOhpidaOOr4qg7zsb+PvPhICe OXxb7nJAI9gbIWPxvO8fFCQ7fv2PAkMEJihLgEExdHzJP2Z2TnpEHV+NRTVSFNlpFEeT AoPWscskHvP3MyDubpCDIPhYh0KiBdIec8o/ePH/22vqsjKoYboLN7jutdjLgpv4aMGx 7TgeaOxSEjz3PAGbeHEORH2JO3V8GfxZ4dgk8nK1yHScjwdcKKt3LAX8GRdF8AgmvIT6 5o6o+FgyekyAogy/u6eAy5gbtUEx4hfvFiH6f4le7epmOiUBQZhKEzA0wouP+j5AwpKW P3vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707734755; x=1708339555; h=content-transfer-encoding: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=v5ofHL2aRusnuDYiN3zyvAIg5TWZuBnLu7a23wtMlHY=; b=T2YlnWg27ifcCEXtqxEBZIG73Age2psnO8XeIpFLDSh+EyCKZlqG7qD5b/ab/cXrVD KWlh1s1KENW3VcgzWjjaK3YKC+Q8T/9/v7QP9Q92KPkBP4O0fSb546fvHWvb4yNoZNSW oe9BEAQtUt5yYnWFYUV8cEHiT/CNPQqh5n6oHdx77iAjHbLDI5uaLUEJktVDXxQhmuWy 1virHtmFIh0JSzT6sWiqxVVGYExEEQ46MBqp9mEQsREU8OClp92FZBuUpfazKT8fCPNi bwKFy3uc2S8muAJkD4EdogGE6lHqlkidhGAMYdnhzD3bSkquWZPuu4D9yHRVmfg90Zoo vzCw== X-Gm-Message-State: AOJu0YyRH4Zd9aTrSqmc09a8zmJtj/I/J0Qsu1+99P4AKYnFtpztqpIG xFWCsjiI/fZx+kLuLZM3Wu4KDC0V7HWXl/2jY5WwySCDsW5LrH5nudTy0SsMZ1iCyVUjypg5mzs Wrt8SA77cP0AqjkH7fnUeTYuBDx4= X-Google-Smtp-Source: AGHT+IG0ucNI0dzIsiPq16GxoJ2pyhqfyPXKwgsz0JqGNbqIpEXhIR25Yvhc7Lhz+nQ48Z/53w1NtqFoHJimBRGax64= X-Received: by 2002:a05:6512:2101:b0:511:31b4:ac16 with SMTP id q1-20020a056512210100b0051131b4ac16mr3937396lfr.47.1707734754812; Mon, 12 Feb 2024 02:45:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amol Surati Date: Mon, 12 Feb 2024 16:15:24 +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" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.1 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,URI_DOTEDU autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Alex, On Wed, 7 Feb 2024 at 18:59, Alejandro Colomar wrote: > > Hi Amol, > > On Wed, Feb 07, 2024 at 09:43:55AM +0530, Amol Surati wrote: [ ... ] > The fact that the compiler does the equivalent of memcpy(3) doesn't > imply a removal of type safety. > > The copiler is aware of the union type at the assignment, and so can > emit diagnostics if anything is wrong. True. That's the diagnostics that was emitted when running 'v=3Du'. > > When assigning to a union member, only that member needs to be copied, > and I'm not sure what happens to other members that have a larger size. > As far as I can read in the standard, it's Undefined Behavior. Maybe > someone can correct me. The std says: "When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values." > When assigning to a union (not its members), the standard doesn't seem > to specify at all the semantics, so I can't really tell. Depending on > the semantics of assigning to a member, I can tell. At first glance, I > don't see anything we should worry. [ ... ] > Not really. If well used, they do actually improve type safety. Think > of my string unions vs the struct proposed by Martin. My union has > const correctness, which is impossible to achieve via structs. A I am not sure I fully understand how using structs forbids achieving const-correctness (vs the unions as declared), but I am also not aware of all the ways in which nginx uses strings. [ ... ] > Indeed. But I'm not sure I'd like a string type that I must treat as a > FILE*. Also, how do you initialize such strings? With an EMPTY_STRING > macro? Do you always get a heap pointer, so you can't declare a string > in the stack as this? > > struct string s; > > What's the content of that string? Is a NULL pointer a valid state of > the string? In NGINX we found this week several cases where we were > doing pointer arithmetics on strings that were holding NULL, precisely > due to this (or it was after some calloc(3), more likely, I don't > remember). It was NULL + 0, which is the least of undefined behaviors > I'm concerned about, but hey, there's another NULL to worry about. > > So, you'll need to do > > struct string s =3D EMPTY_STRING; > > to avoid ever having a NULL, which is yet another thing to worry about. > > Having suffered these strings, I wouldn't recommend them as something > better than a char*. In NGINX, we have them due to historic reasons, > and rewriting the entire code base would be unreasonable, and while they > may have been a good optimization 2 decades ago, I bet that it's a > useless micro-optimization today, and we could just use char* everywhere > to have less problems. If a variable is going to be overwritten without being read first, then the= re's no need to initialize it. Within my implementation, the state resulting fro= m zero-init, i.e. 'struct string s =3D {0};', is deliberately chosen to be well-defined for the implementation. For e.g. appending a char to a zero-init'd string i= s well-defined. > > > You can only make them const, if you use two distinct types: a read-o= nly > > > version, let's call it rstring, and a read-write version, let's call = it > > > string. > > > > But do we need both views (r/w and r/o) at the same time? > > Yes: I want to be able to take a r/w string and pass it to a function > that accepts a r/o string. Since distinct types are incompatible, and > this is the main problem with things like sockaddr, you can't just cast; > that's likely to invoke Undefined Behavior. The std says: "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer." So typecasting between object types is well-defined, given that the resulting pointer is indeed correctly aligned for the target type. The various sock_addr types all impose a common default alignment, because they all begin with a member of the same type. The std. also says: "An object shall have its stored value accessed only by an lvalue expression that has one of the following types: . . . =E2=80=94 a character type." For e.g., the _sys_bind system-call under Linux kernel receives the same 'const struct sockaddr *', along with the size of the data, from glibc. The kernel then copies the data using memcpy (or equivalent routines). Does the pointer conversion forbid the kernel from memcpy'ing the object using that converted pointer? (It is likely that the converted pointer, if it is not of compatible type, may not be dereferenced using that type; but here the kernel isn't dereferencing the pointer using the 'const struct sockaddr *' type; it is reading the obj-representation using memcpy.) If no, then this behaviour is well-defined. If yes, then this behaviour is undefined, although, in practice, both gcc and clang (the compilers that can compile Linux kernels) must be allowing the expected behaviour here, since the compiled kernel binaries do indeed work wherever they are deployed. This only means that, *if* the behaviour turns out to be theoretically undefined, *then* the std. can be augmented to specifically allow reading of representations of objects pointed to by such suitably converted pointers, if it does not already allow such reads. [ ... ] > > A function that is passed 'struct string *' can still be allowed to > > inplace-modify data[i] by invoking appropriate string APIs that tempora= rily > > casts away the constness of data[i]. > > That would be a violation of const correctness. If necessary, yeah, go > ahead. But personally, I'd prefer avoiding that. For something that is > proposed as an inclusion to ISO C, I'd rather not have it. I keep two bits of info within the string: (1) whether the 'struct string' is heap-allocated, or not. (2) whether the data (const char *) it points to is heap-allocated, or not. The std. says: "If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined." Given that a malloc'd object doesn't have its own declaration or a declared type to begin with, it also doesn't have a definition, let alone a const-qualified definition. Modifying malloc'd objects should not cause const-correctness to be violated, even when casting away const on a pointer that points to such an object. Modifiable strings can be created from statically allocated data (for e.g., pointing inside the .rodata section), and the data can be malloc'd and changed/appended-to on a copy-on-write basis. -Amol > > I would prefer that a libstring adds those APIs, rather than having them > in the standard. They aren't uncontroversial. Neither char* is > uncontroversial, but at least it's simple. > > > The SEI CERT coding standard for C allows for an exception for such > > modifications. See > > https://wiki.sei.cmu.edu/confluence/display/c/EXP05-C.+Do+not+cast+away= +a+const+qualification#:~:text=3Dend%20is%20undefined%20*/-,EXP05%2DC%2DEX3= ,-%3A%20Because%20const > > > > Some other options: > > Make use of the sparse semantic checker. > > > > It might help to name the fields with underscores to highlight the fact= that > > they are internal fields. For e.g. 'str_size__' and 'str_data__'. Any = use of > > these fields outside of the dedicated API functions can now be easily > > traced by simple grep searches. > > > > It might also help to create a visible type such as > > > > struct string { > > const uintptr_t raw[2]; > > }; > > > > and let the API manage the translation between uintptr_t and size_t/cha= r *. > > But you'll need a transparent union to do the magic. All of that shows > that it isn't an easy thing through structures. unions at least have it > easier. > > Cheers, > Alex > > -- > > Looking for a remote C programming job at the moment.