Re: [Kicad-developers] please apply small typo patch

Le 09/11/2018 à 15:13, Marco Ciampa a écrit : > TIA > Thanks. I committed a fix. FYI, panel_setup_layers_base.cpp is automatically generated from panel_setup_layers_base.fbp -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-devel

[Kicad-developers] Jenkins build is back to normal : linux-kicad-full-gcc-head #4275

See ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-devel

[Kicad-developers] please apply small typo patch

TIA -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 >From 539fcb288035c4f79b9bf0355b658f05366a6b7e Mon Sep 17 00:00:00 2001 From: Marco Ciampa Date: Fri, 9 Nov 2018 15:03:58 +0100

Re: [Kicad-developers] [PATCH] Fix m_materials init-to-0

In this case, if you did not trust the default construction of glm::vec3f, you could provide a user-defined ctor to SMATERIAL. But in this case, that's not required. Quick note, on closer inspection, KiCad sets GLM_FORCE_CTOR_INIT, so we will actually be calling a user-defined ctor (which does the

Re: [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 Sent: 09 November 2018 13:20:38 To: Mário Luzeiro; Kicad Developers Subject: Re: [Kicad-developers

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 {}:

[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 b