From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 9D7CC3858D35 for ; Sat, 15 Jul 2023 12:58:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9D7CC3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2b933bbd3eeso4431991fa.1 for ; Sat, 15 Jul 2023 05:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689425898; x=1692017898; 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=rsEiC6uLbwaKSasYzP9dNB6JRM5c3Z/jZOzEDZPejoE=; b=gpxp5fma6qAmZ4uXnibC3FROBxn8ewePeuUm2EviX9PT31DYYj0tyo59VOLMHMHo2h Eg4QdiZua0COBEGeWiSFRqRAjGK5g0Ss9vb5YeOApXfFKskzBFZ+RDHbdEqhGlBpuAck ax29hJd5faA01T7WhDAfkZwlBvMxBf+XE0UDbWUJ/ztI1bDHxx9YS8rXbraUNdgpsM9B qY2ry5KaCUW6P1f1UyQqS++bg5S5VMYuxK3w1jsmG2If3jqoKvjzMn3Ba58nfbF4ipZV m/EnMV7BUsGe0xEu3x6KJGPZLu3j2BKGJ0SvVL8WFAfjkjE6kx0Pc0/grnxGWPB8GSJ6 RwrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689425898; x=1692017898; 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=rsEiC6uLbwaKSasYzP9dNB6JRM5c3Z/jZOzEDZPejoE=; b=VbpdHUe7L5G/EGhZy42DQ4UKq/srBDdATQs+XYjwmPqpABlakc9S68axk/baoDP2Bq jnLA4K65C8OScl63cqGACToOe17Dohh5YBF6vJM+LRqNAlVOYbu8IrIpWaz7fKRuQeQv zn2NaOakrrVq7TVqV/6ElWFZBizw70FqZ4WAmud74RQAECv/i4TFzoRQNH0HBjKMluac KfboVItYUujaAKGHQNy3spJaK+k3McjXIWFUtweYN8J0/ooSCO3rGD3KhHoaWrM9Ka4m ZOvTpcp/WrH3o5pbRoaP7mAy48stSZQ6i20Hx4iKVOhrLZGEm8wVPHcS06GW606Otqa9 KdUg== X-Gm-Message-State: ABy/qLbOzW3gUja0724/AdlaOODzj4yRXAKc+Fy8+vH4GUzxWbPpCQou fo0zAnu/DfUeOpYCe5mNtbotsSjf8ZbUK72sHbc= X-Google-Smtp-Source: APBJJlFHbdkIqGkks71TsvTiZvvy1xt2tEtImZAZCYVXGFWZU8f9R6BInExmMgII+KujMEOFz1Ilydi7giHZ83o6Nuk= X-Received: by 2002:a05:6512:3705:b0:4fb:7a4e:b573 with SMTP id z5-20020a056512370500b004fb7a4eb573mr5776822lfr.5.1689425897540; Sat, 15 Jul 2023 05:58:17 -0700 (PDT) MIME-Version: 1.0 References: <334b2a3602914ce0f677de119cbeba7d8db8be41.camel@xry111.site> In-Reply-To: <334b2a3602914ce0f677de119cbeba7d8db8be41.camel@xry111.site> From: James R T Date: Sat, 15 Jul 2023 20:57:38 +0800 Message-ID: Subject: Re: Question about declaring an array in the stack on runtime To: Xi Ruoyao , jscott@posteo.net Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.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 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 Sat, Jul 15, 2023 at 6:49=E2=80=AFPM John Scott wrot= e: > It's not the assignment that's the problem. The problem is that you're > using a compound literal, and a compound literal, like typical > automatically allocated variables, has a lifetime determined by its > scope. > > In other words, the following: > if (some_var =3D=3D 7) { > arr =3D (unsigned int[7]){9, 10, 11, 12, 13, 14, 15}; > } > > is the same as > if (some_var =3D=3D 7) { > unsigned int baz[7] =3D {9, 10, 11, 12, 13, 14, 15}; > arr =3D baz; > } > > I hope this makes the problem a little more obvious: after you leave the > '}', the array doesn't exist anymore, and arr is a dangling pointer to > an object that doesn't exist. Ah thank you for this John, the rearranged code is particularly illuminatin= g. On Sat, Jul 15, 2023 at 7:19=E2=80=AFPM Xi Ruoyao wrot= e: > No. But the usage of arr[i] in the printf call is considered undefined > behavior. Got it. > From C23 6.5.2.5p5: > > A compound literal provides an unnamed object whose value, type, storage > duration and other properties are as if given by the definition syntax > in the constraints; if the storage duration is automatic, the lifetime > of the instance of the unnamed object is the current execution of the > enclosing block. > > And 6.2.4p2: > > If an object is referred to outside of its lifetime, the behavior is > undefined. > > And 6.8p1: > > primary-block: > compound-statement > selection-statement > iteration-statement > > And 6.8p3: > > A block is either a primary block, a secondary block, or the block > associated with a function definition; > > So here the "enclosing block" is the if statement, after the if > statement the lifetime of the unnamed object provided by the compound > literal has ended, thus referring it in the printf call is undefined. Understood, thank you for the references to the specific clauses. Will personally study these notes on the lifetimes of compound literals more for my understanding. > It's very difficult. The emit of the warning depends on the optimizing > of the loop. Without optimization the compiler doesn't even know the > loop will be iterated at least once, so there will be no warning is > produced at -O0. Ah alright, understood. > It seems Clang completely unroll the loop and produced a series of > printf calls at -O2: > > leaq .str.1(%rip), %rbx > movq %rbx, %rdi > movl $9, %esi > xorl %eax, %eax > callq printf@PLT > movq %rbx, %rdi > movl $10, %esi > xorl %eax, %eax > callq printf@PLT > > ... ... Yes, I noticed that. I would assume that this is more of an artifact of me hardcoding the value of `some_var`. If the value of `some_var` cannot be determined at compile time, then I would assume that Clang would not be able to unroll the loop and all bets are off, especially since it is UB. > So obviously -fsanitize=3Daddress won't work because there is no memory > access at all. On the contrary, clang -fsanitize=3Daddress -O0 is able t= o > detect the issue. Oh, interesting. Attempting to specify `-fsanitize=3Daddress` on Godbolt for Clang `-O0` does not seem to detect the issue. I have not tried it locally though. > And this is just completely out of the capability of - > fsanitize=3Dundefined. Despite the naming, -fsanitize=3Dundefined can on= ly > catch a *small* subset of undefined behaviors. > > Generally sanitizers are useful tools, but not silver bullets. Noted the part on `-fsanitize=3Dundefined`. Yes, of course, I understand that sanitizers would not be able to catch all issues. > I believe there has been a lot of duplicates about "no warnings at -O0". > And as I've said, these are very difficult to fix. A lot of warnings > just inherently needs some information from the optimizer, or there will > be either too many false positives, or too many false negatives. If you > need such warnings, you should enable the optimization. Understood, no worries. I was just checking on this specific issue. Thank you for your responses, Xi and John. I hope that both of you have a great day ahead. Best regards, James Raphael Tiovalen