On Sun, Feb 25, 2007 at 12:26:00AM +0100, Frank B. Brokken wrote: > Well, first of all, thanks for your help. I'm sure it'll solve the problem for > the time being. But I'm left with an uneasy feeling. On the one hand I know > that what you write is true in principle. But on the other hand, I'm curious > about what might be going on in the Alpha what apparently doesn't happen on > other architectures. What's a size_t in the Alpha? If it's not in fact an > unsigned int but something bigger then I understand what's happening.
Yes, sizeof(size_t) = 8 on alpha, as it is on ia64 and amd64 as well, whereas sizeof(int) = 4 on all Debian architectures. > The intention here is to use size_t in situations where the value is known > to be non-negative. I don't see any reason why you should use size_t for that instead of unsigned int. size_t is intended for use in describing the size of objects in memory, not just for anything you know should be non-negative. > So, it may very well be an initialization problem, which should then also > be solved by initializing nargs to 0 when it's defined. Well, that would solve the problem for alpha, yes. It would still be wrong on big-endian 64-bit architectures. Granted, powerpc64, sparc64, and s390x aren't major targets for yodl, but in terms of overall correctness, it's still non-portable to pass a size_t * where an int * is requested -- on a big-endian arch, this ends up being a pointer to the high 32 bits, not the low 32bits. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
