X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <52C6CF5B.6020005@estechnical.co.uk> Date: Fri, 03 Jan 2014 14:55:23 +0000 From: Ed Simmons User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] Fwd: gnetlist silently drops components References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000007080105090406080801" X-Authenticated-As: ed AT estechnical DOT co DOT uk Reply-To: geda-user AT delorie DOT com This is a multi-part message in MIME format. --------------000007080105090406080801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/01/2014 12:38, Joshua Lansford wrote: > > On Thu, Jan 2, 2014 at 8:52 AM, Joshua Lansford > > > 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; > } > > > Cross posting this from gEDA-help because I never saw my posts come > through. > > Thanks, > ~Joshua > Good move Joshua! I hope this is rolled into the source by someone who can. :-) --------------000007080105090406080801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 03/01/2014 12:38, Joshua Lansford wrote:

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;

}

Cross posting this from gEDA-help because I never saw my posts come through.

Thanks,

~Joshua

Good move Joshua!

I hope this is rolled into the source by someone who can.

:-)

--------------000007080105090406080801--