[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

Hello Peter

On 8/10/06, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> Jonathan Dion wrote:
> >
> ...
>
> > > Name: XYZ UPS 1000
> > > VendorID: 0x0003
> > > ProductID: 0x0004
> > > ===
> > > Name: XYZ UPS 1001
> > > VendorID: 0x0005         # since productID != 0 (line 152), the
> > >                          # parser will call print_ups(0005,0004), a bug
> >
> > For once you are wrong here ^^. The "===" line set up productID and
> > vendorID to 0, so it won't call print_ups. I used this mechanism to be
> > able to have VendorID and ProductID in any order.
>
> No, the parser will set productID and vendorID to 0 *if* new_entry == 1.
> (line 134). In the particular sequence that I gave, new_entry would
> have been 0, so this bug would have happened.
>

Yes, you are rights. I should have set productID and vendorID to 0
whatever the value of new_entry is.
But it is the past, I don't anymore use this part of code ^_^ (but I
alway like to discute code and bugs)

>
> Oops, my solution also contains a bug similar to the new_entry bug:
> should have been:
>
>              } else if (*p == '=') {  /* any line starting with '=' */
>                 if (have_record) {
>                     print_record(vendorid, productid, ...);
>                 }
>                 have_record = 0;
>                 product_id = 0;
>                 vendor_id = 0;
>                 ...;
>              }
>
> -- Peter
>

Yes, I saw this little bug and corrected it in the version I use. What
you propose is still not enough, because product ID and vendor ID
_can_ be equal to 0.

I use a system of byte to know what have been set and is not. I'll
soon commit the last version of migratetool (which will be nammed
migrateconfig, because it is more appropriate)

For the conversion hex char to int, I used I functions written by
Linus Torvalds himself for the kernel, so I think it works ^_^

Jonathan