While I agree that in principle lengths should be unsigned, the reason that
we picked to make them signed, was because some programming languages on
some platforms have problems with unsigned when the full unsigned integer
range is used. The compares don't work. So we opted to effectively give up
half the range and make the data type of the length field be a SIGNED SHORT
(16-bit) INTEGER.
Remember our old AD's saying: In theory there is no difference between
theory and practice, but in practice there is.
Tom
P.S. The folks who insisted on a binary format at the pivotal IPP San Diego
meeting when we made this decision will remain nameless :-)
-----Original Message-----
From: pmoore@netreon.com [mailto:pmoore@netreon.com]
Sent: Monday, January 29, 2001 13:24
To: Carl Kugler
Cc: Michael Sweet; Mike Bartman; ipp@pwg.org; ifx@pwg.org
Subject: Re: IFX> Re: IPP> New data types
gosh - you are right - the length is signed - thats not right - lengths
should
be unsigned.
"Carl Kugler" <kugler@us.ibm.com> on 01/29/2001 01:08:29 PM
To: Michael Sweet <mike@easysw.com>
cc: Paul Moore/AUCO/US@AUCO, Mike Bartman <bartman@process.com>,
ipp@pwg.org,
ifx@pwg.org
Subject: Re: IFX> Re: IPP> New data types
Since the length field is SIGNED-SHORT (2BYTE). I think it probably only
goes up to 32,767.
-Carl
Michael Sweet <mike@easysw.com>@pwg.org on 01/29/2001 01:17:24 PM
Sent by: owner-ifx@pwg.org
To: pmoore@netreon.com
cc: Mike Bartman <bartman@process.com>, ipp@pwg.org, ifx@pwg.org
Subject: IFX> Re: IPP> New data types
pmoore@netreon.com wrote:
>
> I had had similar thoughts (I was imagining Text, BigText (16-bit)
> and HugeText (32-bit))
> ...
Except that the length field in the current IPP encoding only
supports values up to 65535 octets in length...
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Tue Mar 06 2001 - 14:12:49 EST