prop_number(3) and portability of externalized plists

[Jonathan A. Kollasch]

Hi,

I'm bothered by the unconventional (for a Apple plists anyway) encoding
of unsigned integers in externalized proplib(3) plists.

At least Python's plistlib is unequiped to handle internalizing and
reexternalizing such numbers in base-16.

Is there a reason we absolutely need to have this
contrary-to-comment-in-Apple's-DTD encoding?

It seems to me that the unsigned attribute does not need to be
exposed outside of proplib.  When proplib internalizes a number
beyond INT64_MAX it can mark it as unsigned, and thus then later
externalize it as the same base-10 number.  The only difference I
can see such a change making is prop_number_unsigned(3) would
only claim a number beyond INT64_MAX was unsigned, but this
does not seem like it would be relied upon in existing code.

        Jonathan Kollasch

[Jason Thorpe]

On Oct 23, 2009, at 10:49 AM, Jonathan A. Kollasch wrote:

> Hi,
>
> I'm bothered by the unconventional (for a Apple plists anyway) encoding
> of unsigned integers in externalized proplib(3) plists.
>
> At least Python's plistlib is unequiped to handle internalizing and
> reexternalizing such numbers in base-16.

I am OK with changing to outputting base-10 always, but I would like to keep the ability to internalize base-16.  I am also OK just treating the number as int64_t (and thus outputting -ve numbers beyond INT64_MAX).

>
> Is there a reason we absolutely need to have this
> contrary-to-comment-in-Apple's-DTD encoding?
>
> It seems to me that the unsigned attribute does not need to be
> exposed outside of proplib.  When proplib internalizes a number
> beyond INT64_MAX it can mark it as unsigned, and thus then later
> externalize it as the same base-10 number.  The only difference I
> can see such a change making is prop_number_unsigned(3) would
> only claim a number beyond INT64_MAX was unsigned, but this
> does not seem like it would be relied upon in existing code.
>
> Jonathan Kollasch

-- thorpej

[Jonathan A. Kollasch]

On Fri, Oct 23, 2009 at 09:25:31PM -0700, Jason Thorpe wrote:

>
> On Oct 23, 2009, at 10:49 AM, Jonathan A. Kollasch wrote:
>
> > Hi,
> >
> > I'm bothered by the unconventional (for a Apple plists anyway) encoding
> > of unsigned integers in externalized proplib(3) plists.
> >
> > At least Python's plistlib is unequiped to handle internalizing and
> > reexternalizing such numbers in base-16.
>
> I am OK with changing to outputting base-10 always, but I would like to keep the ability to internalize base-16.  I am also OK just treating the number as int64_t (and thus outputting -ve numbers beyond INT64_MAX).
>

Well, I've worked up a patch that seems to do what I want,
you should find it attached.

It marks all numbers >= 0 as unsigned.  This seemed to be
necessary to do the likes of a prop_dictionary_get_uint8()
on <integer>169</integer> sucessfully.

        Jonathan Kollasch

Index: common/lib/libprop/prop_number.c
===================================================================
RCS file: /cvsroot/src/common/lib/libprop/prop_number.c,v
retrieving revision 1.22
diff -u -r1.22 prop_number.c
--- common/lib/libprop/prop_number.c 15 Mar 2009 22:29:11 -0000 1.22
+++ common/lib/libprop/prop_number.c 24 Oct 2009 20:52:14 -0000
@@ -195,12 +195,8 @@
  prop_number_t pn = v;
  char tmpstr[32];
 
- /*
- * For unsigned numbers, we output in hex.  For signed numbers,
- * we output in decimal.
- */
  if (pn->pn_value.pnv_is_unsigned)
- sprintf(tmpstr, "0x%" PRIx64, pn->pn_value.pnv_unsigned);
+ sprintf(tmpstr, "%" PRIu64, pn->pn_value.pnv_unsigned);
  else
  sprintf(tmpstr, "%" PRIi64, pn->pn_value.pnv_signed);
 
@@ -334,7 +330,10 @@
 
  memset(&pnv, 0, sizeof(pnv));
  pnv.pnv_signed = val;
- pnv.pnv_is_unsigned = false;
+ if (pnv.pnv_signed < 0)
+ pnv.pnv_is_unsigned = false;
+ else
+ pnv.pnv_is_unsigned = true;
 
  return (_prop_number_alloc(&pnv));
 }
@@ -546,7 +545,10 @@
     errno == ERANGE)
      return (false);
 #endif
- pnv->pnv_is_unsigned = false;
+ if (pnv->pnv_signed < 0)
+ pnv->pnv_is_unsigned = false;
+ else
+ pnv->pnv_is_unsigned = true;
  ctx->poic_cp = cp;
 
  return (true);

[David Holland-6]

On Fri, Oct 23, 2009 at 09:25:31PM -0700, Jason Thorpe wrote:
 > > I'm bothered by the unconventional (for a Apple plists anyway) encoding
 > > of unsigned integers in externalized proplib(3) plists.
 > >
 > > At least Python's plistlib is unequiped to handle internalizing and
 > > reexternalizing such numbers in base-16.
 >
 > I am OK with changing to outputting base-10 always, but I would
 > like to keep the ability to internalize base-16.  I am also OK just
 > treating the number as int64_t (and thus outputting -ve numbers
 > beyond INT64_MAX).

ISTM that if there's going to be a distinction between signed and
unsigned integer values, they should be tagged differently in the XML.
Is this hopelessly naive?

--
David A. Holland
dholland@...

[Jason Thorpe]

On Oct 28, 2009, at 9:50 PM, David Holland wrote:

> ISTM that if there's going to be a distinction between signed and
> unsigned integer values, they should be tagged differently in the XML.
> Is this hopelessly naive?

Let me double-check how the Mac OS X Core Foundation XML plist parser deals with numbers.

-- thorpej