[FFmpeg-devel] Eliminating long
Mon Mar 31 03:52:50 CEST 2008
"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
> 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
> 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
mans at mansr.com
More information about the ffmpeg-devel