X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Message-ID: <3C63319A.2E193983@yahoo.com>
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
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> <3C630FB1 DOT E69F87A AT cyberoptics DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 84
Date: Fri, 08 Feb 2002 06:00:06 GMT
NNTP-Posting-Host: 12.90.167.33
X-Complaints-To: abuse AT worldnet DOT att DOT net
X-Trace: bgtnsc05-news.ops.worldnet.att.net 1013148006 12.90.167.33 (Fri, 08 Feb 2002 06:00:06 GMT)
NNTP-Posting-Date: Fri, 08 Feb 2002 06:00:06 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eric Rudd wrote:
> 
> 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.

Who knows what goes on in the printf conversion and the cast.  IT
IS ILLEGAL. So the system can output anything it feels like.  Note
that the %p specification outputs are reasonable, and always 8
byte aligned.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
   void *ptr;
   int   v;
   int   a, i;

   for (i = 0; i < 18; i++) {
     ptr = malloc(1023);
     v   = (int)ptr;
     if      (!(v & 31)) a = 32;
     else if (!(v & 15)) a = 16;
     else if (!(v & 7))  a = 8;
     else if (!(v & 3))  a = 4;
     else if (!(v & 1))  a = 2;
     else                a = 1;
     printf(" ptr %p is %2d-byte aligned. (int)p = %d6\n",
             ptr, a, v);
   }
   return 0;
}

c:\dnld\scratch>a
 ptr 205d8 is  8-byte aligned. (int)p = 1325686
 ptr 209e0 is 32-byte aligned. (int)p = 1336006
 ptr 20de8 is  8-byte aligned. (int)p = 1346326
 ptr 25508 is  8-byte aligned. (int)p = 1528406
 ptr 25918 is  8-byte aligned. (int)p = 1538806
 ptr 25d28 is  8-byte aligned. (int)p = 1549206
 ptr 26138 is  8-byte aligned. (int)p = 1559606
 ptr 26548 is  8-byte aligned. (int)p = 1570006
 ptr 26958 is  8-byte aligned. (int)p = 1580406
 ptr 26d68 is  8-byte aligned. (int)p = 1590806
 ptr 27178 is  8-byte aligned. (int)p = 1601206
 ptr 27588 is  8-byte aligned. (int)p = 1611606
 ptr 27998 is  8-byte aligned. (int)p = 1622006
 ptr 27da8 is  8-byte aligned. (int)p = 1632406
 ptr 281b8 is  8-byte aligned. (int)p = 1642806
 ptr 285c8 is  8-byte aligned. (int)p = 1653206
 ptr 289d8 is  8-byte aligned. (int)p = 1663606
 ptr 28de8 is  8-byte aligned. (int)p = 1674006

0x205d8 * 10 + 6 = 1325686, for example.

(gcc 2.953, DJGPP 2.03)

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:uce AT ftc DOT gov  (for spambots to harvest)