Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: pointer cast question
Message-ID: <6449@brl-smoke.ARPA>
Date: Sun, 20-Sep-87 22:11:25 EDT
Article-I.D.: brl-smok.6449
Posted: Sun Sep 20 22:11:25 1987
Date-Received: Mon, 21-Sep-87 04:16:02 EDT
References: <100@teletron.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19
Keywords: pointer  cast  alignment

In article <100@teletron.UUCP> andrew@teletron.UUCP (Andrew Scott) writes:
>...  Thus, it is the programmer's
>responsibility to insure that the pointers involved in such expressions
>point to valid addresses after the cast.
>Why is this the case?  It seems to me that the cast should produce code
>which aligns the pointer to a proper alignment boundary if necessary.

The compiler cannot tell how you intend to eventually use the converted
pointer.  It is exceeding unlikely that automatic rounding of a pointer's
address value (whatever that may mean) to some other alignment would
result in anything useful; if the pointer were not already properly
aligned (as malloc()'s return values are), then "adjusting" its value
would result in a new pointer that no longer pointed to sane data.

Generally, you should not attempt to play tricks with pointer casts
(other than on the result of malloc() and the argument to free())
until you're quite familiar with C.  If you declare types correctly,
such casts are seldom necessary, and they're almost always associated
with non-portable code.  (There are a few exceptions.)