🚀 go-pugleaf

In article <4l33mf$7pr@solutions.solon.com> msz@sirius.astrouw.edu.pl
(Michal Szymanski) writes:

|> There is a discussion of (void *) and pointer casting going on this list.
|> K&R "Ansi C" book says that conversion: (type *) -> (void *) -> (type *)
|> is guaranteed to yield the same pointer. This (and the discussion on the
|> list) suggests that another chain: (void *) -> (type *) -> (void *)
|> might result in some change of the original pointer. In other words
|> I would guess that casting a void pointer to a pointer to a type requiring
|> special memory allignment might involve adjusting it to a proper value.
|> Is this true? I played with such conversions on Sun Sparcstation
|> (which surely requires proper allignment of data with sizeof > 1),
|> using both Sun compiler v. 2.0.1 and Gnu 2.6.3, but never observed
|> such an automatic adjustment? Odd pointers casted to (e.g.) double
|> result in Bus Error when referenced. And they show the same odd value
|> when printed as long values.

|> So I wonder whether this adjustment is just (nowhere-implemented) possibility 
|> or some real thing?

The adjustment is certainly legal, although I don't know of an
implementation that does it.  More of a problem occurs, however, on
implementations where `type*' contains less bits than `void*'.
Obviously, in such cases, some information will be lost.  (Typically,
this will `look like' the compiler has adjusted the pointer downward.
In fact, it is just a case of throwing away the bits it doesn't have
room for.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung

In article <4l33mf$7pr@solutions.solon.com> msz@sirius.astrouw.edu.pl (Michal Szymanski) writes:
] There is a discussion of (void *) and pointer casting going on this list.
] K&R "Ansi C" book says that conversion: (type *) -> (void *) -> (type *)
] is guaranteed to yield the same pointer. This (and the discussion on the
] list) suggests that another chain: (void *) -> (type *) -> (void *)
] might result in some change of the original pointer. In other words
] I would guess that casting a void pointer to a pointer to a type requiring
] special memory allignment might involve adjusting it to a proper value.
] Is this true?

    An implementation is free to modify pointers to obey alignment
restrictions: on a Sun, your compiler _could_ round an odd pointer off
to the nearest alignment.  No compilers I know of actually do, though:
crashing is sometimes a more obvious complaint than just accessing the
wrong section of memory,...

    However, I _do_ know of at least one machine where the pointer can
get modified--not because of different alignments, but because of
different binary representations for pointers.  The compiler can and
does lose bits off a pointer if you cast to a pointer type with the
wrong binary representation (i.e., from (void *) or (char *) to anything
else).

    (And, no, I'm not going to say which--I want you to stay paranoid,
producing portable code.)

                                           -- Bill K.

Bill Kaufman               | "I grow old, I grow old, I shall wear the bottom
wkaufman@us.oracle.com     |  of my trousers rolled,..."
                           |     -- the Mole-Man, "Incredible Hulk" annual

In article <4l33mf$7pr@solutions.solon.com>, msz@sirius.astrouw.edu.pl (Michal Szymanski) writes:
|> There is a discussion of (void *) and pointer casting going on this list.
|> K&R "Ansi C" book says that conversion: (type *) -> (void *) -> (type *)
|> is guaranteed to yield the same pointer. This (and the discussion on the
|> list) suggests that another chain: (void *) -> (type *) -> (void *)
|> might result in some change of the original pointer. In other words
|> I would guess that casting a void pointer to a pointer to a type requiring
|> special memory allignment might involve adjusting it to a proper value.
|> Is this true? I played with such conversions on Sun Sparcstation
|> (which surely requires proper allignment of data with sizeof > 1),
|> using both Sun compiler v. 2.0.1 and Gnu 2.6.3, but never observed
|> such an automatic adjustment? Odd pointers casted to (e.g.) double
|> result in Bus Error when referenced. And they show the same odd value
|> when printed as long values.
As far as I know, this problem is more academic. It is allowed for an
operating system, to store pointers differently (according to their type).
So a (char *) might use 35bits, wheres (double *) uses only 30 bits. If
this is the case, a cast from (char *) to (double *) and back to (char *)
(through a void pointer or not) strips 5 bits. 
I've never seen an operating system, which does use different pointers
for different objects, thats why normaly typecasting is just a runtime
problem when derefferencing the pointer. (See your core dump).
|> 
|> So I wonder whether this adjustment is just (nowhere-implemented) possibility 
|> or some real thing?

Joachim
-- 
---------------------------------------------------------------------
Joachim Huober                                Phone: +49 731 502-6241
UDINE-Project,            URZ, University of Ulm, 89081 Ulm , Germany
E-mail: joachim.huober@rz.uni-ulm.de 
---------------------------------------------------------------------

Michal Szymanski <msz@sirius.astrouw.edu.pl> wrote:
>So I wonder whether this adjustment is just (nowhere-implemented) possibility 
>or some real thing?

I believe the allowed adjustment is not actually implemented as such
anywhere.  It would be a waste of time to do so, as one can't portably
rely on it.  But there are systems where pointers to words take up
fewer bits than pointers to bytes, and in such a case the hardware will
either do the truncation for you, or complain at the conversion.

Are conversions of pointers without the proper alignment actually
illegal, i.e. invoking undefined behaviour?  It seems to me that an
implementation where conversion of an unaligned byte pointer to a word
pointer will trap ought to be conforming.

-zefram

In <4lbao2$lkd@solutions.solon.com> Network News <news@dcs.warwick.ac.uk> writes:

>Are conversions of pointers without the proper alignment actually
>illegal, i.e. invoking undefined behaviour?

All arbitrary pointer conversions are illegal, unless the standard 
explicitly states otherwise.  The result of such a conversion is
undefined behaviour, indeed.

>It seems to me that an
>implementation where conversion of an unaligned byte pointer to a word
>pointer will trap ought to be conforming.

On most real world platforms, the trap occurs when the resulting pointer
is dereferenced.  But an implementation where the trap occurs at 
conversion time would be conforming (when it comes to undefined behaviour,
any behaviour is conforming).

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland