220 31685 <90f34150-9513-4b5a-a026-2d73334ece05@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Explicitly uninitialized variables with = void, with warnings on missing initializers. Date: Sat, 18 Mar 2017 21:13:02 -0700 (PDT) Lines: 144 Approved: news@gmane.org Message-ID: <90f34150-9513-4b5a-a026-2d73334ece05@isocpp.org> References: <1c1bbb0a-89cb-4c90-8384-94e92b61f649@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4960_1994215863.1489896782172" X-Trace: blaine.gmane.org 1489896784 1622 195.159.176.226 (19 Mar 2017 04:13:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Mar 2017 04:13:04 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIM5CVYYYCRUBA26Z5XE@isocpp.org Sun Mar 19 05:12:59 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cpSDC-000890-7w for gclcip-std-proposals@m.gmane.org; Sun, 19 Mar 2017 05:12:58 +0100 Original-Received: by mail-pg0-f72.google.com with SMTP id 79sf101909057pgf.2 for ; Sat, 18 Mar 2017 21:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BIfEds8evc5CwUwlw9+r2xhtxXz8KswkA3c9MRbF4ug=; b=GajBOFdBVC/fvCPmscjNZ4+XJVQYyiWQqqUDLVnAqjo8/yRbu7uc/HD5PQ15bNYRYF GAqApKmZ3Q7a+vMBzIzBcoYYhWHAhMYHuoU68d8JiBXxTmMjm/VD9Vh6j526XJSeC6vI 9v/ZeHOQdpY3TGvqpR1hxeFuIBMW3Gsi29kCc3uXq7nVV9N1Z0FNJxX9GHw8WOEfsESc hripX+uS03RmR9hb1e4Ca6+EFiEDNzbQlhWsQEErntEgnmhzTDeAtY0O3HIqA5ZqA7J3 iHR6p804gs2wDAyWq3cW2CfHv+Ct58Aw0gDaAf5nZjB7dzXK/X04ljapyRQYGrd6JPVq h+jw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BIfEds8evc5CwUwlw9+r2xhtxXz8KswkA3c9MRbF4ug=; b=BY7DMWbVMX5cEYkmj8SYZhlXP0G+Z31V+1yT77zD32E1nro90ybWWjxjw+8+X4QcGh jB0PjbxgKRCVjghHhq9DWVGuuVG/vYLjMtZqSNeyI+QZZPmQ2lApMWZTcEua7mggC7b4 DWzJHyC+ia3wJsBBx5rhWbCzM5gAAMN1lJZLD9d4aOC8/vHShG7egXl+fze48NDJo/QO Y+nwI9JFL+Gqj+b+7azZLCUllip4CJNndiUHTwlUDQa8RMapjTVBntb4S13xXRBCPthG g2mYAqWtL9IDTBJ09vKLXQMvSyfi7rVPar0RzKR91otQic7Qs47OU1CqC6PNWPf7pNKj Ehgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=BIfEds8evc5CwUwlw9+r2xhtxXz8KswkA3c9MRbF4ug=; b=CG3IcwPr/+9nJTEzgjweXPCdRVpM4qE1xqPbEeojRIWwqT4FzyCw0hwCxArZSDLVCC 5o+ZUP3WlKK2pik2/e+Ws/lQx2zHZr+zyhP0d80V1CyPwDSvyWXasu8gwN/t8bOPNZ2R rDsGIJou+GeDrw9ilXlTgVZZhF7XXZkiTu16dXUsoRiQRJ0ZypHPSa0bnAsa6Ia/GZyR 9lxDnDsiUSM4un5uJtKBRP/5N6+omAU28dnnzkAl/5mYkl6jAfSq2y+nENa8RMOAphFI JESpUSoiHjDhn54jQ1JYLPPmnCWIP3qrFciny57nxgpqEVPizqf/DVMfZh5r84QC7Nk/ +hUQ== X-Gm-Message-State: AFeK/H0Kn+HCV2gu1odOBwQRRmeUyQwMi8KXGYh1Y23ValC0XvM3BpTHbEwxoyT1JqqHQw== X-Received: by 10.99.124.27 with SMTP id x27mr2131300pgc.50.1489896783843; Sat, 18 Mar 2017 21:13:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.3.111 with SMTP id 102ls1393708otv.42.gmail; Sat, 18 Mar 2017 21:13:02 -0700 (PDT) X-Received: by 10.157.82.47 with SMTP id e47mr2334319oth.18.1489896782838; Sat, 18 Mar 2017 21:13:02 -0700 (PDT) In-Reply-To: <1c1bbb0a-89cb-4c90-8384-94e92b61f649@isocpp.org> X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:31685 Archived-At: ------=_Part_4960_1994215863.1489896782172 Content-Type: multipart/alternative; boundary="----=_Part_4961_508203819.1489896782172" ------=_Part_4961_508203819.1489896782172 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, March 18, 2017 at 1:20:37 PM UTC-7, Matthew Fioravante wrote: > > In C++, we inherited this rule from C where primitive types like ints and= =20 > pointers are uninitialized by default. > > Before getting into it, essentially what I'm suggesting is first we add a= =20 > syntax for explicitly leaving a variable uninitialized > > int x =3D void; //I'm telling you x really is intended to start its life= =20 > uninitialized > std::cout << x << std::endl; //undefined behavior > > Next, we can suggest compilers warn if you don't provide an initializer= =20 > for types that would otherwise default to be uninitialized. > > Note that for class types with constructors like vector, you can still go= =20 > on with no initializer. The warning scheme is what maintains backwards=20 > compatibility. > What you're describing sounds good, but you've picked the wrong syntax for= =20 it. Look at the semantics again: - We want to add a semi-standardized diagnostic for an existing construct - We need a way to annotate the construct in order to suppress the=20 diagnostic - The annotation should have no effect on codegen What kind of syntax does C++ already have for this kind of thing? Answer:= =20 attributes. In fact what you're proposing is basically identical to the existing C++17= =20 attribute [[maybe_unused]], in terms of its interactions with codegen and= =20 diagnostics. int x [[uninitialized]]; // yes, compiler, I know this variable is=20 uninitialized; please don't complain about it struct Foo { int m [[uninitialized]]; // yes, compiler, I know this member=20 isn't always initialized; please don't complain about it Foo() { } }; A proposal along these lines would sound good to me. Sadly I'm not sure there's any prior art for actually giving such warnings.= =20 Maybe in compilers that support MISRA-C++...? =E2=80=93Arthur --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/90f34150-9513-4b5a-a026-2d73334ece05%40isocpp.or= g. ------=_Part_4961_508203819.1489896782172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, March 18, 2017 at 1:20:37 PM UTC-7, Matthew F= ioravante wrote:
In C++, we inherited this rule from C where primitive types like ints an= d pointers are uninitialized by default.

Before getting into it, ess= entially what I'm suggesting is first we add a syntax for explicitly le= aving a variable uninitialized

int x =3D void= ; //I&#= 39;m telling you x really is intended to start its life uninitialized
std::cout <&l= t; x &l= t;< std::endl; //u= ndefined behavior
=

Next, we can suggest compilers warn if you don't provide an i= nitializer for types that would otherwise default to be uninitialized.
<= br>Note that for class types with constructors like vector, you can still g= o on with no initializer. The warning scheme is what maintains backwards co= mpatibility.

What you're describi= ng sounds good, but you've picked the wrong syntax for it. Look at the = semantics again:
- We want to add a semi-standardized diagnostic = for an existing construct
- We need a way to annotate the constru= ct in order to suppress the diagnostic
- The annotation should ha= ve no effect on codegen

What kind of syntax does C= ++ already have for this kind of thing? Answer: attributes.
In fa= ct what you're proposing is basically identical to the existing C++17 a= ttribute [[maybe_unused]], in terms of its interactions with codegen and di= agnostics.

=C2=A0 =C2=A0 int x [[uninitialized]]; = =C2=A0// yes, compiler, I know this variable is uninitialized; please don&#= 39;t complain about it

=C2=A0 =C2=A0 struct Foo {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int m [[uninitialized]]; =C2=A0// yes= , compiler, I know this member isn't always initialized; please don'= ;t complain about it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Foo() { }
=C2=A0 =C2=A0 };

A proposal along these li= nes would sound good to me.
Sadly I'm not sure there's an= y prior art for actually giving such warnings. Maybe in compilers that supp= ort MISRA-C++...?

=E2=80=93Arthur

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/90f34150-9513-4b5a-a026-2d73334ece05= %40isocpp.org.
------=_Part_4961_508203819.1489896782172-- ------=_Part_4960_1994215863.1489896782172-- .