Re: AMD opteron 64

From: Keith Thompson (kst-u_at_mib.org)
Date: 12/02/03 

Date: Tue, 02 Dec 2003 22:01:24 GMT

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> E. Robert Tisdale wrote:
> > Barry Schwarz wrote:
> >> On a machine where the method of returning a pointer
> >> differs from the method of returning an int
> >> (such as using a different register),
> > Please tell us which machine does this.
>
> Any machine where sizeof(int) is different than sizeof(char*) will do.
>
> Though this is more OS or function calling convention dependent than
> machine dependent.

Note that this (calling malloc() with no prototype) may happen to work
on some systems even if sizeof(int) > sizeof(void*). For example, if
int is 32 bits, void* is 64 bits, the value returned by malloc happens
to have the 32 high-order bits all zero, the machine is little-endian
(I think), and a few other unstated assumptions hold, you could
accidentally extract a valid 64-bit pointer from what the compiler
thinks is a 32-bit int result.

This is, of course, deep in the realm of undefined behavior. "Happens
to work" is actually a bad thing, because it can make it more
difficult to detect bugs. (Hey, maybe we should start referring to
this kind of thing as "HTW". 8-)}) 

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Relevant Pages

  • Re: malloc trouble
    ... > someone could look over my updated/modified code to make sure that it ... int main{/* here we don't use command line arguments, ... * exactly the same as calling malloc). ... * you lose the original buffer if realloc fails. ...
    (comp.lang.c)
  • Re: AMD opteron 64
    ... >> On a machine where the method of returning a pointer ... >> differs from the method of returning an int ... Though this is more OS or function calling convention dependent than ...
    (comp.lang.c)