- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 15 Nov 2013 09:16:56 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@gmx.de>
- Cc: Eliot Lear <lear@cisco.com>, HTTP Working Group <ietf-http-wg@w3.org>
(replying to your two e-mails at once, I'm in a hurry and late) On Thu, Nov 14, 2013 at 11:36:37PM -0800, Roy T. Fielding wrote: > > That is consistent with the previous requirement of "MUST use an arithmetic type of at least 31 bits of range", no? > > Yes, but I feel for Willy's desire to get rid of the apparent > contradiction altogether ... but not that much. > > I suggest we use the original 31 bits of range, remind folks that > it is unsigned, and explain that the 2147483648 can be used as a > canned numeric string on overflow even if they happen to be forced > to use a signed 32bit storage. *sigh* Seems reasonable eventhough not looking nice. On Fri, Nov 15, 2013 at 08:40:34AM +0100, Julian Reschke wrote: > >Is there a reason for this type to be signed ? > > a) It's been implicitly like that before. OK > b) Java, for instance, doesn't have unsigned integers. OK I didn't know. > Of course we can add even more prose or even pseudo-code, and also > warnings about broken language libraries. But does this edge case > *really* require this? In fact it's not that much of an edge case if we suggest that a specific value has a special meaning, because that specific value will be hard-coded in some senders, making it less of an edge case and causing interop issues with the receivers which will read -1 or 0 there. > Can we please > > 1) focus on whether this is an improvement over RFC 2616, addressing te > LC comment, and/or > > 2) propose concrete changes? Probably that Roy's right. After all, if this is a specific value then it makes sense to warn the developer about the fact he might need to read the man or use strcmp(!). Best regards, Willy
Received on Friday, 15 November 2013 08:17:25 UTC