#227 avoid long in public interfaces

Peter Wang

Due to differing widths of 'long' by different compilers on 64-bit versions of Windows we need to avoid using 'long' in the public interfaces. Mostly plain int will suffice. The main culprit here is kcm_audio.


  • Elias Pschernig

    Elias Pschernig - 2009-08-25

    For the same reason, we should avoid size_t and off_t I'd say. Mostly file routines seem to be using those at places.

  • Thomas Fjellstrom

    Nah. The entire point to using size_t and off_t is that they change size depending on if the system is 32bit or 64bit. they WON'T change size based on compiler, which is what the bug is about.

  • Elias Pschernig

    Elias Pschernig - 2009-08-25

    Yes, size_t and off_t have uses - but not in the public API. E.g. filesizes > 4GB should be reported even when size_t is only 32 bit.

  • Elias Pschernig

    Elias Pschernig - 2009-08-25

    Erm, libc is the library which has strcpy in it - so I'd think almost everyone knows better than libc. Likely no other library ever caused as many portability and other problems as libc.

    If our API uses uint64_t (where it makes sense), then that's the type it uses. It's the same with all compilers and on all platforms. It can never create any problems whatsoever and is immediately clear to everyone which type is being used.

    The libc types are the very opposite - you are supposed to write your code in a way which works with all possible choices of size_t and off_t, never being able to assume anything. It's a different design goal, it offloads all the work to users and makes it very hard to write your code. Allegro I'd say is on the other hand, it handles all the platform differences for the user and doesn't want them to have to mess with possibly changed APIs when they recompile on another platform, suddenly breaking working code for no good reason.

    As for how to implement it, that has nothing to do with it, it's just driver implementation. If off_t is defined as 32-bit in some versions of libc, then that's a platform limitation and Allegro's API shouldn't be modified because of it. If off_t is always 64 bit anyway, then even more reason to just use uint64_t directly and not hide what it is behind another type.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks