Re: [hackers] [quark][PATCH] Fix overflow when calling strtonum in parse_range

2020-10-31 Thread Laslo Hunhold
On Sun, 1 Nov 2020 01:15:32 +0100
José Miguel Sánchez García  wrote:

Dear José,

> Good point! It could be the case that SIZE_MAX is smaller than 
> LLONG_MAX. Honestly I don't know, but I would do what you are
> proposing just to be sure: it is the safest option, and maybe the
> compiler will take care of replacing the correct value at compile
> time. Way better than leaving another bug lingering until someone
> else finds it again.

we should be safe at that point and I have committed the MIN-solution
in commit 7d26fc695. Thanks for your report!

With best regards

Laslo



Re: [hackers] [quark][PATCH] Fix overflow when calling strtonum in parse_range

2020-10-31 Thread José Miguel Sánchez García

On 10/31/2020 11:27 PM, Laslo Hunhold wrote:


this is a great catch, thanks! But wouldn't it be better to use
MIN(SIZE_MAX, LLONG_MAX)?

I haven't found anything in the standard that puts "long long" and
"size_t" into any relation, which means, for me, that any case is
possible where either value could be larger, but please correct me if
I'm wrong.


Good point! It could be the case that SIZE_MAX is smaller than 
LLONG_MAX. Honestly I don't know, but I would do what you are proposing 
just to be sure: it is the safest option, and maybe the compiler will 
take care of replacing the correct value at compile time. Way better 
than leaving another bug lingering until someone else finds it again.


Best regards,
José Miguel




Re: [hackers] [quark][PATCH] Fix overflow when calling strtonum in parse_range

2020-10-31 Thread Laslo Hunhold
On Sat, 31 Oct 2020 21:58:26 +
José Miguel Sánchez García  wrote:

Dear José,

> The value passed as maxval, SIZE_MAX, doesn't fit on a long long int
> due to signedness. It was causing legitimate range request to be
> discarded as bad.
> 
> I tested it serving an mp4 and opening it with Firefox. A "range=0-"
> was requested, and it triggered the bug.

this is a great catch, thanks! But wouldn't it be better to use
MIN(SIZE_MAX, LLONG_MAX)?

I haven't found anything in the standard that puts "long long" and
"size_t" into any relation, which means, for me, that any case is
possible where either value could be larger, but please correct me if
I'm wrong.

With best regards

Laslo