From: Kevin Rosenberg
Date: 2005-08-27 13:16:15 -0400
Subject: Re: libsnert/milter-ahead on AMD64
More information..: http://www.milter.info/#Support
Anthony Howe wrote:
> Also the ANSI C89 standard states that:
> size_t is the unsigned integral type returned by the
> sizeof operator.
That's a good standard with a clear and intuitive definition.
> Therefore size_t should be able to represent the size of the largest
> possible memory chunk, since:
> Now I'm surprised that sizeof (size_t) != sizeof (socklen_t), because
> they both describe the size of memory objects. Someone else has provided
> me with an AMD 64 Gentoo account and the following test shows
I'm glad you got that account. I was preparing one for you, but I'm
sure the Gentoo amd64 account should not vary materially from a Debian
amd64 system at this OS level.
My suspicion is that Linux decided to make an 'optimization' and
decided that the size of the memory block for a network address will
not be longer than 32 bits.
> sizeof (size_t) > sizeof (socklen_t)
Yep, that's what linux is defining.
> Which is counter intuitive.
Perhaps, I'm not familiar enough on the idioms or definition of
socklen_t to have an opinion.
> Anyways. There are indeed several isses related to the size of a "long"
> type on AMD 64, which is 8 bytes instead of 4. I think I've always
> understand teh C standard to define char as 8 bits, short as 16, long as
> 32, and the common type extension "long long" as 64.
If I recall correctly, K&R has a statement very much like that in
their appendix. In the AMD64 documentation (and also practically in
Debian alpha64 and sparc64), the widths are
char 8 bits
short 16 bits
int 32 bits
long 64 bits
long long 128 bits (gcc)
So, from a portability standpoint these days, one can count on int
being 32-bits and that long varies across platforms. That's quite
different than the 16-bit CPU days: int was 16 bits and long was 32
bits. In the 16-bit to 32-bit transition, the long type was the
constant at 32-bits and that int size varied between 16-bit and 32-bit
platforms. I believe that was the point of K&R's table. These days,
that constancy is reversed.
> Anyways, because of this I've already fixed Dns.c and I'm going through
> some of the other LibSnert functions making corrections concerning AMD 64.
Great, that's good news.
As an aside, I'm new to your software. But, I think your directory
layout and coding style is very, very nice.
Copyright 2009, 2012 by SnertSoft. All rights reserved.