[milters] Archive

Lists Index Date Thread Search

Article: 708
From: Kevin Rosenberg
Date: 2005-08-27 13:16:15 -0400
Subject: Re: libsnert/milter-ahead on AMD64

Removal...........: milters-request@milter.info?subject=remove
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:

Right.

> 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.
 
-- 
Kevin Rosenberg
kevin@rosenberg.net

Lists Index Date Thread Search