🚀 go-pugleaf

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
-----------------------------------------