From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2AA79383A238; Thu, 15 Sep 2022 20:21:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2AA79383A238 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663273307; bh=gjyW3XAKp1FSi8l01h5j2vpQ96b5d/md/G6PbQ0JhEE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=x8Jsgq6/oKPnEBbiNRA4Vm2/s2v+Ri1GYCpHlN9hJpzbL7ty3Ed1mdQ98pFrjHvLK b9Mty/IopgfL/0X/s3xlmuhnKMwdbXjx7NjeRFmGv9jMAjq1G05Yap3t4PdZpkg8aP x2KFJ6qb0BC6PGlq04k32SLgelDkvYnvXcAhkQ6o= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106926] string_view construction from literal string containing null/zero should warn Date: Thu, 15 Sep 2022 20:21:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106926 --- Comment #3 from Jonathan Wakely --- (In reply to John Zwinck from comment #2) > I agree the same problem could happen with std::string. As for your idea= to > add an attribute, I assume you mean something like this: >=20 > string_view(const char* s __attribute__((does_strlen))); Yes. > I think this would work but it seems like the attribute would have to be > added in many places. Why? I don't think there are that many places. > Instead, the compiler could statically determine that > the length of the string is lost in code like this: >=20 > string_view foo("bad\0string"); How would it determine that? By inlining the eventual call to strlen (sever= al function calls down from the location of the literal)? > And maybe even here: >=20 > const char* bar =3D "another\0one"; >=20 > Though that may be a step too far because someone could hard-code the len= gth > 12 elsewhere, and there probably is code in the wild doing that. I agree that's not a good idea. > In general the diagnostic could apply wherever the compiler knows the > contents will be copied. But that doesn't apply to string_view, there's no copying. And such a warni= ng would require optimization and inlining to be effective. How would the comp= iler know that? That's why I suggested an attribute, because the call site can g= ive a warning without having to know what happens inside the function, and everything that it calls. Relying on arbitrarily deep inlining doesn't sound like it will be very effective, nor does expecting the compiler to just "know" which functions t= his applies to. > Since that's not always possible to know, maybe it > could assume copying will happen when the literal is passed to an > out-of-line function. That seems like a bad idea too. Every function is "an out of line function"= at -O0.=