Re: p6: maximum delta-seconds of 2147483648

On 2013-11-15 09:16, Willy Tarreau wrote:
> (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(!).

But this is true for parsing Content-Length as well, for instance. Do we 
need to state it there as well?

Best regards, Julian

Received on Friday, 15 November 2013 08:38:40 UTC