delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/12/21/17:30:07

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=sbcglobal.net; s=s2048; t=1482359318; bh=bhO4wpEsaoHm1tWX6myeKSbjxqEcy9F4n8bnmPlZNGU=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To:From:Subject; b=nmW4/fn9moBF7PpwKbhICQ7kwEFdYkAgwO/PzI3HTwRLti3zEPS2bq1zU9iBJRIPDl9AIHaKplZLfHPymphAGuG3kWHeSaa4re7vL/uDYwB3Rf5cC0wsxjW8oeuh7QaRHYvJpMx9OnzMzhYatHSrtDHrVWLOBsZtFKnIH7MwBdNz8/JtmgWxwEU0YWRRRO9bQwMfCNcfGgEKBQWDbLFnAOm5UR3Y8uyU7zvaUxyMVLI52eAmH2o1l4VmtPU79OSAdIoc0dW4R0jlhQ3Ki98npPqP56iIw/r5FFD781wP2NXjeHv2NGklrJMFmB7AcXCB3GpsdGIWg2mhyidVWKI76Q==
X-Yahoo-Newman-Id: 588197 DOT 24608 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: SUhWNm4VM1kHGsDLjIOuumCi.1vAFmUC_jFfHmSl3zCPClt
YlRXD_04jV3xBBq6V2Bosi8_SiNp.Rx8kFyk25YkxgG7G71M.Zdvb0U4Zep3
aT6udoQALzAXLiOQpAIqm.0pUvnxC6hE531AwzUBCWr4bw_qOqHoAikC4WEQ
Eb4u6951n8ThRcuG8aUxj.7roh.daSVB1QOrgwZJP1x5vmHluyj96_Kkinz0
8hEFupSnPV08Qopv7G2HbkCV9sUY22_Rr0x.FjcgVivREIQf4e0AwSNQgkZm
6cYa6RNOqLuxOgD__xGn0Rq1PwI8TCJv_fF.mPqTymZ88l1iZ1RSseLlGIFb
CeneswNZU8a6p01keS0XMnheqX8kBwlg.deXrh7JFUC75mrsn7prGDrxopSv
UvKzbQ3Ay415BKyTLFX4uVHa63q8QAPkdnm9EfAOjQ0EekZO_jpHWFIHtnS7
TvDb.lNTqRBJVwBLgidrSbZxy_4fIVdk0OwCw2vv.W4sOxuaa5IvI1eyjFB0
C3Jf4ix6VcAodOoiNrxIctV.8kDm6RSXGnrcYMqX7Kkef7XB451dTbMKYaZw
Y
X-Yahoo-SMTP: xaem6kSswBCHwCBMr0jlCBIQdXYGmRxsm8OX6ACyP7Ho9Sk-
Subject: Re: [geda-user] [pcb] bugreport
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>
<CAJZxidCWrLf3x4XizBE5SA7EPo0m4UBMsTx=U_NDd_+3zCp6sQ AT mail DOT gmail DOT com>
To: geda-user AT delorie DOT com
From: "Girvin R. Herr (gherr375 AT sbcglobal DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID: <af123997-5498-7b19-30dc-c000fcbaeec4@sbcglobal.net>
Date: Wed, 21 Dec 2016 14:27:07 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAJZxidCWrLf3x4XizBE5SA7EPo0m4UBMsTx=U_NDd_+3zCp6sQ@mail.gmail.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

This is a multi-part message in MIME format.
--------------7650A73754C6B5CC5BC10F5B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Chad,

Thanks for the reply.  Yes, time.  I know what you mean.

Sounds good.  I will continue to monitor it's progress on this forum.

Happy holidays.
Girvin



On 12/21/2016 05:30 AM, Chad Parker (parker DOT charles AT gmail DOT com) [via 
geda-user AT delorie DOT com] wrote:
> 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 <mailto:gherr375 AT sbcglobal DOT net>) [via 
> geda-user AT delorie DOT com <mailto:geda-user AT delorie DOT com>] 
> <geda-user AT delorie DOT com <mailto: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
>     <mailto:parker DOT charles AT gmail DOT com>) [via geda-user AT delorie DOT com
>     <mailto: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
>>     <mailto: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
>>
>>
>
>


--------------7650A73754C6B5CC5BC10F5B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Chad,</p>
    <p>Thanks for the reply.  Yes, time.  I know what you mean.<br>
    </p>
    <p>Sounds good.  I will continue to monitor it's progress on this
      forum.</p>
    <p>Happy holidays.<br>
      Girvin</p>
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 12/21/2016 05:30 AM, Chad Parker
      (<a class="moz-txt-link-abbreviated" href="mailto:parker DOT charles AT gmail DOT com">parker DOT charles AT gmail DOT com</a>) [via <a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:<br>
    </div>
    <blockquote
cite="mid:CAJZxidCWrLf3x4XizBE5SA7EPo0m4UBMsTx=U_NDd_+3zCp6sQ AT mail DOT gmail DOT com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>Girvin-<br>
            <br>
          </div>
          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.<br>
          <br>
        </div>
        --Chad<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Dec 20, 2016 at 5:49 PM, Girvin
          R. Herr (<a moz-do-not-send="true"
            href="mailto:gherr375 AT sbcglobal DOT net">gherr375 AT sbcglobal DOT net</a>)
          [via <a moz-do-not-send="true"
            href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
          <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#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 suggested to add to the
                "mainline" version?</p>
              <p>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"?!</p>
              <p>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!<br>
              </p>
              <p>Just my 2-cents and, I hope, constructive criticism. 
                Thanks.<span class="HOEnZb"><font color="#888888"><br>
                    Girvin Herr</font></span></p>
              <div>
                <div class="h5">
                  <p><br>
                  </p>
                  <br>
                  <div class="m_-4242469372538703484moz-cite-prefix">On
                    12/20/2016 05:03 AM, Chad Parker (<a
                      moz-do-not-send="true"
                      class="m_-4242469372538703484moz-txt-link-abbreviated"
                      href="mailto:parker DOT charles AT gmail DOT com"
                      target="_blank">parker DOT charles AT gmail DOT com</a>) [via
                    <a moz-do-not-send="true"
                      class="m_-4242469372538703484moz-txt-link-abbreviated"
                      href="mailto:geda-user AT delorie DOT com"
                      target="_blank">geda-user AT delorie DOT com</a>] wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">Thanks. I filed the bug report in
                      Launchpad.<br>
                    </div>
                    <div class="gmail_extra"><br>
                      <div class="gmail_quote">On Tue, Dec 20, 2016 at
                        4:18 AM, <span dir="ltr">&lt;<a
                            moz-do-not-send="true"
                            href="mailto:gedau AT igor2 DOT repo DOT hu"
                            target="_blank">gedau AT igor2 DOT repo DOT hu</a>&gt;</span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-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 struct, 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>
    </blockquote>
    <br>
  </body>
</html>

--------------7650A73754C6B5CC5BC10F5B--

- Raw text -


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