[comp.std.c] Casting pointers

tim@maths.tcd.ie (Timothy Murphy) (09/30/90)

I recently came across the following problem,
when temporarily 'borrowing' od from Unix to Mac.
Consider a program like this.

#include <stdio.h>

char *buf = "abc";

main()
{
  int *n = (int*) buf;
  printf("%d", *n);
}

Should this always work?
On the Mac, with THINK C,
it only works if buf has an even address.
Otherwise it bombs out.
Is that a bug, according to standard C?

-- 

Timothy Murphy  

e-mail: tim@maths.tcd.ie

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/01/90)

In article <1990Sep29.201144.23113@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>when temporarily 'borrowing' od from Unix to Mac.

Assuming you're talking about AT&T's proprietary source code,
that is not "borrowing", it's theft.

>char *buf = "abc";
>  int *n = (int*) buf;
>Should this always work?

Of course not.  You may cast pointers to objects with more stringent
alignment requirements to pointers to objects having less stringent
or the same alignment requirements, not the other way around.

henry@zoo.toronto.edu (Henry Spencer) (10/02/90)

In article <1990Sep29.201144.23113@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>char *buf = "abc";
>  int *n = (int*) buf;
>  printf("%d", *n);
>Should this always work?
>On the Mac, with THINK C,
>it only works if buf has an even address. ...
>Is that a bug, according to standard C?

What you are doing is not portable, and your machine is quite entitled to
object to it.  Converting pointer-to-more-aligned-type to pointer-to-less-
aligned type (e.g. `int *' to `char *') is guaranteed to produce a usable
pointer, but not vice-versa.  You are working in the Twilight Zone of
undefined behavior, and all bets are off.
-- 
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry

fillg1@uni-paderborn.de (Michael Illgner) (10/02/90)

in tim@maths.tcd.ie (Timothy Murphy) writes:

>I recently came across the following problem,
>when temporarily 'borrowing' od from Unix to Mac.
>Consider a program like this.

>#include <stdio.h>

>char *buf = "abc";

>main()
>{
>  int *n = (int*) buf;
>  printf("%d", *n);
>}

>Should this always work?
>On the Mac, with THINK C,
>it only works if buf has an even address.
>Otherwise it bombs out.
>Is that a bug, according to standard C?

>-- 

>Timothy Murphy  

>e-mail: tim@maths.tcd.ie

I think it is a problem with the Macs 680X0 processor. Larger objects like
integer number are aligned at even addresses, and if they are accessed at
an odd address, the processor raises an exception.


|-----------------------------------------------------------------------------|
|It`s not dead,          | Michael Illgner          | email to                |
|It justs smells funny ! | Theodorstr. 27           |                         |
|                        | 4790 Paderborn (Germany) | fillg1@uni-paderborn.de |
|Life, Universe and all  | 05251/26488 or 60-2331   |                         |
------------------------------------------------------------------------------|

asylvain@felix.UUCP (Alvin E. Sylvain) (10/05/90)

In article <1990Sep29.201144.23113@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>I recently came across the following problem,
>when temporarily 'borrowing' od from Unix to Mac.
>Consider a program like this.
>
>#include <stdio.h>
>char *buf = "abc";
>main()
>{
>  int *n = (int*) buf;
>  printf("%d", *n);
>}
>
>Should this always work?
>On the Mac, with THINK C,
>it only works if buf has an even address.
>Otherwise it bombs out.
>Is that a bug, according to standard C?

I don't know off-hand what the "right" answer is to this one,
but I personally lump this kind of problem into the following category:

Patient, demonstrating a painful maneuver: "Doc, it hurts when I do dat."

Doctor, repeating same maneuver:  "Don't do dat!"

Put another way, unless you can convince me you have compelling reasons
to cast a character pointer into an integer pointer, then treat it
like a character pointer, "don't do dat!"

Change the "int *n" to "char *n", and let it go at that.
--
=======================Standard Disclaimers Apply=======================
"We're sorry, but the reality you have dialed is no   |            Alvin
longer in service.  Please check the value of pi,     |   "the Chipmunk"
or pray to your local diety for assistance."          |          Sylvain