| [AD] [ alleg-Bugs-2830708 ] avoid long in public interfaces |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Bugs item #2830708, was opened at 2009-08-01 15:08
Message generated for change (Settings changed) made by tjaden
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2830708&group_id=5665
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 4.9
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: Peter Wang (tjaden)
Assigned to: Nobody/Anonymous (nobody)
Summary: avoid long in public interfaces
Initial Comment:
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.
----------------------------------------------------------------------
Comment By: Elias Pschernig (elias)
Date: 2009-08-26 07:11
Message:
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.
----------------------------------------------------------------------
Comment By: Evert Glebbeek (eglebbk)
Date: 2009-08-26 05:00
Message:
How do you propose to do that? The file size returned by stat() is of type
off_t.
There's a reason the standard library defines these types for returning
sizes of various kinds. It really is better to use them when writing
portable code rather than deciding on our own that some other integer type
is always better. That assumes we know better than whoever wrote the C
library for every particular system out there. That's probably not true.
I've run into more problems where people use ints where they should have
used size_t (or ptrdiff_t) than the other way around.
Of course, that doesn't fix broken situations like MSVC and MinGW
disagreeing on the size of basic data types, but that is in a sense
orthogonal to the question of whether these specialised datatypes should be
used or not. If anything, it's a stronger argument in favour since there's
at least a chance that these have been defined to have a similar size
between the two compilers (and if not, that can be worked around).
----------------------------------------------------------------------
Comment By: Elias Pschernig (elias)
Date: 2009-08-26 04:27
Message:
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.
----------------------------------------------------------------------
Comment By: Thomas Fjellstrom (strangemoose)
Date: 2009-08-26 04:20
Message:
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.
----------------------------------------------------------------------
Comment By: Elias Pschernig (elias)
Date: 2009-08-25 22:56
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2830708&group_id=5665