why having a variable size type as first field and fixed as other in
Mix_Chunk struct ?
typedef struct {
int allocated;
Uint8 abuf;
Uint32 alen;
Uint8 volume; / Per-sample volume, 0-128 */
} Mix_Chunk;
Well, first of all, nothing is variable here in any way that matters -
unless you try to send this struct as is over the network or something,
but that would just be silly. In fact, only ‘volume’ is consistent across
all platforms - alen is affected by endian, and ‘abuf’ is a pointer.
Anyway, the reason is probably that ‘alen’ must be a full 32 bit int - no
room for a sign, and definitely no chance to get away with a 16 bit int.
‘allocated’ OTOH, is probably a C style boolean, or a use count variable
or something, so size and sign doesn’t matter much how - the CPUs native
format is prefered for performance.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 13 November 2001 02:42, Lloyd Dupont wrote:
why having a variable size type as first field and fixed as other in
Mix_Chunk struct ?typedef struct {
int allocated;
Uint8 abuf;
Uint32 alen;
Uint8 volume; / Per-sample volume, 0-128 */
} Mix_Chunk;
why having a variable size type as first field and fixed as other in
Mix_Chunk struct ?typedef struct {
int allocated;
Uint8 abuf;
Uint32 alen;
Uint8 volume; / Per-sample volume, 0-128 */
} Mix_Chunk;Well, first of all, nothing is variable here in any way that matters -
int is system dependent.
on future itanium it would be 64 bit.
i know pointer size is sytem dependant, but this is not a problem to me.
but allocated is a problem to me, i would prefer Sint32.
why i have these problem ?
i try to wrap these in an other language. where standart type have fixed
(platform independant) size. except for pointer where it is simply
system size.
so (Uint8 *) woul well translate pointer to pointer
Uint8 would well translate Uint8 -> byte
but int (allocated) would not.
when itanium comes i have to release a new version of my library for it.
but these other language, normally, don’t need such procedure, so these
worry me.
ok, but if i have no choice i just think i could do some hack, but i
just want to be sure…
i don’t want to offense anyone.
Lloyd
int is system dependent.
on future itanium it would be 64 bit.
i know pointer size is sytem dependant, but this is not a problem to me.
but allocated is a problem to me, i would prefer Sint32.
There’s actually a couple of places in SDL with this trouble (I’m thinking
of SDL_RWops, specifically, which use “int” for the number of objects
read/written, which may be a problem, and for the number of bytes to seek,
which is most definitely a problem), and they should be flushed out,
except it breaks binary compatibility to do so. Probably best to wait for
SDL 1.3 to fix them.
Generally speaking, these are sometimes oversights (as is probably the
case in SDL_mixer), and in some cases, it’s intentional, since (at least
in theory) “int” could be more optimized than “Sint32”, as it represents
the platform’s natural word size.
–ryan.
int is system dependent.
on future itanium it would be 64 bit.
i know pointer size is sytem dependant, but this is not a problem to me.
but allocated is a problem to me, i would prefer Sint32.
There’s actually a couple of places in SDL with this trouble (I’m thinking
of SDL_RWops, specifically, which use “int” for the number of objects
read/written, which may be a problem, and for the number of bytes to seek,
which is most definitely a problem), and they should be flushed out,
except it breaks binary compatibility to do so. Probably best to wait for
SDL 1.3 to fix them.
Yup.
Generally speaking, these are sometimes oversights (as is probably the
case in SDL_mixer), and in some cases, it’s intentional, since (at least
in theory) “int” could be more optimized than “Sint32”, as it represents
the platform’s natural word size.
Yup.
Correct on all counts. 
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment