Thanks Ian. This looks good. Patch merged.
-Seth
On 2019-08-05 10:39, Ian McInerney wrote:
The updated patch using constexpr (which now only affects the color4d
files) is attached.
Simon, thanks for the suggestion to use constexpr. It ended up working
by just declaring the variables
The updated patch using constexpr (which now only affects the color4d
files) is attached.
Simon, thanks for the suggestion to use constexpr. It ended up working by
just declaring the variables constexpr and also making one of the
constructors constexpr. Definitely much simpler.
-Ian
On Mon, Aug
On 8/5/19 5:03 AM, Simon Richter wrote:
> Hi,
>
> On Mon, Aug 05, 2019 at 10:58:44AM +0200, Ian McInerney wrote:
>
>> I tracked it down to the fact that COLOR4D has some static colors that were
>> being used to initialize some other static variables in pcbnew's layer
>> widgets. I have moved all
Forgot that I split the updating the widget into a separate commit. Here is
an updated patch that just fixes the initialization (I updated the message).
-Ian
On Mon, Aug 5, 2019 at 10:58 AM Ian McInerney
wrote:
> I decided to instrument my debug build with the address sanitizer and see
> what
Hi,
On Mon, Aug 05, 2019 at 10:58:44AM +0200, Ian McInerney wrote:
> I tracked it down to the fact that COLOR4D has some static colors that were
> being used to initialize some other static variables in pcbnew's layer
> widgets. I have moved all the static colors to an initialize on first use
>
I decided to instrument my debug build with the address sanitizer and see
what happened, and it has pointed out an initialization order fiasco in the
loading of pcbnew.
I tracked it down to the fact that COLOR4D has some static colors that were
being used to initialize some other static variables
6 matches
Mail list logo
