Mail Archives: geda-user/2016/12/20/17:52:57
| 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>
|
| 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.
--------------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"><<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>></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--
- Raw text -