Eliminating long

Hi,

The C 'long' type, used in the interoperable structure
ByteIOContext 
from avio.h, is causing problems with the Tao.FFmpeg C#
wrapper library.

   unsigned long checksum
   unsigned long (*update_checksum)(unsigned long checksum,
const 
uint8_t *buf, unsigned int size);

Most structures can be marshalled from C# to C and back
again with ease. 
However C# fixes sizeof(long) to be 8 bytes on all
platforms. In C it 
varies with platform and compiler:
   GCC 32-bit: 4 bytes
   GCC 64-bit: 8 bytes
   VC  32-bit: 4 bytes
   VC  64-bit: 4 bytes

There is no reliable way to marshall this type into a
managed structure 
on all platforms. Could I request that the type be made
explicit in 
ByteIOContext, as 'unsigned int' or 'uint32_t'.

Thanks,

-- 
Jay L. T. Cornwall
http://www.jcornwall.me.u
k/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Jay L. T. Cornwall wrote:
> 
> There is no reliable way to marshall this type into a
managed structure 
> on all platforms. Could I request that the type be made
explicit in 
> ByteIOContext, as 'unsigned int' or 'uint32_t'.

I'm not sure that's a good workaround... Cannot fix it on
your wrapper side?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/
~lu_zero

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, 2008-03-30 at 23:40 +0100, Jay L. T. Cornwall
wrote:
> Luca Barbato wrote:
> 
> >> There is no reliable way to marshall this type
into a managed structure 
> >> on all platforms. Could I request that the
type be made explicit in 
> >> ByteIOContext, as 'unsigned int' or
'uint32_t'.
> 
> > I'm not sure that's a good workaround... Cannot
fix it on your wrapper side?
> 
> Not reliably. The size of the ByteIOContext structure
depends on the 
> compiler that FFmpeg was built with. It's worse than a
32-bit/64-bit

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

> issue; unfortunately the C specification is lax enough
to permit that 
> for the long type. There's no way to detect how the
structure was built 
> from C#.

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.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Reimar Döffinger wrote:

> Huh, you mean there is no way to differentiate between
a 32 and a 64 bit
> library? That seems hard to believe...
> Either way, IMO the code at least lacks a comment as to
why long is used
> for all that checksum stuff, I currently can't seen any
sense in that...

Sorry, perhaps I worded that badly. .NET provides good
support for 
handling 32-bit/64-bit differences across platforms and it
will only 
link to libraries of the same bitness as the runtime
system.

It provides support for handling platform differences, like
sizeof(void 
*), but not ABI differences like sizeof(long). That type is
very 
problematic and, as far as I can see, is no more useful than
uint32_t 
and definitely more confusing.

There seems to be so much resistance to the idea of making
this simple 
change, it's not worth my effort to make its case any
longer. I'll just 
conditionally compile the type size in C# and limit the
runtimes I can 
support.

Thanks for your reply, at least, that was grounded in
practicality and 
not pedantry.

-- 
Jay L. T. Cornwall
http://www.jcornwall.me.u
k/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

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.u
k/

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Mon, Mar 31, 2008 at 12:15:59AM +0100, Jay L. T. Cornwall
wrote:
> 
> Likewise, I can guarantee that FFmpeg's own developers
have made
> assumptions about type sizes all over the code base
that violate the
> standard.

If you point them out I am sure they will be fixed in short
order.

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

That compiler is known broken and unsupported, mainstream as
it may be ...

Diego
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, 30 Mar 2008 23:09:27 +0100, Jay L. T. Cornwall
wrote:

>Hi,
>
>Most structures can be marshalled from C# to C and back
again with
>ease. However C# fixes sizeof(long) to be 8 bytes on all
platforms. In
>C it varies with platform and compiler:
>There is no reliable way to marshall this type into a
managed
>structure on all platforms. Could I request that the
type be made
>explicit in ByteIOContext, as 'unsigned int' or
'uint32_t'.


maybe i misunderstand this, but
could you just have ffmpeg print out what long it was
compiled to use
and then have your wrapper work around whichever long it was
?



-compn
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

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.u
k/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

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

FFmpeg's most favourite pass-time is bashing Windows and
anything
Microsoft-related... So yes, most of it is for fun...

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, Mar 30, 2008 at 11:40:36PM +0100, Jay L. T. Cornwall
wrote:
> Luca Barbato wrote:
> 
> >> There is no reliable way to marshall this type
into a managed structure 
> >> on all platforms. Could I request that the
type be made explicit in 
> >> ByteIOContext, as 'unsigned int' or
'uint32_t'.
> 
> > I'm not sure that's a good workaround... Cannot
fix it on your wrapper side?
> 
> Not reliably. The size of the ByteIOContext structure
depends on the 
> compiler that FFmpeg was built with. It's worse than a
32-bit/64-bit 
> issue; unfortunately the C specification is lax enough
to permit that 
> for the long type. There's no way to detect how the
structure was built 
> from C#.

Huh, you mean there is no way to differentiate between a 32
and a 64 bit
library? That seems hard to believe...
Either way, IMO the code at least lacks a comment as to why
long is used
for all that checksum stuff, I currently can't seen any
sense in that...

Greetings,
Reimar Döffinger
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel