🚀 go-pugleaf

On 26 Dec 1995 22:06:38 GMT, e8927426@fbma.tuwien.ac.at (Seda Oezses)
wrote:


>	STSHORT(10, buff + 1); 
>	i = LDSHORT(buff + 1);
>	printf("%d\n", i);
>
>	- On a SUN SPARCclasic (Solaris 2.4) the result was a Bus error.
>	- On a DECStation 5500 (ULTRIX 4.4) program run and printed 10 but with a
>	  message "Fixed up unaligned data access for pid 25977 (a.out) at pc 0x400678".
>	- On a RISC/6000 (AIX ??) program run without an error or warning.
>
>	
>Do you have any idea about why this little code produce such different results on
>different processors?

Sure. You are using typecasting to force a word or longer reference to
an odd memory address. Some processors are incapable of accessing
things bigger than a byte on an odd address, while others can do so,
but take a performance hit. It sounds like Ultrix has trapped the odd
address exception and fudged it for you - are those DEC people kind or
foolhardy? 

In general you should not try and do things like this. If you
absolutely must insert or extract word quantities on randomly aligned
addresses, you should do so by accessing a byte at a time and
reassembling the data, or by storing a byte at a time, e.g.

put2(unsigned char * ptr, unsigned short val)
{
	*ptr = val & 0xFF;
	ptr[1] = val >> 8;
}

but note that this is assuming little-endian byte ordering.

Happy New Year, Clyde
>
>
>
>
>--
>
>        ("\''/").___..--'''"-._
>       `9_ 9  )   `-.  (     ).`-.__.`)     S  E  D  A   O  Z  S  E  S
>       (_Y_.)'  ._   )  `._ `. ``-..-'
>     _..`--'_..-_/  /--'_.' .'              e8927426@fbma.tuwien.ac.at
>    (il).-''  ((i).'  ((i.-'
>

 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
 clyde@hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au  | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
----------------------------------------------------------------------------
FREE! Download our shareware (FREE for noncommercial use) MS-DOS C Compiler!
             Point your Web browser at http://www.hitech.com.au/

In article <4bprle$n2k@news.tuwien.ac.at>
           e8927426@fbma.tuwien.ac.at "Seda Oezses" writes:

>------------
>
>#include        ......

State the header files you include - this can be important.

>unsigned char   *buff;
>
>#define         MAXBUFF 128
>#define         LDSHORT(addr)   (ntohs (*( (unsigned short *) (addr) )))
>#define         STSHORT(sval, addr) (*( (unsigned short *)(addr)) =
> htons(sval))

The C language does not define functions ntohs() and htons(). However they
don't appear that they are not relevant to this particular problem.

>void main(void)

When posting to comp.lang.c please post C code. In C main returns an int.

>{
>        unsigned short i;
>
>        buff = (unsigned char *) calloc(MAXBUFF, sizeof(unsigned char));

In ANSI C this case is unnecessary.

>        STSHORT(10, buff + 1); 

This is illegal in ANSI C because it results in undefined behaviour - anything
can happen. The problem is that you convert a pointer to a pointer to
unsigned short which is not correctly aligned for that type, and then try to
dereference it.

>        i = LDSHORT(buff + 1);

Similarly here.

>        printf("%d\n", i);
>}

>
>Executing the above program gave three different results on three different
>processors and operating systems;
>
>        - On a SUN SPARCclasic (Solaris 2.4) the result was a Bus error.
>        - On a DECStation 5500 (ULTRIX 4.4) program run and printed 10 but with
> a
>          message "Fixed up unaligned data access for pid 25977 (a.out) at pc
> 0x400678".
>        - On a RISC/6000 (AIX ??) program run without an error or warning.

These are simply 3 ways in which undefined behaviour can manifest itself.
There are an innumberable number of other ways. These 3 observed behaviours
happen to come from the way the various processors/OSs deal with unaligned
accesses. On the SUN they simply cause a fault, on the DEC they are reported
but it deals with them (it is probably the OS patching up), on the RISC/6000
the system either deals with them in hardware, silently deals with the
in the OS or simply generates the wrong result. All that is pretty much
irrelevant though - the basic issue is that the code is broken and needs
to be fixed. Where possible I suggest you fix the data format that caused
them to be misaligned in the first place.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

In article <4bprle$n2k@news.tuwien.ac.at>,
Seda Oezses <e8927426@fbma.tuwien.ac.at> wrote:

> void main(void)

Anything can happen if you lie to the compiler. The function main
returns an int, nothing else.

> 	- On a SUN SPARCclasic (Solaris 2.4) the result was a Bus error.

This is what I expect if you do unaligned accesses.

> 	- On a DECStation 5500 (ULTRIX 4.4) program run and printed 10 but with a
> 	  message "Fixed up unaligned data access for pid 25977 (a.out) at pc 0x400678".

This is stupid. They are just trying to be kind, but are giving you a
huge performance penalty.

> 	- On a RISC/6000 (AIX ??) program run without an error or warning.

Perhaps that processor can do unaligned accesses? I've never seen a RISC
processor that allowed unaligned accesses, so AIX is probably handling it
with a huge performance penalty.

-- 
 Goran Larsson              Phone: +46 13 299588  FAX: +46 13 299022
 Approve AB                        +46 589 12810       +46 589 16901
 hoh@approve.se
           I was an atheist, until I found out I was God.

In article <1995Dec27.145139.29380@lorelei.approve.se>
           hoh@lorelei.approve.se "Goran Larsson" writes:

>>       - On a DECStation 5500 (ULTRIX 4.4) program run and printed 10 but with
> a
>>         message "Fixed up unaligned data access for pid 25977 (a.out) at pc
> 0x400678".
>
>This is stupid. They are just trying to be kind, but are giving you a
>huge performance penalty.

Actually I quite like the idea of this. It allows you to compile and run
3rd party code that is broken in this respect - it is vastly better to
have something that runs slowly than something that doesn't run at all.
For this to be useful you'd have to have the option to disable the diagnostic
(or just diagnose once per program invocation) or you could be swamped
with them.

On the other hand you have the diagnostics that allow you to track down
and fix these problems in development. It really gives you the best of all
worlds.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

In article <820187762snz@genesis.demon.co.uk>,
Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
> On the other hand you have the diagnostics that allow you to track down
> and fix these problems in development.

I prefer a nice and fat core dump instead of some stupid printout
that just tells the programmer where it happened, not how and why.

-- 
 Goran Larsson              Phone: +46 13 299588  FAX: +46 13 299022
 Approve AB                        +46 589 12810       +46 589 16901
 hoh@approve.se
           I was an atheist, until I found out I was God.

In article <1995Dec29.184746.12327@lorelei.approve.se>
           hoh@lorelei.approve.se "Goran Larsson" writes:

>In article <820187762snz@genesis.demon.co.uk>,
>Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
>> On the other hand you have the diagnostics that allow you to track down
>> and fix these problems in development.
>
>I prefer a nice and fat core dump instead of some stupid printout
>that just tells the programmer where it happened, not how and why.

I would certainly prefer that to be an available option too. 

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------