X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Message-ID: <3C630FB1.E69F87A@cyberoptics.com>
Date: Thu, 07 Feb 2002 17:37:21 -0600
From: Eric Rudd <rudd AT cyberoptics DOT com>
Organization: CyberOptics
X-Mailer: Mozilla 4.72 [en] (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Alignment problem
References: <3C629769 DOT AEAFB611 AT cyberoptics DOT com> <3C62A89A DOT 9DF630C5 AT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 31
NNTP-Posting-Host: 65.214.97.102
X-Trace: 1013125049 reader3.ash.ops.us.uu.net 5154 65.214.97.102
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

CBFalconer wrote:

> Is there a problem?  The (int) cast is not necessarily valid.  Try this
> modification (note alloc of 1023):
>
> It looks as if the integer conversion is multiplying by 10 and adding 6.

I don't see how you came to that conclusion.  When run on your machine, did
the program print out pointer values that always ended in 6?  (I'm
struggling to think of some plausible explanation.)  This would lead to the
conclusion that the pointer values were in the form 16n+6, not 10n+6, since
the pointers print out as hexadecimal.  I have no reason to suspect any bug
in the %p format specifier, and 8f4e4 hex is definitely not 8-byte aligned.

I tried your modified program, and it claimed that all the pointers were
4-byte aligned.

> Which shouldn't matter because it is undefined anyhow.

In the C standards sense, conversion of a pointer to an int may well be
undefined, but DJGPP actually does use 4-byte pointers that correspond to
the byte offset used to address the memory, so as far as I know, this is a
valid test.

At any rate, my floating-point routines run faster if I force these pointers
to be 8-byte aligned, which is functional evidence that there's an alignment
problem.

-Eric Rudd
rudd AT cyberoptics DOT com