sking@nowhere.uucp (steven king) (08/19/90)
I have two implementations of cfront 2.0, Guidelines (for dos) and Intek
(unix); both provide an "a+" option to generate "ansi c" output as opposed to
the default K&R; so I assume its part of the AT&T product. However, when
presented with a class ala
class foo {
public:
foo();
~foo();
};
what is emitted for the destructor is a proto of the form
void __dt__3fooFv(struct foo *__0this, int );
^^^^?
the only "ansi c" compiler I have available to me (Microsoft C 6.0) chokes on
this. Which has the bug, the cfront(s) or MSC?
(The ansi mode is importantant to me because MSC wont convert functions like
memcpy, etc., into their intrinsic form with a K&R style proto)
thanxs,
--
NONE of the standard disclaimers apply
===============================================================================
UUCP: ...!cs.utexas.edu!ut-emx!nowhere!skingsking@nowhere.uucp (steven king) (08/20/90)
in my earlier post about MSC choking on the output of cfront
(Guidelines || Intek) using the +a (ansi c) switch, I think I wasnt clear
about what MSC didnt like; protos generated by cfront of the form
void __dt__3fooFv(struct foo * __0this, int );
cause MSC to complain "syntax error : ')' " for the line in question;
appearently it expecting a tag for the second arguement. Editing the output
of cfront to produce
void __dt__3fooFv(struct foo * __0this, int free);
and MSC compiles it without a complaint. Note that if the body of the function
is defined, cfront produces output acceptable to MSC, ie:
class foo {
public:
foo();
~foo();
};
foo::~foo()
{
}
results in
void __dt__3fooFv (
struct foo *__0this ,
int __0__free )
{ if (__0this )
if (__0this )if (__0__free & 1)__dl__FPv ( (void *)__0this ) ;
}
so the question remains, to whom do I complain to? Intek and Guidelines (AT&T)
or Microsoft?
--oh the version of cfront used is 2.0 and the version of MSC is 6.0
(I applogise for wasting so much bandwidth on for what to most must seem a
trivial matter)
--
NONE of the standard disclaimers apply
===============================================================================
UUCP: ...!cs.utexas.edu!ut-emx!nowhere!skinggregk@cbnewsm.att.com (gregory.p.kochanski) (08/20/90)
In article <9008191857.13779@nowhere.uucp> sking@nowhere.uucp (steven king) writes: > >in my earlier post about MSC choking on the output of cfront >(Guidelines || Intek) using the +a (ansi c) switch, I think I wasnt clear >about what MSC didnt like; protos generated by cfront of the form > > void __dt__3fooFv(struct foo * __0this, int ); > >cause MSC to complain "syntax error : ')' " for the line in question; >appearently it expecting a tag for the second arguement. Editing the output >of cfront to produce > > void __dt__3fooFv(struct foo * __0this, int free); > >and MSC compiles it without a complaint. I found this a while back. It is a bug in Microsoft C, as ANSI standards specify both of the above prototypes to be allowable. I am told there is a simple change to make to cfront which suppresses all variable names in prototypes, but unless you have the source code, you're out of luck. Greg Kochanski gpk@physics.att.com AT&T Physics Research -- Physics for fun and profit.
shankar@hpclscu.HP.COM (Shankar Unni) (08/21/90)
> class foo { > public: > foo(); > ~foo(); > }; > > what is emitted for the destructor is a proto of the form > void __dt__3fooFv(struct foo *__0this, int ); > the only "ansi c" compiler I have available to me (Microsoft C 6.0) chokes on > this. Which has the bug, the cfront(s) or MSC? Actually, both. MSC is the more glaring violator, because the ANSI C standard explicitly allows you to leave out parameter names on any of the parameters (i.e. parameter names for external function declarations are totally optional, and there is no requirement for them to be all present or all absent). Cfront is also a contributor to this fiasco: it should not be putting out parameter names for external declarations. In fact, one of the more serious bugs in cfront 2.0 is that sometimes these name nodes get reclaimed and re-used, and then when it finally gets around to dropping the prototype, one gets interesting declarations like: void __dt__3fooFv(struct foo *__03.14159, int ); ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
rfg@NCD.COM (Ron Guilmette) (08/21/90)
In article <9008191857.13779@nowhere.uucp> sking@nowhere.uucp (steven king) writes:
<
<in my earlier post about MSC choking on the output of cfront
<(Guidelines || Intek) using the +a (ansi c) switch, I think I wasnt clear
<about what MSC didnt like; protos generated by cfront of the form
<
< void __dt__3fooFv(struct foo * __0this, int );
<
<cause MSC to complain "syntax error : ')' " for the line in question;
<appearently it expecting a tag for the second arguement. Editing the output
<of cfront to produce
<
< void __dt__3fooFv(struct foo * __0this, int free);
<
<and MSC compiles it without a complaint.
...
<so the question remains, to whom do I complain to? Intek and Guidelines (AT&T)
<or Microsoft?
Looking at the syntax given in section 3.5.4 of the Dec. 7 1988 draft ANSI
C standard, it appears clear that each parameter declaration in a
parameter declaration list may include either an actual declarator
or an (optional) abstract declarator (i.e. nothing).
For some strange reason, I though at first that I recalled some ANSI C
rule that said that if, in your function prototype, one or more parameter
declarations included explicit names for the parameters, then all of them
had to. Looking at the (draft) standard however, I can find no such rule,
so I must have been wrong. Section 3.5.4.3 certainly lists no such
constraint.
ADDITIONAL EVIDENCE: GCC accepts either of the declarations above.
CONCLUSION: Complain to Microsoft.
Note however that people inside AT&T have occasionally been known to
frequent these parts, and perhaps they will notice the trouble you've
gotten into. With luck, they will also solve this problem on their
end, since there is no particularly good reason for cfront to be
putting out *any* parameter names in <forward> function declarations.
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg
// Motto: If it sticks, force it. If it breaks, it needed replacing anyway.jimad@microsoft.UUCP (Jim ADCOCK) (08/24/90)
In article <58170030@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: |> void __dt__3fooFv(struct foo *__0this, int ); |> the only "ansi c" compiler I have available to me (Microsoft C 6.0) chokes on |> this. Which has the bug, the cfront(s) or MSC? | |Actually, both. | |MSC is the more glaring violator, because the ANSI C standard explicitly |allows you to leave out parameter names on any of the parameters (i.e. |parameter names for external function declarations are totally optional, |and there is no requirement for them to be all present or all absent). The MSC people are aware of this difference from the ANSI spec, and it will be corrected by release 7.0 -- if not earlier. I will update this info if I can find out more exact details.
sking@nowhere.uucp (steven king) (08/26/90)
Just like to say thanks to everyone that responded. Fortunately I was able to work around the problem by reordering my source and only using the +a1 option on those modules that >really< required it. -- UUCP: ...!cs.utexas.edu!ut-emx!nowhere!sking