AMD opteron 64

[Keith Thompson]

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/groups?&as_umsgid=<[email protected]>

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.

 

[E. Robert Tisdale]

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/groups?&as_umsgid=<[email protected]>

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.

I just happen to have access to an IA-64 Linux machine:

> expand main.c

#include <stdio.h>

int main(int argc, char* argv[]) {

printf("sizeof(int) = %d\n", (int)sizeof(int));
printf("sizeof(void*) = %d\n", (int)sizeof(void*));

int* p = (int*)malloc(sizeof(int));
printf("p = [%p]\n", (void*)p);
fflush(stdout);

*p = 42;
printf("*p = %d\n", *p);

return 0;
}

> ecc -Wall -std=c99 -o main main.c

main.c(8): warning #266: function declared implicitly
int* p = (int*)malloc(sizeof(int));
^

main.c(8): remark #967: conversion from "int" to "int *";
sizes do not match
int* p = (int*)malloc(sizeof(int));
^

A good C compiler will warn you about this problem
whether or not you use a cast.

 

[Eric Sosman]

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

No, the confusion is elsewhere. The O.P. asked why his
program compiled without complaint in one environment and
elicited a diagnostic on another. Without the cast, the
program would have produced diagnostics on *all* C compilers.
Thus, the cast hid the required diagnostic, and it was pure
luck that an "optional" or "extraneous" diagnostic from another
compiler drew his attention to the error.

It says nothing about the fact that malloc was not declared.
It certainly doesn't tell you that stdlib.h was not included.

Nor does it tell you how to feed the hungry, heal the sick,
and end war. And when the diagnostic is suppressed altogether,
as in the O.P.'s original environment, it doesn't even tell
you to come in out of the rain.

But if the diagnostic had been permitted to appear, it
would at least have alerted the O.P. to the existence of a
problem. The description of the problem might not have been
all that could be desired, but knowing that a problem exists
is at least half the battle in finding the cure.

My GNU C compiler

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'

That's nice. Seriously, it *is* nice. So what?

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

The "inferior compilers" in the O.P.'s case were (ahem)
gcc and gcc. And I fail to see how leaving out an unnecessary
and potentially harmful cast constitutes "cobbling" the code.

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.

I once saw a cute little "Hello, world!" program that
ran correctly in three different languages: C, Fortran, and sh,
if I recall aright. It was an amusing stunt, but hardly a useful
way to write programs ...

I put it to you that writing programs that are somehow
simultaneously both C and C++ is an exercise of similar
[f]utility. Yes, it's possible to write such code, if one
is willing to wear a tight enough strait jacket. But the
result will be derided by both camps: Neither the C people
nor the C++ people will deem it good code. In the particular
case of malloc(), the C++ folks will say it's poor practice
to use it in the first place; the `new' operator needs no
cast. If you want to write C++ go right ahead and do so --
but don't pretend that writing bad C code so it can masquerade
as bad C++ code is a good idea.

Personally, I use `new' as an identifier whenever I can
find a reasonable excuse to do so.

 

[Eric Sosman]

Why are you arguing with a troll?

Because he writes with an authoritative manner, and people
might therefore believe he's an authority. I have observed
that he oscillates between nonsense on some threads and good
advice on others; the latter tends to build credibility for
the former. (And makes it not entirely proper to dismiss
him as purely a troll; sometimes he *does* make sense.)

Somebody's got to contradict him when he spouts foolishness.
I'm not volunteering to be Permanent Latrine Orderly, so it's
kind of a coin-toss whether I'll join in on a thread or just
leave his flagellation to others -- there never seems to be a
shortage of people willing to point out misteaks, and in the
case of ERT I think that's a good thing.

I just wish I knew whether he does it out of forgivable
ignorance or out of malice.

 

[Richard Heathfield]

If you want to write C++ go right ahead and do so --
but don't pretend that writing bad C code so it can masquerade
as bad C++ code is a good idea.
Amen...

Personally, I use `new' as an identifier whenever I can
find a reasonable excuse to do so.

Yes, and this is not through anti-C++ bloodymindedness. All right - it's not
/just/ through anti-C++ bloodymindedness. There's a much more important
reason, too: it's a heads-up to anyone compiling the code with a C++
compiler; a message from the original author. When translated, the message
reads "I wrote this in C. I have assumed C rules throughout. C++ is
different from C. Proof: the diagnostic you are now reading! So either
rewrite this from the ground up in C++, or leave it alone".

Not bad for three letters.

 

[E. Robert Tisdale]

Eric Sosman wrote:

The "inferior compilers" in the O.P.'s case
were (ahem) gcc and gcc.

No. Lionel Valéro simply forgot to use
the appropriate options (-Wall, etc.)

I put it to you that writing programs that are somehow
simultaneously both C and C++ is an exercise of [f]utility.
Yes, it's possible to write such code
if one is willing to wear a tight enough strait jacket.
But the result will be derided by both camps:
Neither the C people nor the C++ people will deem it good code.
In the particular case of malloc(), the C++ folks will say
it's poor practice to use it in the first place;
the `new' operator needs no cast.
If you want to write C++ go right ahead and do so --
but don't pretend that writing bad C code
so it can masquerade as bad C++ code is a good idea.

If I find a great open source function library implemented in C,
a I obliged to re-implement in C++ so that "C++ folks"
will "deem it good code"? I don't think so.
I just compile it with my C++ compiler
and link it into my C++ programs.

Personally, I use `new' as an identifier
whenever I can find a reasonable excuse to do so.

Just to frustrate C++ programmers?
Is your code really more valuable
if C++ programmers can't use it?
Does your employer/client know that you do this?

 

[Richard Heathfield]

If I find a great open source function library implemented in C,
a I obliged to re-implement in C++ so that "C++ folks"
will "deem it good code"? I don't think so.

Right. You can just link it in, and everyone's happy.

I just compile it with my C++ compiler
and link it into my C++ programs.
Right.


Just to frustrate C++ programmers?

No, not just for that. Partly to warn them "this is C code - compile as C,
then link".

Is your code really more valuable
if C++ programmers can't use it?

But they can, as you yourself just pointed out!

Does your employer/client know that you do this?

I'm sure Eric Sosman's employer knows perfectly well that Eric is a
programmer to be trusted.

 

[NFish]

You forgot to include stdlib.h again



And this cast hides the error that you forgot to include the header in
redhat linux.
Casting the result from a function that returns void* is always an
error.

Well, I wouldn't go that far. Consider replacing the first occurrence
of 'a' with 'A" in a block of 100 bytes, given that it exists.

*(char*)memchr(buffer, 'a', sizeof buffer) = 'A';

seems like a reasonable solution.

 

[Dan Pop]

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.

Wrong. The code is for a C compiler that does conform with the
ANSI/ISO C89 standard. The lack of a diagnostic for good.c is the
ultimate proof that the compiler was used as a C compiler and not as a
C++ compiler.

Nothing in your initial request outruled Intel 80286 processors, or
conforming C89 implementations, therefore my example is an adequate
response to your request.

Dan

 

[CBFalconer]

E. Robert Tisdale wrote:
.... snip ...


I'm sure Eric Sosman's employer knows perfectly well that Eric
is a programmer to be trusted.

A more germane question is "Does ERTs employer know what he does
here?". If his job is pushing a broom it probably doesn't matter.

 

[Grumble]

there never seems to be a shortage of people willing to point out
misteaks

I want mine rare, thanks!

 

[Keith Thompson]

If I find a great open source function library implemented in C,
a I obliged to re-implement in C++ so that "C++ folks"
will "deem it good code"? I don't think so.
I just compile it with my C++ compiler
and link it into my C++ programs.

Why not compile it with your C compiler and use extern "C"?

 

[The Real OS/2 Guy]

Well, I wouldn't go that far. Consider replacing the first occurrence
of 'a' with 'A" in a block of 100 bytes, given that it exists.

*(char*)memchr(buffer, 'a', sizeof buffer) = 'A';

seems like a reasonable solution.

You'll get 2 problems here:
1. you forgot to include string.h. results in a faulty conversion of
int to char*
as you supperess the diagnostic the compiler will give you.
2. memchr() may return NULL - results in dereferencing a NULL pointer.

Again: never cast the result of a function that returns pointer to
void because the only you get is a faulty program.

 

[E. Robert Tisdale]

E. Robert Tisdale writes:
[...]

If I find a great open source function library implemented in C,
a I obliged to re-implement in C++ so that "C++ folks"
will "deem it good code"? I don't think so.
I just compile it with my C++ compiler
and link it into my C++ programs.

Why not compile it with your C compiler and use extern "C"?

extern "C" only *helps* with linkage.
There is no guarantee, for example, that both the C and C++ compiler
will use the same representation for int.
There is no guarantee that both compilers will pass (or return)
arguments in the same registers or on the stack in the same order.
The only reliable way to link C library functions into C++ programs
is to compile them both with the same C++ compiler.

 

[Randy Howard]

extern "C" only *helps* with linkage.
There is no guarantee, for example, that both the C and C++ compiler
will use the same representation for int.

Which platform(s) have C and C++ compilers where this does not work.
Please give a specific example, with example code to show the failure.