Re: [AD] WIP 4.1.15 and CVS freeze

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-07-26 at 13:42 +0200, Evert Glebbeek wrote:
> > > How come "unsigned int" instead of "unsigned long"?
> > > 
> > 
> > Well, int just seemed to make more sense. Isn't long the same on the
> > common platforms anyway? I changed it to unsigned long in the first
> > patch actually, but Chris suggested "unsigned int" - and when thinking
> > about that it seemed to make more sense to me.
> 
> What's the libc way to handle this? If typical rest-like functions in the
> standard library take ints, then I think we should also use ints. If they take
> longs, then taking longs for Allegro would be proper too.
> 

Well, the unix functions use a struct with two long values, one for
seconds, one for us or even ns. Which I find kind of awkward, always
need to multiple/divide with 1000000 or 1000000000. Unix sleep is sleep
(unsigned int). Windows uses Sleep(DWORD), SDL uses SDL_Delay(Uint32).

> If there's no consensus on this, then the type should remain the same as it is
> now (but possibly unsigned) in my opinion. Not for API breakage but
> theoretically possible ABI breakage on some compilers. I doubt it's a real issue
> though.
> 

Yes, I didn't see any issue at all when changing it first. So, I'll
modify the patch to keep long, and apply it. We can worry about
generally cleaning types, and maybe even using the new C99 types like
uint32_t where it makes sense (and providing typedefs for platforms
without C99). Along that, we can athen lso get rid of all "long" values,
since that type makes little sense, given it is the same as int on most
32-bit platforms (and probably 64-bit as well).

> > Hm, don't know. I guess, where negative values make no sense, we should
> > use unsigned. I just thought about changing rest while working on it.
> 
> I think unsigned/signed correctness is like const correctness and would be a
> good thing to have. The usage of size_t rather than int for items that take the
> size of, say, an array would be along the same lines, and this is already on the
> TODO list.
> 

Yes - size_t also could be good. I'll just leave it at long now though,
since nobody so far agreed to change it to int.

-- 
Elias Pschernig