X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=jMhvfoCtNL5xRt9JsNAndq5H2ata35SJOuHhzzCEGiU=;
b=b57oKuA0hq5NAZyhFj4a/OfvFTjtLwLjvhCCrfkdQgO37knQON2bW1G+Y+g0HRy9gt
2uqd1TaweqomHRNs/43/V46vEYQehi9UeRFz1ibdT6UPVo3SPXIyupgh9ULOMdsZYJ2v
ytfVWUCrwFzgJVxaXl5P4fuyeV3MCFC4SdjCpd3VsB3joRbOFFtVbMvRMxovg2s3WB4j
jT77GJzfZCienul1MpLLg/QvPZjHrjWztEw+rWiLmU6jjIN0WpiGIQGvf5meLmdS4FvZ
ibqEDEuXJvHX5kFUJin7vopWTCX/oXrIE7rwtuJ3BS4CB0jbzqF3p6ilFSsgVjatp5qf
1VXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=jMhvfoCtNL5xRt9JsNAndq5H2ata35SJOuHhzzCEGiU=;
b=PWGsS+xAb/mx0xD4boT/tLv3ar4DLNllf9Ou799qF0Z2amwelvQ8XNtM/nFE4JKiz0
0k6RAZj7Y/GACYx+PcNBzYWATpW3JVMTICbM1ea9ac9E6sbnq7pBu2pFru/LV65ZH+Pb
Qj3bmf5QitNASdw6SQP50BP+OLl7FnCRVvSNwPrsfesGigeLlDmfeUcXgpW9XJkj0P97
9XzLZ2KDr4ualyGyhlc6G2+Fq7StftKgExPj77kWrJt9MDPRQqfihPUGwHZuDQMEOCG1
80Ti+EDOfHyQOlcKH1vIahAPp/J16P3e2EcGHV5vur4jvtmC0HBILm3UXtXp+DiFFMJ9
Mzkg==
X-Gm-Message-State: AIkVDXLPwmaMdHG6yys9/zrRLYESoVxRQcRzbK50L8+pRgi3OXEEIJ2ss+CX/hvjcCtnwhsEUYrS7PwGPHMB5Q==
X-Received: by 10.28.173.4 with SMTP id w4mr4692949wme.70.1482327004935; Wed,
21 Dec 2016 05:30:04 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <48368219-0b52-59aa-139d-a3dc69b12a2c@sbcglobal.net>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1612200951240 DOT 7286 AT igor2priv> <CAJZxidAeHVwHXq9jdvnMF08Z_nXK+tHVf6MLB-YiJrOT4zUJDg AT mail DOT gmail DOT com>
<48368219-0b52-59aa-139d-a3dc69b12a2c AT sbcglobal DOT net>
From: "Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date: Wed, 21 Dec 2016 08:30:04 -0500
Message-ID: <CAJZxidCWrLf3x4XizBE5SA7EPo0m4UBMsTx=U_NDd_+3zCp6sQ@mail.gmail.com>
Subject: Re: [geda-user] [pcb] bugreport
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary=001a1144214e9201e005442b261a
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk
--001a1144214e9201e005442b261a
Content-Type: text/plain; charset=UTF-8
Girvin-
Yes, we have been talking about a release for mainline, and you're
absolutely right that it needs to happen. I think that the problem has
mostly been just finding the time to do it. I think I'll start a thread on
this right now actually.
--Chad
On Tue, Dec 20, 2016 at 5:49 PM, Girvin R. Herr (gherr375 AT sbcglobal DOT net)
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> Greetings,
>
> Is there any plan to release a new stable version of gEDA and pcb soon
> with all these bugfixes our good friends at pcb-rnd (what does "rnd" stand
> for anyway?) and others have found and suggested to add to the "mainline"
> version?
>
> I have been using the "mainline" 20140316 version of PCB and the 1.8.2
> (20130925) version of gEDA (gschem, mostly) for years now. Isn't it about
> time to at least test the 1.9.2 (20150930) "unstable" version to make it
> the "stable" version and "kick it out the door"?!
>
> No wonder potential users think gEDA is dying (I hope not) and don't want
> to invest in it. If I were in a production environment (I'm retired now)
> and responsible for production tool selection, I would have second thoughts
> about selecting a tool that is over 3 years old with no apparent activity.
> No software is that good!
>
> Just my 2-cents and, I hope, constructive criticism. Thanks.
> Girvin Herr
>
>
>
> On 12/20/2016 05:03 AM, Chad Parker (parker DOT charles AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
> Thanks. I filed the bug report in Launchpad.
>
> On Tue, Dec 20, 2016 at 4:18 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>> Hi all,
>>
>> FlagType is a struct; FLAGS_EQUAL attempts to compare two flags using
>> memcmp() on the full struct.
>>
>> While this happens to work at the moment on the most common platforms,
>> it's wrong, because the C standard lets the compiler to:
>>
>> - insert padding between struct fields (except before the first), to
>> achieve whatever alignment it sees fit, in an "implementation-defined
>> manner"
>>
>> - may append an "unnamed padding" at the end of the struct, which will be
>> counted in sizeof()
>>
>> Thus memcmp() may go and compare potentially uninitialized padding
>> fields, saying two equal flags are not equal because of differences in
>> uninitialized bytes.
>>
>> Why it works at the moment is: the first field is a long, which is wide
>> enough that the second field won't need alignment on the most common
>> current platforms, and MAX_LAYER is 16 so t[] ends up being 8 characters
>> long which is usually good enough not to add pads to the end of the struct
>> by most compilers today. But neither of these are guaranteed. Raising
>> MAX_LAYER to 18 could probably break it. The other reason is that the macro
>> is used only once in the code (minus external plugins) and it probably gets
>> 0-initialized flag structs all (or most of) the time - I was too lazy to
>> trace this back.
>>
>> It is a trap for future development: if you extend the struct, it may get
>> random new paddings even on current platforms/compilers, which could break
>> in hard-to-detect ways. (I found this memcmp() only because I did extend
>> the flag struct in pcb-rnd and it did get some padding - but now I will go
>> an search for all memcmp()s in the code).
>>
>> I've fixed this in pcb-rnd; I recommend fixing this in mainline too, by
>> comparing the struct field by field.
>>
>> (In theory it could be fixed by making sure all bytes of all flag fields
>> are always 0-initialized, sure these get memset() to 0 all the time even by
>> future code sounds less safe. But it's up to mainline devs to decide.)
>>
>> Regards,
>>
>> Igor2
>>
>
>
>
--001a1144214e9201e005442b261a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Girvin-<br><br></div>Yes, we have been talking a=
bout a release for mainline, and you're absolutely right that it needs =
to happen. I think that the problem has mostly been just finding the time t=
o do it. I think I'll start a thread on this right now actually.<br><br=
></div>--Chad<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Tue, Dec 20, 2016 at 5:49 PM, Girvin R. Herr (<a href=3D"mailto:gh=
err375 AT sbcglobal DOT net">gherr375 AT sbcglobal DOT net</a>) [via <a href=3D"mailto:ge=
da-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a hr=
ef=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p>Greetings,</p>
<p>Is there any plan to release a new stable version of gEDA and pcb
soon with all these bugfixes our good friends at pcb-rnd (what
does "rnd" stand for anyway?) and others have found and sug=
gested
to add to the "mainline" version?</p>
<p>I have been using the "mainline"=C2=A0 20140316 version of=
PCB and the
1.8.2 (20130925) version of gEDA (gschem, mostly) for years now.=C2=
=A0
Isn't it about time to at least test the 1.9.2 (20150930)
"unstable" version to make it the "stable" versio=
n and "kick it
out the door"?!</p>
<p>No wonder potential users think gEDA is dying (I hope not) and
don't want to invest in it.=C2=A0 If I were in a production envir=
onment
(I'm retired now) and responsible for production tool selection, =
I
would have second thoughts about selecting a tool that is over 3
years old with no apparent activity.=C2=A0 No software is that good!<=
br>
</p>
<p>Just my 2-cents and, I hope, constructive criticism.=C2=A0 Thanks.<s=
pan class=3D"HOEnZb"><font color=3D"#888888"><br>
Girvin Herr</font></span></p><div><div class=3D"h5">
<p><br>
</p>
<br>
<div class=3D"m_-4242469372538703484moz-cite-prefix">On 12/20/2016 05:0=
3 AM, Chad Parker
(<a class=3D"m_-4242469372538703484moz-txt-link-abbreviated" href=3D"=
mailto:parker DOT charles AT gmail DOT com" target=3D"_blank">parker DOT charles AT gmail DOT com=
</a>) [via <a class=3D"m_-4242469372538703484moz-txt-link-abbreviated" href=
=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</=
a>] wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Thanks. I filed the bug report in Launchpad.<br>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Dec 20, 2016 at 4:18 AM, <span d=
ir=3D"ltr"><<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu" target=3D"_blank">ged=
au AT igor2 DOT repo DOT hu</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
FlagType is a struct; FLAGS_EQUAL attempts to compare two
flags using memcmp() on the full struct.<br>
<br>
While this happens to work at the moment on the most common
platforms, it's wrong, because the C standard lets the
compiler to:<br>
<br>
- insert padding between struct fields (except before the
first), to achieve whatever alignment it sees fit, in an
"implementation-defined manner"<br>
<br>
- may append an "unnamed padding" at the end of the s=
truct,
which will be counted in sizeof()<br>
<br>
Thus memcmp() may go and compare potentially uninitialized
padding fields, saying two equal flags are not equal because
of differences in uninitialized bytes.<br>
<br>
Why it works at the moment is: the first field is a long,
which is wide enough that the second field won't need
alignment on the most common current platforms, and
MAX_LAYER is 16 so t[] ends up being 8 characters long which
is usually good enough not to add pads to the end of the
struct by most compilers today. But neither of these are
guaranteed. Raising MAX_LAYER to 18 could probably break it.
The other reason is that the macro is used only once in the
code (minus external plugins) and it probably gets
0-initialized flag structs all (or most of) the time - I was
too lazy to trace this back.<br>
<br>
It is a trap for future development: if you extend the
struct, it may get random new paddings even on current
platforms/compilers, which could break in hard-to-detect
ways. (I found this memcmp() only because I did extend the
flag struct in pcb-rnd and it did get some padding - but now
I will go an search for all memcmp()s in the code).<br>
<br>
I've fixed this in pcb-rnd; I recommend fixing this in
mainline too, by comparing the struct field by field.<br>
<br>
(In theory it could be fixed by making sure all bytes of all
flag fields are always 0-initialized, sure these get
memset() to 0 all the time even by future code sounds less
safe. But it's up to mainline devs to decide.)<br>
<br>
Regards,<br>
<br>
Igor2<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>
--001a1144214e9201e005442b261a--