[FFmpeg-devel] Eliminating long

[Måns Rullgård]

"Jay L. T. Cornwall" <jay at jcornwall.me.uk> writes:

> 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.

Show me.  They will be fixed.

> There's a trade-off between absolute correctness and time and
> programmers learn the balance appropriate for themselves.

Absolute correctness should always be the goal, no excuses.

> 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.

No, it is unsafe to interpret it as anything other than a long, that
being its declared type.  You are the one trying to interpret it as
uint32_t, and that is failing.

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

There is no rescue for a catastrophically failed compiler, no matter
how mainstream.  The sooner you realise this and move on, the better
for everyone.

> 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.

Just why would we have any interest whatsoever in that?

> Are we just arguing for fun (it is fun!), or is there a real,
> practical reason not to change the structure?

It is working now.  Until you can prove that a change will not
adversely affect a currently working system, the code stays the way it
is.

-- 
M?ns Rullg?rd
mans at mansr.com