AMD opteron 64

[Dan Pop]

Instead, write it this way:

int *x = malloc (sizeof *x * 128);

Or, more readably:

int *x = malloc(128 * sizeof *x);

which tells to the human reader: I want to allocate space for 128 items
of that size.

Dan

 

[Paul Hsieh]

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 ?

Well, the #include <...> headers that others have posted about will
fix the problem (the compiler thinks that malloc returns a 32bit int
because you didn't include a header file that says otherwise.)

But of course you have an additional problem that you did not define
the value of nka. Which is going to be another serious problem for
you to get the code working.

 

[Lionel Valero]

Sorry,

this code is a peace of code taken from a bigger one, i should have instancied
nka value to make it clearer.

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 ?

Well, the #include <...> headers that others have posted about will
fix the problem (the compiler thinks that malloc returns a 32bit int
because you didn't include a header file that says otherwise.)

But of course you have an additional problem that you did not define
the value of nka. Which is going to be another serious problem for
you to get the code working.

--
-=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=-

 

[E. Robert Tisdale]

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 behavior is indeed undefined.
malloc will return the pointer using the correct procedure.
The compiler will generate code to convert the assumed returned int.
Since malloc did not return an int,
this code will operate on residual data.

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?

 

[Dan Pop]

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 ?

Well, the #include <...> headers that others have posted about will
fix the problem (the compiler thinks that malloc returns a 32bit int
because you didn't include a header file that says otherwise.)

But of course you have an additional problem that you did not define
the value of nka. Which is going to be another serious problem for
you to get the code working.

I don't think that initialising nka is such a serious problem. Most
likely, this is the trimmed down version of his real program and he
trimmed too much.

What I find surprising is that, in this day and age, people still use
old style function definitions. Have they been asleep for the last 15
years or what?

And, while I can easily understand the usage of exit(1) to signal
failure (common convention under Unix and MSDOS), the usage of exit(-1)
keeps baffling me: I have yet to see a single implementation where the
value -1 is passed as such to the entity that launched the execution
of the program in question.

Dan

 

[Dan Pop]

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.

Dan

 

[Keith Thompson]

Which proves once again that C++ is broken, since the cast is useless
and useless casts should be anathema.

<OT>
C++ is a different language than C, and there are valid reasons that
C++ disallows implicit conversions from void* to other pointer types.
These reasons don't apply to C. For details, see elsewhere.
</OT>

 

[E. Robert Tisdale]

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?

 

[Keith Thompson]

Please tell us which machine does this.

One example is gcc on IA-64 Linux, which has 64-bit pointers and
32-bit ints. (It doesn't use a different register, but the size
mismatch causes similar problems.)

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?

I did this some time ago; search the archives.

 

[glen herrmannsfeldt]

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.

-- glen

 

[Chris Torek]

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

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.

 

[Keith Thompson]

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

 

[CBFalconer]

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.

 

[Dik T. Winter]

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

>

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

 

[Grumble]

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]

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

 

[E. Robert Tisdale]

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]

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)(const void *)
(intptr_t)(char **)malloc((size_t)sizeof(struct foo));
if (0 != ((p == (struct foo*)NULL) == (int)1)) {
(void)perror ((const char*)"malloc failed!");
(void)exit ((int)EXIT_FAILURE);
}

 

[E. Robert Tisdale]

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
that the compiler would otherwise have been required to produce!
The O.P.'s mistake in omitting [the declaration of malloc]
went unnoticed exactly as we've all said would happen.

You are confused. No diagnostic was hidden.
You need to reread Lionel Valéro's original post.
The diagnostic message was,
"warning: cast to pointer from integer of different size".
It says nothing about the fact that malloc was not declared.
It certainly doesn't tell you that stdlib.h was not included.
My GNU C compiler

> gcc --version

gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

issues a more informative diagnostic message:

malloc.c:8: warning: implicit declaration of function `malloc'

The solution to this problem is to get a better C compiler
and *not* to cobble your code to accommodate inferior C compilers.

What benefit does *inserting* the cast provide?

It allows you to compile your code with a C++ compiler.
This is important because it allows your C code to survive
even if the C language itself doesn't survive.

 

[Ben Pfaff]

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