Mail Archives: geda-user/2016/12/21/17:30:07
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"><<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>></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"><<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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>
--------------7650A73754C6B5CC5BC10F5B--
- Raw text -