[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi Anders,

Well, the naming of the variables isn't very intuitive IMHO.

I'm not familiar with the root cause of this bug report, which Joost
filed. Joost, please provide samples of the problems, otherwise we're not
in a position to help you.

Anders, we'll have to wait for word from Joost before we can get any
further.

Thanx,
Jaap


On Mon, 26 Dec 2005, Anders Broman wrote:

> Hi,
> The current code is:
> /*
>  * This routine will pars in a XML vendor entry.
>  */
> static int
> xmlParseVendor(xmlNodePtr cur)
> {
>   char *name=NULL, *code=NULL, *id=NULL;
>
>   /* First, get our properties */
>   id = XmlStub.xmlGetProp(cur, "vendor-id");           -> "Merrit"
>   name = XmlStub.xmlGetProp(cur, "name");		-> "Merrit Networks"
>   code = XmlStub.xmlGetProp(cur, "code");              -> "61"
>
>   if (!id || !name || !code) {
> 	report_failure( "Invalid vendor section.  vendor-id, name, and code
> must be specified");
> 	return -1;
>   }
>
>   return (addVendor(atoi(code), id, name));     -> 61,"Merrit","Merrit
> Networks"
>
> } /* addVendor */
> :
> > Line 692:
> > static int
> > addVendor(int id, const gchar *name, const gchar *longName)
>
> The "problem" might be that "Code" is called "id" here?
>
> Also the code is working on Diameter samples and dictionaries that I have,
> so the question is what problem it's supposed to fix?
> One problem might be that the dissector can only translate vendor Id's
> that?s defined in the xml files if xml is used. If xml isn't used it'll fall
> back and use the internal values from sminpec.c which has a lot of values
> defined. So perhaps if the parsing of vendor id's is made not to work
> You'll get "better" translation of vendor ID's?
>
> Brg
> Anders
> -----Ursprungligt meddelande-----
> Fr?n: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] F?r Jaap Keuter
> Skickat: den 25 december 2005 21:10
> Till: Ethereal development
> ?mne: Re: SV: SV: [Ethereal-dev] Ethereal fails to correctly
> adddiametervendors from the dictionary xml files [PATCH]
>
> Oke lets see,
>
> <vendor vendor-id="Merit" code="61" name="Merit Networks"/>
>
> Which is fead into xmlParseVendor()
>
> ---------8<---------------
> static int
> xmlParseVendor(xmlNodePtr cur)
> {
>   char *name=NULL, *code=NULL, *id=NULL;
>
>   /* First, get our properties */
>   id = XmlStub.xmlGetProp(cur, "vendor-id");
>   name = XmlStub.xmlGetProp(cur, "name");
>   code = XmlStub.xmlGetProp(cur, "code");
> ---------8<---------------
>
> Which yealds these pointers:
>   id = "Merit"
>   code = "61"
>   name = "Merit Networks"
>
> ---------8<---------------
>
>   if (!id || !name || !code) {
>         report_failure( "Invalid vendor section.  vendor-id, name, and code
> must be specified");
>         return -1;
>   }
>
>   return (addVendor(id, atoi(code), name));
>
> }
> ---------8<---------------
>
> Which yealds:
>   return (addVendor("Merit", 61, "Merit Networks"));
>
> ---------8<---------------
> static int
> addVendor(int id, const gchar *name, const gchar *longName)
> {
>   VendorId *vendor;
>
>   /* add entry */
>   vendor=g_malloc(sizeof(VendorId));
>   if (!vendor) {
>         return (-1);
>   }
>
>   vendor->id = id;
>   vendor->name = g_strdup(name);
>   vendor->longName = g_strdup(longName);
>   vendor->next = vendorListHead;
>   vendorListHead = vendor;
>
>   return 0;
> } /* addVendor */
> ---------8<---------------
>
> So, in addVendor(), for 'id' using a (char *) as an (int) and for 'name'
> an (int) as a (const gchar *). What's wrong with this picture?
>
> Shouldn't the patch be like this:
> -  return (addVendor(id, atoi(code), name));
> +  return (addVendor(atoi(code), id, name));
>
> Which yealds:
>   return (addVendor(61, "Merit", "Merit Networks"));
>
> It seems that the patches proposed earlier were based on older code
> already. Hmmm, confuzzing to say the least..... :-/
>
> Thanx,
> Jaap
>
>
>
> On Sun, 25 Dec 2005, Anders Broman wrote:
>
> > Hi,
> > As I understand the function addVendor:
> > Line 692:
> > static int
> > addVendor(int id, const gchar *name, const gchar *longName)
> >
> > Where id is the Vendor Id as an Integer, Name is the short Vendorname,
> > LongName is the 'long vendorname' should be called as it is today?
> >
> >
> > Brg
> > Anders
> >
> > -----Ursprungligt meddelande-----
> > Fr?n: ethereal-dev-bounces@xxxxxxxxxxxx
> > [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] F?r Jaap Keuter
> > Skickat: den 25 december 2005 18:05
> > Till: Ethereal development
> > Kopia: Joost Yervante Damad
> > ?mne: Re: SV: [Ethereal-dev] Ethereal fails to correctly add
> diametervendors
> > from the dictionary xml files [PATCH]
> >
> > Hi Anders,
> >
> > This patch is different from the one you are refering to.
> >
> > http://www.gossamer-threads.com/lists/ethereal/dev/40347
> > That one states:
> > -  return (addVendor(atoi(code), id, name));
> > +  return (addVendor(atoi(id), code, name));
> >
> > while Joost proposes:
> > -  return (addVendor(atoi(code), id, name));
> > +  return (addVendor(id, atoi(code), name));
> >
> > Which seems to fit
> > <vendor vendor-id="Merit" code="61" name="Merit Networks"/>
> > as mentioned by Guy in the thread.
> >
> > Please contact Joost Yervante Damad <joost@xxxxxxxxxx>
> > for further details.
> >
> > Thanx,
> > Jaap
> >
> > On Sun, 25 Dec 2005, Anders Broman wrote:
> >
> > > Hi,
> > > That patch is faulty as previously noted on this list.
> > > Brg
> > > Anders
> > >
> > > -----Ursprungligt meddelande-----
> > > Fr?n: ethereal-dev-bounces@xxxxxxxxxxxx
> > > [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] F?r Jaap Keuter
> > > Skickat: den 25 december 2005 11:04
> > > Till: Ethereal Developer Mailinglist
> > > Kopia: Joost Yervante Damad
> > > ?mne: [Ethereal-dev] Ethereal fails to correctly add diameter vendors
> from
> > > the dictionary xml files [PATCH]
> > >
> > > Hi list,
> > >
> > > In the Debian bug database is an entry from Joost Yervante Damad
> > > <joost@xxxxxxxxxx>
> > > concerning the diameter dissector:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316082
> > >
> > > I've ported the patch to revision 16893, so it's ready for inclusion.
> For
> > > further details refer to the Debian bug report or Joost.
> > >
> > > Thanx,
> > > Jaap
> > >
> > >
> > > _______________________________________________
> > > Ethereal-dev mailing list
> > > Ethereal-dev@xxxxxxxxxxxx
> > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >
> > >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>