kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #38329
Re: [PATCH] Fix m_materials init-to-0
-
To:
John Beard <john.j.beard@xxxxxxxxx>, Kicad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Mário Luzeiro <mrluzeiro@xxxxx>
-
Date:
Fri, 9 Nov 2018 13:40:10 +0000
-
Accept-language:
en-GB, en-US
-
Authentication-results:
spf=none (sender IP is ) smtp.mailfrom=mrluzeiro@xxxxx;
-
In-reply-to:
<CAG1r56JZBEe_gwDTO10erhzPjvrk09p_C=WvhWi9N9w0DJwZ5g@mail.gmail.com>
-
Spamdiagnosticmetadata:
NSPM
-
Spamdiagnosticoutput:
1:99
-
Thread-index:
AQHUeCY4OegD5pG/Ek2CJNtkORbz3aVHXmLQgAAPVACAAARnYw==
-
Thread-topic:
[Kicad-developers] [PATCH] Fix m_materials init-to-0
Thanks, it's clear as mud!
I guess next time I will take as option to do a proper initialization element by element in a WYSIWYG fashion ;)
________________________________________
From: John Beard <john.j.beard@xxxxxxxxx>
Sent: 09 November 2018 13:20:38
To: Mário Luzeiro; Kicad Developers
Subject: Re: [Kicad-developers] [PATCH] Fix m_materials init-to-0
Hi Mário,
In C++11, this is list-initialisation, which has various behaviours
depending on what you are initialising. In this case:
* m_materials is class type with default ctor, so value-init it.
Value-init of aggregates with {} does aggregate-init. This does
list-init of each member with {}:
* SMATERIAL is the same, so list-init each member with {}:
* glm::vec3f's is the same (explicit "= default" in the hpp
file), so list-init each member with {}:
* 3 floats are value-inited (-> 0.0f, in whatever the
implementation's floating point type is, most likely IEEE-754)
* floats are value-inited (as above)
In C++14, this is *slightly* different in that aggregate-init comes
before value-init for class type with default ctors. So the step goes
right from list-init to aggregate-init (skipping the value-init). The
result is the same.
Pre-C++11, there was no list-initialisation, so this would just be
aggregate-init, which would do value-init directly.
Clear as mud, right?
FYI, memset-to-0 for floating point is unsafe/non-portable in C too
(unless you can guarantee that the format is IEEE-754, but that's not
in the standard): 6.2.6 Representations of types, 1.1: "The
representations of all types are unspecified except as stated in this
subclause."
Cheers,
John
On Fri, Nov 9, 2018 at 12:28 PM Mário Luzeiro <mrluzeiro@xxxxx> wrote:
>
> Hi John,
>
> Thanks for proper fix that code. That illustrate how much "C programmer" I was at the time..
> Is the "= {}" initialization available on all C++ versions?
>
> Mario Luzeiro
>
> ________________________________________
> From: Kicad-developers <kicad-developers-bounces+mrluzeiro=ua.pt@xxxxxxxxxxxxxxxxxxx> on behalf of John Beard <john.j.beard@xxxxxxxxx>
> Sent: 09 November 2018 12:20:01
> To: Kicad Developers
> Subject: [Kicad-developers] [PATCH] Fix m_materials init-to-0
>
> Hi,
>
> Simple patch to fix a use of memset to reset an array of floats and
> glm::vec3f's to 0.
>
> This is unsafe, not least as float types have implementation-defined
> value representations [1]. Memory-0 = float-0 is true for IEEE-754,
> and glm::vec3f happens to not have any book-keeping data that could be
> smashed by this (if m_materials contained a std::string or
> std::vector, this would be very bad karma), so it does happen to work.
>
> Cheers,
>
> John
>
> [1]: http://www.open-std.org/jtc1/sc22/open/n2356/basic.html#basic.fundamental
Follow ups
References