Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!acorn!abccam!pete
From: pete@abccam.abcl.co.uk (Peter Cockerell)
Newsgroups: comp.lang.c++
Subject: Compiling _vec_new with an ANSI C compiler
Message-ID: <493@pete.abccam.abcl.co.uk>
Date: 16 Jul 90 14:41:37 GMT
Organization: Active Book Company Limited, Cambridge, UK
Lines: 46

Yo, netLanders!

We've been having a problem porting cfront 1.2.1 on to a system that
uses a strict ANSI C comiler.  It's this: the declarations of the
functions _vec_new() and _vec_delete() are hard-wired into cfront, ie
the symbol table is set-up explicitly (in simpl.c) to behave as if these
declarations have been read:

extern _vec_new(void *, int, int void *f);
extern _vec_delete(void *, int, int, void *f, int);

In both cases, the void *f in the list is actually a pointer to a
fuction (ctor or dtor respectively).  In the code for the functions
themselves in the file _vec.c, there are lines like:

typedef void (*PF)(void *)
...
	for (register int i=0; i<n; i++) ( *PF(f))( PV(p+i*sz) );

ie f is being cast from a void* to a pointer to a function that takes a
void *.  The problem is, our compiler treats a cast (even an explicit
one) from a data type to a function type as a serious error, and just
wouldn't let it pass.  Or indeed parse.  And because the declaration is
hardwired we can't re-declare it in a header with the correct type. 

Eventually we fixed it by changing the code that sets up the symbol
table to give f the right prototype (not a pleasant experience), but my
questions are these: why is f given the type void* instead of the
appropriate (*)()? Why are the declarations for these functions (plus
operators new and delete) hard-wired into the front end like this? Is
this the case in versions 2.X? And is it in fact reasonable that our cc
chucks out so unceremoniously the cast that cfront was trying to do?

Comments please... 

PS We had an earlier problem with cfront emitting extraneous semicolons
after function bodies, eg

void fred()
{
...
};

which our cc also took a very dim view of.  This was quite easy to fix,
to the extent that you wonder why they were generated in the first
place...