X-Authentication-Warning:	delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient:	geda-help AT delorie DOT com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type;
	bh=gZN5jniWaPRQyxzI0eAw8w2Ppp0vvWqm9I/zN6jtsmI=;
	b=jGBGMJtt+FYZK2jPcOKJKfo7wF8OdC31tpgmWDlhFfms7ClOHzbTZiPMLAebnoRRFr
	AfC0C8HFp9AvYsRt1HsJpFO8x7f7KRbJTXazxTNK9LIDg4phf7MWZpdUP06cJDYIuJNz
	o/mVk4XEw+/xvJP5kVHbYb5Pj8eQ16U/2yBwCj9Ig57c32FG9p+yExlb+IE3FwxJCgve
	Rs0WDZPiy4Mhf3Iukdw4ENMnZ/SE0/nnT31mGZLa4JMyhEzrpOIEG5I9MLH5qQrNqYk4
	cxPo2SZn43REfvoVuJyB0N42/xH9mURsfv8zNtbwY212zibX0nqlw0MOA8uIFcSly/kc
	/0fw==
X-Gm-Message-State:	ALoCoQlifVC4kFygsI36k+xqO7CYUb5CKHphZduW4LQM7ZbijSXs8VNvzPECWFlA5pdaX/XVNLWn
X-Received:	by 10.194.187.101 with SMTP id fr5mr5638002wjc.76.1388684226323;
	Thu, 02 Jan 2014 09:37:06 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<CAGRhJMZEWsXnVuJ_pCKqBovr71trDFD_93HCpfLaaS-h99=wxA@mail.gmail.com>
References:	<CAGRhJMZEWsXnVuJ_pCKqBovr71trDFD_93HCpfLaaS-h99=wxA AT mail DOT gmail DOT com>
From:	Joshua Lansford <joshua DOT lansford AT laserlinc DOT com>
Date:	Thu, 2 Jan 2014 12:36:45 -0500
Message-ID:	<CAGRhJMYm3Hy2t6Ejkvm2hTPprQH6LwRqcqU2asJ4hBnaNASgVg@mail.gmail.com>
Subject:	[geda-help] Re: gnetlist silently drops components
To:	geda-help <geda-help AT delorie DOT com>
Reply-To:	geda-help AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-help AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--047d7bd6b9ac0400fe04ef003e84
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 2, 2014 at 8:52 AM, Joshua Lansford <
joshua DOT lansford AT laserlinc DOT com> wrote:

>
>   I just had a scare,  I was casually checking stuff into svn and noticed
> in a diffed netlist output that a component from one of our designs in
> production was missing a component.  I checked the schematic and the part
> was there all bright eyed and bushy tailed but it was completely missing
> from the generated netlist without any complaint from gnetlist.  I took a
> look at the schematic with vim and discovered I had a property missing a
> value.  I removed this valueless property and *ding* the component shows
> back up in the netlist when I run gnetlist.  Checking around some more with
> diff I discovered there was another component silently being dropped from
> the netlist.  gnetlist use to seg fault when there is a missing valued
> property.  Now apparently it silently assassinates the component.
>
> At first I thought I would just make a check script to make sure no
> components are dropped, but then I thought perhaps I might also be able to
> fix gnetlist and further this project.  But thought I would check in with
> everyone to make sure this isn't like this for a reason or perhaps has
> already been fixed.
> ~Joshua
>

The following change fixes the problem:

diff --git a/libgeda/src/o_attrib.c b/libgeda/src/o_attrib.c
index 5dae202..cb161a1 100644
--- a/libgeda/src/o_attrib.c
+++ b/libgeda/src/o_attrib.c
@@ -383,7 +383,7 @@ o_attrib_string_get_name_value (const gchar *string,
gchar **name_ptr, gchar **v
   prev_char = g_utf8_find_prev_char (string, ptr);
   next_char = g_utf8_find_next_char (ptr, NULL);
   if (prev_char == NULL || *prev_char == ' ' ||
-      next_char == NULL || *next_char == ' ' || *next_char == '\0' ) {
+      next_char == NULL || *next_char == ' ' ) {
     return FALSE;
   }


I did notice in the comment of the function o_attrib_string_get_name_value
that a valueless attribute is intentionally invalid.

 *  If you get an invalid attribute (improper) with a name and no
 *  value, then it is NOT an attribute.

What problems would it cause for the library to be tolerant to valueless
attributes?  According to this following link, I see that
o_attribute_string_get_name_value intolerance has caused other problems
already and resulted in a commit having to be reverted because it
standardized on this function making the code less stable.  This seems to
indicate to me that valueless attributes happen and allowing the code to
behave reasonably when they do would benefit everything in the long run.
http://archives.seul.org/geda/cvs/Sep-2008/msg00014.html

I have seen at least one other person in the past who couldn't figure out
why gnetlist was bombing until they figured out they had had a valueless
attribute.

Can this be discussed?

Thanks,
~Joshua

--047d7bd6b9ac0400fe04ef003e84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Jan 2, 2014 at 8:52 AM, Joshua Lansford <span dir=3D"ltr">&=
lt;<a href=3D"mailto:joshua DOT lansford AT laserlinc DOT com" target=3D"_blank">joshu=
a DOT lansford AT laserlinc DOT com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><br><div>=A0 I just had a scare, =A0=
I was casually checking stuff into svn and noticed in a diffed netlist outp=
ut that a component from one of our designs in production was missing a com=
ponent. =A0I checked the schematic and the part was there all bright eyed a=
nd bushy tailed but it was completely missing from the generated netlist wi=
thout any complaint from gnetlist. =A0I took a look at the schematic with v=
im and discovered I had a property missing a value. =A0I removed this value=
less property and *ding* the component shows back up in the netlist when I =
run gnetlist. =A0Checking around some more with diff I discovered there was=
 another component silently being dropped from the netlist. =A0gnetlist use=
 to seg fault when there is a missing valued property. =A0Now apparently it=
 silently assassinates the component.</div>


<div><br></div><div>At first I thought I would just make a check script to =
make sure no components are dropped, but then I thought perhaps I might als=
o be able to fix gnetlist and further this project. =A0But thought I would =
check in with everyone to make sure this isn&#39;t like this for a reason o=
r perhaps has already been fixed.</div>

<span class=3D""><font color=3D"#888888"><div>~Joshua</div></font></span></=
div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">The following chang=
e fixes the problem:</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><div class=3D"gmail_extra">diff --git a/libgeda/src/o_attr=
ib.c b/libgeda/src/o_attrib.c</div>

<div class=3D"gmail_extra">index 5dae202..cb161a1 100644</div><div class=3D=
"gmail_extra">--- a/libgeda/src/o_attrib.c</div><div class=3D"gmail_extra">=
+++ b/libgeda/src/o_attrib.c</div><div class=3D"gmail_extra">@@ -383,7 +383=
,7 @@ o_attrib_string_get_name_value (const gchar *string, gchar **name_ptr=
, gchar **v</div>

<div class=3D"gmail_extra">=A0 =A0prev_char =3D g_utf8_find_prev_char (stri=
ng, ptr);</div><div class=3D"gmail_extra">=A0 =A0next_char =3D g_utf8_find_=
next_char (ptr, NULL);</div><div class=3D"gmail_extra">=A0 =A0if (prev_char=
 =3D=3D NULL || *prev_char =3D=3D &#39; &#39; ||</div>

<div class=3D"gmail_extra">- =A0 =A0 =A0next_char =3D=3D NULL || *next_char=
 =3D=3D &#39; &#39; || *next_char =3D=3D &#39;\0&#39; ) {</div><div class=
=3D"gmail_extra">+ =A0 =A0 =A0next_char =3D=3D NULL || *next_char =3D=3D &#=
39; &#39; ) {</div><div class=3D"gmail_extra">

=A0 =A0 =A0return FALSE;</div><div class=3D"gmail_extra">=A0 =A0}</div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">I did notice in the comment of the function o_attrib_=
string_get_name_value that a valueless attribute is intentionally invalid.<=
/div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_extra">=A0* =A0If you get an invalid attribute (improper) with a =
name and no</div><div class=3D"gmail_extra">=A0* =A0value, then it is NOT a=
n attribute.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">What proble=
ms would it cause for the library to be tolerant to valueless attributes? =
=A0According to this following link, I see that o_attribute_string_get_name=
_value intolerance has caused other problems already and resulted in a comm=
it having to be reverted because it standardized on this function making th=
e code less stable. =A0This seems to indicate to me that valueless attribut=
es happen and allowing the code to behave reasonably when they do would ben=
efit everything in the long run.</div>

<div class=3D"gmail_extra"><a href=3D"http://archives.seul.org/geda/cvs/Sep=
-2008/msg00014.html">http://archives.seul.org/geda/cvs/Sep-2008/msg00014.ht=
ml</a>=A0</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">I have seen at least one other person in the past who couldn&#39;t figu=
re out why gnetlist was bombing until they figured out they had had a value=
less attribute.=A0</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Can this be=
 discussed?</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">Thanks,</div><div class=3D"gmail_extra">~Joshua</div></div></div></di=
v>

--047d7bd6b9ac0400fe04ef003e84--

- Raw text -