| [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 07:08
Message generated for change (Comment added) made by eglebbk
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: 5
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: Evert Glebbeek (eglebbk)
Date: 2009-08-25 21: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-25 20: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-25 20: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 14: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