AMD opteron 64

[Lionel Valero]

Hello,

I have a test program that is compiled fine on a 32 bits redhat linux using gcc :
*************** ********
main (argc, argv)
int argc;
char *argv[];
{
int *ka;
int nka;

/* allocation dynamique entiere */
ka = (int *) malloc(nka * sizeof(int));
if (!ka) {
printf ("<ERROR> : Out of heap space (malloc) !\n");
printf ("<ERROR> : %d int words required\n", nka);
exit (-1);
}
}
*************** ********

But under linux suse AMD opteron 64, i get this message from the compiler :

warning: cast to pointer from integer of different size

Any explanation ?

Regards,
Lionel.
--
-=O=------------------------------------------=O=-
Lionel Valéro
Analyste Informatique Département Génie Chimique
École Polytechnique de Montréal
C.P. 6079, succ. centre-ville
Montréal (Québec) H3C 3A7
Tel: (514) 340 - 4711 # 4805 / C552
Fax: (514) 340 - 4159
-=O=------------------------------------------=O=-

[Keith Thompson]

glen herrmannsfeldt <ga*@ugcs.calte ch.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_Keit h) ks***@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)

[Chris Torek]

[On mis-declaring malloc() and having code fail, in answer to
"where might this happen"]

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

E. Robert Tisdale wrote:

Please tell us which machine does this.

In article <nh7zb.6213$_M. 26715@attbi_s54 >,
glen herrmannsfeldt <ga*@ugcs.calte ch.edu> wrote: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.

Typically the function-call conventions mirror some properties of
the machine, though. Another example where it fails is some old
(Amiga, perhaps?) 680x0-based compilers, where pointer values are
returned in register A0 while integer values are returned in D0.

Amusingly enough, this entire thread resulted from using a machine
on which this occurred. The subject line -- "AMD opteron 64" --
names a machine that "does this", i.e., returns an int in a
different (sub)register than it returns pointers. This particular
AMD is being used in 64-bit mode, so that its "int"s are 32 bits
while its pointers are 64 bits.

The original poster failed to #include <stdlib.h>, then wrote a
call to malloc() that included a cast, and as a consequence, his
code compiled without diagnostics on one machine (32-bit x86) but
with a diagnostic on another (AMD in 64-bit mode). His question
was about the diagnostic. Had the O.P. avoided the cast -- as is
the usual comp.lang.c recommendation -- he would have gotten
diagnostics on both machines. Whether this would have led him to
the correct fix -- "#include <stdlib.h>" -- is not obvious, but it
would at least have elimininated one puzzling difference.

Although I do not have hard numbers, it is clear to me that,
statistically, many more people run into trouble by casting the
return value of malloc() than by not doing so. Casting malloc()
is a bit like smoking cigarettes: many will do so without ever
dying of lung cancer, but it is still a bad habit and a poor choice
of action.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

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

Inasmuch as we try to write strictly portable code here, let us
conjugate some verbs:

I don't care We don't care
You don't care You (-all) don't care
He doesn't care They don't care
I am a Troll We are Trolls
You are a Troll You (-all) are Trolls
Trollsdale is a Troll Most Trollsdales are Trolls.

If you don't live in the southern US elide (-all). However,
looked on dispassionately , it serves a useful grammatical function
:-). I fail to find an equivalent use for ERT.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Dik T. Winter]

In article <bq**********@e lf.torek.net> Chris Torek <no****@torek.n et> writes:

[On mis-declaring malloc() and having code fail, in answer to
"where might this happen"]

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

E. Robert Tisdale wrote:

Please tell us which machine does this.

.... Typically the function-call conventions mirror some properties of
the machine, though. Another example where it fails is some old
(Amiga, perhaps?) 680x0-based compilers, where pointer values are
returned in register A0 while integer values are returned in D0.

It was for certain on a Mac. Pointers in A0, integers in D0.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Grumble]

E. Robert Tisdale wrote:

Dan Pop wrote:

E. Robert Tisdale writes:

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.

The x86 in certain memory models
where an int is 16 bits and a pointer is 32 bits.

Could you please code up an example
and run it on the machine that you reference above
so that we can see how it fails?

How lazy can you get?

[Dan Pop]

In <3F************ @jpl.nasa.gov> "E. Robert Tisdale" <E.************ **@jpl.nasa.gov > writes:

Dan Pop wrote:

E. Robert Tisdale writes:

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.

The x86 in certain memory models
where an int is 16 bits and a pointer is 32 bits.

Could you please code up an example
and run it on the machine that you reference above
so that we can see how it fails?

Yes, I can, but it shouldn't be necessary: only an idiot couldn't
figure out how it fails.

H:\>type good.c
#include <stdio.h>
#include <stdlib.h>

int main()
{
char *p = malloc(10);
printf("%p\n", (void *)p);
return 0;
}

H:\>tcc -mh good.c
Turbo C++ Version 1.01 Copyright (c) 1990 Borland International
good.c:
Turbo Link Version 3.01 Copyright (c) 1987, 1990 Borland International

Available memory 410832

H:\>good
0856:0004

H:\>type bad.c
#include <stdio.h>

int main()
{
char *p = (char *)malloc(10);
printf("%p\n", (void *)p);
return 0;
}

H:\>tcc -mh bad.c
Turbo C++ Version 1.01 Copyright (c) 1990 Borland International
bad.c:
Turbo Link Version 3.01 Copyright (c) 1987, 1990 Borland International

Available memory 418000

H:\>bad
0000:0004

The address printed by the bad program is right into the interrupt
vector area of the processor, therefore it is clearly not the address
returned by malloc. If the bad program actually attempted to write
something into it, the whole system would get screwed.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[E. Robert Tisdale]

Dan Pop wrote:

E. Robert Tisdale writes:

Dan Pop wrote:

E. Robert Tisdale writes:

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.

The x86 in certain memory models
where an int is 16 bits and a pointer is 32 bits.

Could you please code up an example
and run it on the machine that you reference above
so that we can see how it fails?

Yes, I can, but it shouldn't be necessary: only an idiot couldn't
figure out how it fails.

H:\>type good.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
char *p = malloc(10);
printf("%p\n", (void *)p);
return 0;
}

H:\>tcc -mh good.c
Turbo C++ Version 1.01 Copyright (c) 1990 Borland International
good.c:
Turbo Link Version 3.01 Copyright (c) 1987, 1990 Borland International

Available memory 410832

H:\>good
0856:0004

H:\>type bad.c
#include <stdio.h>

int main(int argc, char* argv[]) {
char *p = (char *)malloc(10);
printf("%p\n", (void *)p);
return 0;
}

H:\>tcc -mh bad.c
Turbo C++ Version 1.01 Copyright (c) 1990 Borland International
bad.c:
Turbo Link Version 3.01 Copyright (c) 1987, 1990 Borland International

Available memory 418000

H:\>bad
0000:0004

The address printed by the bad program
is right into the interrupt vector area of the processor,
therefore it is clearly not the address returned by malloc.
If the bad program actually attempted to write something into it,
the whole system would get screwed.

Thanks Dan. I knew you could do it.

The only problem is that your example is for a C++ compiler (Turbo C++)
which is obsolete, which never fully complied
with the ANSI/ISO C89 standard much less the ANSI/ISO C99 standard
and which was designed to emit code for Intel 80286 processors.
There are almost no C programmers who actually consider it
a viable target for their applications -- nobody cares.

The point is that

1. a good C compiler will warn the programmer
if malloc has not been declared properly and
2. the code will probably execute properly
even if malloc has not been declared properly.

Omitting the type cast for the result returned by malloc
does *nothing* for the programmer except to produce
a cryptic and, possibly, misleading diagnostic
when malloc has not been declared properly.

[Eric Sosman]

"E. Robert Tisdale" wrote:

Thanks Dan. I knew you could do it.

The only problem is that your example is for a C++ compiler (Turbo C++)
which is obsolete, which never fully complied
with the ANSI/ISO C89 standard much less the ANSI/ISO C99 standard
and which was designed to emit code for Intel 80286 processors.
There are almost no C programmers who actually consider it
a viable target for their applications -- nobody cares.
Awfully critical of work someone else did at your
request and without reward ...
The point is that

1. a good C compiler will warn the programmer
if malloc has not been declared properly and
True. In fact, a C99-conforming compiler *must*
complain if malloc() or any other function is used
without a prior declaration.
2. the code will probably execute properly
even if malloc has not been declared properly.
False, as Dan's example demonstrated. False, false,
false. What part of "false" are you having trouble with?
Omitting the type cast for the result returned by malloc
does *nothing* for the programmer except to produce
a cryptic and, possibly, misleading diagnostic
when malloc has not been declared properly.

A cryptic and possibly misleading diagnostic is more
helpful than no diagnostic at all. In fact, this entire
thread stems from an incident in which the unnecessary
cast hid the diagnostic the compiler would otherwise
have been required to produce! The O.P.'s mistake in
omitting <stdlib.h> went unnoticed, exactly as we've all
said would happen.

So omitting the cast is demonstrably helpful, with
this thread as the demonstration. What benefit does
*inserting* the unnecessary cast provide? None! None,
none, none. What part of "none" are you having trouble
with?

Y'know, if one cast is good, perhaps more would be
even better:

struct foo *p = (struct foo *)(uintptr_t)(c onst void *)
(intptr_t)(char **)malloc((size _t)sizeof(struc t foo));
if (0 != ((p == (struct foo*)NULL) == (int)1)) {
(void)perror ((const char*)"malloc failed!");
(void)exit ((int)EXIT_FAIL URE);
}

--
Er*********@sun .com

[Keith Thompson]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > writes:
[snip]

Thanks Dan. I knew you could do it.

The only problem is that your example is for a C++ compiler (Turbo C++)
which is obsolete, which never fully complied
with the ANSI/ISO C89 standard much less the ANSI/ISO C99 standard
and which was designed to emit code for Intel 80286 processors.
There are almost no C programmers who actually consider it
a viable target for their applications -- nobody cares.

As I mentioned in this thread, I posted an example myself (for gcc
under IA-64 Linux) some time ago. Since you seem disinclined to
search for it yourself, here's the Google Groups URL:

http://groups.google.com/gr*********...***@cts.com%3E

I posted it about 6 weeks ago in the "why still use C?" thread. You
may have missed it the first time around; I see that you didn't
participate in the thread after that.

And of course the article that started this thread was yet another
perfectly valid example of the problem you keep telling us nobody
cares about.

--
Keith Thompson (The_Other_Keit h) ks***@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)

[Ben Pfaff]

Eric Sosman <Er*********@su n.com> writes:

"E. Robert Tisdale" wrote:

2. the code will probably execute properly
even if malloc has not been declared properly.

False, as Dan's example demonstrated. False, false,
false. What part of "false" are you having trouble with?

Why are you arguing with a troll? This is ERT's modus operandi:
he makes an incorrect statement and when people show that he is
wrong, he denies their evidence. Don't bothe
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}