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=1482274257; bh=1ZkrRFwW+QpdFVwUXLD6yoYP+j4Cs2kjuZB5QSq8w6Y=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To:From:Subject; b=XbhPUfg31Vf+10bw9h98nvvg66D/ylSE+HZzf/mMmqgzFNQ+hmWcdOk7+ZQ0h61E+VgGWtIx5suvvNQLUrVCMHP3KyuGzIJPrNd1oiqqKqsrVD6pOpNmew//ML1b4M/gfp/FFUyEFPWSlrWWLZVMhmByzAujc1izqInMCQdPUdF0M7ttTAD38UjD7TIKgVOuG5zTCRXWjxQjI8CJd+/2vXgxJ7r+MYJ13sUCZCAqGE6dF5syvaA3G8if5jDuPSfAvUXL7CvIXqDD3w5NORJR6hgZyPqIYZH6i0OiVu/M3/3L+SSX34Ys45GL0wDK1jrZ5plvF9WzGmV6wTJjAAoOKA==
X-Yahoo-Newman-Id: 932128 DOT 49062 DOT bm AT smtp117 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: N1.wzekVM1m0TG5AYzBJSNzNULgxeKtxr2TOuww5tFUonOI
 cXgYYRarvhQB1KMJgAhOj7.wp8GQl5wPPn.JoU3um4glInHb46F1dAteDaL6
 YUi8sZcOJcPkiqZLyA0399SeOvXS_TaL7cDzpFY.M8l.3kCrPsHRPg2wD9a9
 EtZ3dadJBnRKyZkuKYEAB6KagpI8i1NMJUHfSH_O1XTanI4PwtRbxPj7p2nm
 W6BKWfzWrlaifrZjrpqDeIgmv25VnNtHhhi7u.shAqJ311YrpGAz6Ve9Tcxf
 azTZHLMntIBnx8ScG0DUgaT1mw6T97Me1YFllmKTSOQ36Ab2ms3Udz96cL7Y
 suqyeUy4REhde1SHwnYYGsljvrCmUB4_q4qyARWnWJWejLHhAryHMdl_R1PN
 jztG2_kKyNi86GeMHFsAWYfS5KXiHDoSc4zOShWnYiIh_EKGQ5cx6_yKMu.e
 9UpIB_vPpAHUme1rF2YlSXJ98BNiFmBiN3V8zxE0wPDQONluig0KaaDverTf
 sBKNhTNzLqVhN.lgjgLJkxVC.RqtiFe_DOGKdUQT6Io4Zz7raeoBUCnpwwRW
 I
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>
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: <48368219-0b52-59aa-139d-a3dc69b12a2c@sbcglobal.net>
Date: Tue, 20 Dec 2016 14:49:26 -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: <CAJZxidAeHVwHXq9jdvnMF08Z_nXK+tHVf6MLB-YiJrOT4zUJDg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------4348DB26AC1CF2C5D946AEE7"
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

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

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


--------------4348DB26AC1CF2C5D946AEE7
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>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.<br>
      Girvin Herr</p>
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 12/20/2016 05:03 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:CAJZxidAeHVwHXq9jdvnMF08Z_nXK+tHVf6MLB-YiJrOT4zUJDg AT mail DOT gmail DOT com"
      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>
  </body>
</html>

--------------4348DB26AC1CF2C5D946AEE7--