[wpkg-users] Revision handling inconsistency - base assumptions in parseInt() with leading zeros

[Mark Cooke]

Hi all,

Anyone else seen the following with 0.9.10?  I was attempting an update from
Stellarium 0.8.2 to 0.9.0, and I'd formulated the WPKG revision ID from the
software version number, plus an extra trailing digit in I needed to change
the deployment without there being a new Stellarium release.

So the revision number changed from 0821 to 0900 in my package.

However:

1. Running a /query:u

Stellarium Virtual Observatory
    ID:           stellarium
    Old Revision: 0821
    New Revision: 0900
    ExecAttribs:  null
    Status:       updatable

(so far so good)

2. Running a /synchronize:

<no output> - it didn't update the version.  Oops!



I've done some testing and this appears to be a 'gotcha' with leading zeros.
A bit of wscript research shows that the parseInt() function assumes a
leading 0 indicates octal, and so the wpkg.js /synchronize check:

  parseInt(0821) < parseInt(0900) becomes 0 < 0

as neither revision is a valid octal number.

What was inconsistent was that /query:u did correctly identify the increment
in revision.  The revision check in queryUpgradable() doesn't use parseInt()
to force a numeric comparison, and in the purely alphanumeric string
comparison, 0821 is less than 0900.


I've worked around this by prefixing all my package revisions that began
with '0' with an extra '0x' to avoid the assumption of octal, but perhaps
this is worthy of a note in the wiki about revision ids, or some other
software fix.

Could /synchronise and /query:u be updated to use consistent checks in
0.8.11 please!  In the most simple case, adding 2 parseInt() calls to the
queryUpgradable function would work.[*]

Cheers,

Mark Cooke

[*] For my specific problem, changing the parseInt calls in /synchronize to
be parseInt(x,16) would have fixed this, as I use 'base-consistent'
numbering within packages.

However, if a site mixed octal, hex and decimal revision formats then there
are some cases that using parseInt(x,16) would break.

A contrived example:

  parseInt("0100",16)=256  >  parseInt("0xFF",16)=255

It gives a different result without the radix force to 16:

  parseInt("0100")=64      <  parseInt("0xFF")=255



wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users