[FFmpeg-devel] Eliminating long

Jay L. T. Cornwall jay
Mon Mar 31 01:57:10 CEST 2008


Uoti Urpala wrote:

> It's only unsafe if you interpret it to guarantee something else than
> what you can expect from "long" in the environment(s) you want to
> support. IMO that shouldn't be too hard to get right.

If 'long' is used knowingly differently from 'int', when similar types
in the public structures are explicitly sized or just 'int', one would
at least question why.

But, yes, if you write code properly that used sizeof(field) then there
would be no issue. I just see no good reason to keep it as the ambiguous
'long' when 'int' serves just as much purpose and does not vary in
mainstream compilers.

>>  It would fail catastrophically under the 
>> choice of your compiler, including a mainstream compiler on a mainstream 
>> platform (VC x64).

> This is a fundamental misconception on your part. It's not the compiler
> with determines the size of 'long', unlike what you had in your table
> ("GCC 64-bit"). It's the platform and its ABI that determines what the
> compilers must produce. If gcc and VC produced different sizes _for the
> same ABI_ that would not be just a compiler difference but a blatant bug
> in at least one of them.

Yes, I mixed up the compiler and the ABI. But that does not detract from
my point: if somebody interpreted that long field to be anything other
than uint32_t, it would break under compilers that choose to implement
it differently. A variable type like 'long' adds nothing that explicitly
sized fields does not.

I'm not going to continue this pedantic discussion in public. It's an
ever worse waste of developers' time and inboxes. Let's just agree to
disagree on the philosophy of programming.

-- 
Jay L. T. Cornwall
http://www.jcornwall.me.uk/





More information about the ffmpeg-devel mailing list