[FFmpeg-devel] Eliminating long

[Jay L. T. Cornwall]

Uoti Urpala wrote:

> Normally compilers follow an ABI, and the ABI will define the size of
> 'long'. If you really wouldn't know the ABI used then you couldn't do
> much with a library (there would be much more significant problems than
> 'long').

There may be an obscure way of handling this; however, I'm not aware of 
it. The UnmanagedType.Sys* ABI-specific space does not contain a 
definition for long.

> The C specification allows varying size for basically everything except
> the intXX_t types, including 'int'.
> 
> If C# really makes it that hard to interface with C libraries I'd
> consider using a better language.

Switching languages for every minor flaw is a poor use of one's time. In 
fact, you would never find the ideal language. Likewise, I can guarantee 
that FFmpeg's own developers have made assumptions about type sizes all 
over the code base that violate the standard. There's a trade-off 
between absolute correctness and time and programmers learn the balance 
appropriate for themselves.

I'll rephrase this, if this makes a better incentive: ByteIOContext is 
type unsafe if anyone is interpreting ByteIOContext.checksum field to be 
anything other than a uint32_t. It would fail catastrophically under the 
choice of your compiler, including a mainstream compiler on a mainstream 
platform (VC x64).

So, in addition to fixing that problem, it gives the flawed .NET 
framework (this isn't a C# language issue per se) a leg up. Are we just 
arguing for fun (it is fun!), or is there a real, practical reason not 
to change the structure?

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