🚀 go-pugleaf

gaulke@uiucdcsp.CS.UIUC.EDU (Dave Gaulke) writes:
>I have found a problem with C++ when using it to write code for the DMD.
>The following is part of the output of the preprocessor when including the
>file <blit.h> for a simple program.
>
>typedef int (*ptr_fint)();
>main() { (*((int (*)())((ptr_fint *)0x0071d700)[ 43]))( 1 ); }

The problem is that "int (*)()" in oldC means "pointer to function returning
int" whereas in C++ it means "pointer to function taking no arguments and
returning int".  "typedef int (*ptr_fint)(...);" is the correct declaration
in C++, and presumably there's a macro somewhere in blit.h that uses the
oldC cast "(int (*)())" which should be "(int (*)(...))" in C++.

The other compatibility problem which came up recently was a collision
between a structure tag and a variable (which share one namespace in C++).

Bjarne: is there a CC option that gives you compatibility with oldC in these
two cases?  Also, ANSI C preserves the oldC meaning of "int (*)()" and adds
"int (*)(void)" for functions with no arguments.  Will C++ switch to this
notation?  Does it currently accept this notation?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

In article <66700003@uiucdcsp> gaulke@uiucdcsp.CS.UIUC.EDU writes:
>
>typedef	int (*ptr_fint)();
>main()
>{
>	(*((int (*)())((ptr_fint *)0x0071d700)[ 43]))( 1 );
>}
>
>I don't understand what the above jumble is, but it compiles fine using cc.
>CC, however, gives the following error message:
>
>line 4: error: un expected 1 argument for ?

You should have analyzed the jumble a bit more before complaining about
it, as it really does contain an error for CC.  The statement means the
following in C:
	1. take the constant 0x0071d700
	2. cast it to pointer to ptr_fint
	3. considering it as pointing to an array, take element 43 (of
	  type ptrf_fint)
	4. now cast it to pointer to function returning pointer to int
	5. finally call the function pointed to with an argument of 1.

The same error is emitted by CC for a more conventional fragment like this:

	extern int f();
	main() { f(1); }

	"x.c", line 2: error: un expected 1 argument for f()

The error is simply that f() is declared as a function with no argument,
but called as a function with one argument.  This is an error in C++,
but not in C.  Unfortunately C++ has chosen a different solution to cope
with this incompatibility than [proposed] ANSI C; in ANSI C, f() means
that f's arguments are unknown, and one writes f(void) to state
explicitly that f has no arguments.  In your case, the meaning of the
C code changes in C++: line 4 casts to pointer to function with no
arguments and returning pointer to int.

Your error message looks a bit strange because the function name is
unknown.  Another plea for less cryptic error messages in compilers is
in order.
-- 
	Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>