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:

=20 =20 =20

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 sug= gested to add to the "mainline" version?

I have been using the "mainline"=C2=A0 20140316 version of= PCB and the 1.8.2 (20130925) version of gEDA (gschem, mostly) for years now.=C2= =A0 Isn't it about time to at least test the 1.9.2 (20150930) "unstable" version to make it the "stable" versio= n 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.=C2=A0 If I were in a production envir= onment (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.=C2=A0 No software is that good!<= br>

Just my 2-cents and, I hope, constructive criticism.=C2=A0 Thanks.
Girvin Herr

On 12/20/2016 05:0= 3 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, <ged= au 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 s= truct, 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