delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/12/21/08:31:58

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

--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&#39;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&#39;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">&lt;<a hr=
ef=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com=
</a>&gt;</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 &quot;rnd&quot; stand for anyway?) and others have found and sug=
gested
      to add to the &quot;mainline&quot; version?</p>
    <p>I have been using the &quot;mainline&quot;=C2=A0 20140316 version of=
 PCB and the
      1.8.2 (20130925) version of gEDA (gschem, mostly) for years now.=C2=
=A0
      Isn&#39;t it about time to at least test the 1.9.2 (20150930)
      &quot;unstable&quot; version to make it the &quot;stable&quot; versio=
n and &quot;kick it
      out the door&quot;?!</p>
    <p>No wonder potential users think gEDA is dying (I hope not) and
      don&#39;t want to invest in it.=C2=A0 If I were in a production envir=
onment
      (I&#39;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">&lt;<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu" target=3D"_blank">ged=
au AT igor2 DOT repo DOT hu</a>&gt;</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&#39;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
            &quot;implementation-defined manner&quot;<br>
            <br>
            - may append an &quot;unnamed padding&quot; 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&#39;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&#39;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&#39;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--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019