Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!princeton!allegra!alice!bs
From: bs@alice.UucP (Bjarne Stroustrup)
Newsgroups: net.lang.c++
Subject: DMD problem; really f(void);
Message-ID: <6103@alice.uUCp>
Date: Tue, 23-Sep-86 22:57:40 EDT
Article-I.D.: alice.6103
Posted: Tue Sep 23 22:57:40 1986
Date-Received: Wed, 24-Sep-86 22:21:45 EDT
Organization: Bell Labs, Murray Hill
Lines: 34

> Path: ..!haddock!karl
> 
> 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++.

Thanks. There is.

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

C++ includes the "int (*)(void)" notation. After all, I did invent it. I don't
particularly like it and dropped it as anything but a compatibility fudge after
Doug McIlroy and Dennis Ritchie both condemmed it (that is, the ``f(void)''
notation) as an ``abommination''.

For compatibility, cfront accepts the simplest cases of ``struct s s;''. It
also typically warns against tham and there is no guarantee that this laxness
will remain. ``struct s s;'' is not C++.