[MPlayer-dev-eng] [PATCH] fix SAMI parsing

[Howard Chu]

Reimar Döffinger wrote:
> On Mon, Jun 07, 2010 at 03:29:20PM -0700, Howard Chu wrote:
>> I respect your attention to detail and security-consciousness. I
>> don't respect your treatment of this topic with superstition,
>> instead of facts.
>> I gave you solid facts - a binary number read from a base16 string
>> cannot overflow the original space - and you're the one handwaving
>> them away.
>>
>> You gave a completely valid criticism - negative numbers need to be
>> checked. Unicode is only defined for 0-0x7fffffff, i.e., positive
>> only, and I've addressed that. The rest is just superstition.
>
> You've addressed one specific issue I gave, without changing your
> argument one bit despite it having failed before.
> Where do you suddenly get the confidence that your way of arguing
> should suddenly work now since it failed once?
> I agree you are very, very, very likely right, but repeating an
> argument that has already been shown to be insufficient as "proof"
> does not make it a proof.

It is not an argument, or a belief, or an opinion. It is a simple fact. 
Whether I am confident or not doesn't change the facts. Converting a textual 
representation of a positive integer into binary will always use fewer bits 
than the original text. It amazes me that this even needs to be discussed.

Even in hexadecimal - one digit stores 16 values or 4 bits. But each digit is 
represented by an entire octet, 8 bits. So naturally going from character 
representation to binary, the space required will decrease by half. Number 
bases smaller than 16 store even fewer bits per digit. How can you dispute 
these facts?

In the worst case, converting "0x7fffffff" to UTF-8 takes 6 bytes while 
"0x7fffffff" is obviously 10 bytes. These are inherent properties of 
arithmetic, not opinions or beliefs. If you want to argue against this you 
might as well argue against Earth's gravity.

> And since I suspect nobody really wants to waste the time doing it
> properly (e.g. I am not certain what strange strtoul implementations
> may exist in addition, probably they keep to the specification on
> all supported systems or deviate in a way that does not matter here,
> who knows), I suggested a rather simple solution.

strtoul() is specified in ANSI and a bunch of other C standards. If you can't 
rely on its behavior on a given platform then probably none of your software 
will work on that platform anyway.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/