Re: [AD] SF.net SVN: alleg:[12193] allegro/branches/4.9/addons/memfile/memfile.c |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] SF.net SVN: alleg:[12193] allegro/branches/4.9/addons/memfile/memfile.c
- From: Elias Pschernig <elias.pschernig@xxxxxxxxxx>
- Date: Mon, 11 May 2009 05:09:08 +0200
On Mon, 2009-05-11 at 04:27 +0200, Evert Glebbeek wrote:
> On 10 May 2009, at 16:30 , elias@xxxxxxxxxx wrote:
> > Log Message:
> > -----------
> > Fixed two warnings. Can't we replace all uses of size_t and offset_t
> > with int64_t?
>
> No.
Why not? E.g. al_ftell returns int64_t - and it has to, as even with a
32-bit compiler you of course need the correct offset at all times. I
just see no reason why some other functions should use different types -
it just means programs break in case numbers above 31/32-bit actually do
occur. With int64_t (where required, normal int otherwise) everything
would always work.
>
> > - if (mf->size - mf->pos < size) {
> > + if (mf->size - mf->pos < (int64_t)size) {
>
> Isn't the logic backwards here?
> Shouldn't the LHS of the comparison here rather be size_t?
>
No idea. If we would use int64_t everywhere, it again would just always
work with no need to ever cast anything. But I guess I'm missing
something, there must be a reason e.g. libc also is using such types.
--
Elias Pschernig <elias@xxxxxxxxxx>