cudcv@warwick.UUCP (04/27/87)
<munch>
I've just put C++ release 1.2 up on our Gould running UTX 1.2 (BSD Unix
with bits of System V thrown in). This went with barely a hitch, but
during the build the compiler issues hundreds of warnings like
"simpl.c", line 1098: warning: function has a declared type but never
returns a value
It turns out the noddy file
--- c.c ---
void
func()
{
;
}
-----------
produces the intermediate
--- c..c ---
/* <<cfront 1.2.1 2/16/87>> */
/* < c.c */
char *_new(); char _delete(); char *_vec_new(); char _vec_delete();
char func ()
{
;
}
;
/* the end */
------------
which when compiled with 'CC +i -c c.c' produces
---
CC c.c:
cc -c c..c
"c..c", line 10: warning: function has a declared type but never returns a value
---
Now my question. Why does the void get changed into char ? This seems
a very strange choice. I know some compilers aren't very good with
void's, so it might make sense not to leave it as void, but if you're
going to change it surely the obvious choice would be int (as in 1.1,
and about which the Gould compiler doesn't complain). Any offers ?
--
UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037
JANET: cudcv@uk.ac.warwick.daisy ARPA: cudcv@daisy.warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, Englandcmc@rlvd.UUCP (Chris Crampton) (05/11/87)
In article <343@sol.warwick.ac.uk> cudcv@sol.warwick.ac.uk (Rob McMahon) writes: > >Now my question. Why does the void get changed into char ? This seems >a very strange choice. I know some compilers aren't very good with >void's, so it might make sense not to leave it as void, but if you're >going to change it surely the obvious choice would be int (as in 1.1, >and about which the Gould compiler doesn't complain). Any offers ? >-- I for one am glad that Bjarne has made this change as I would have to do it anyway. The problem is that cfront changes all mentions of the type "void" to a different type because, as you say, some compilers have problems with void. It would be OK to use int as the substitute type except for the special overloading of void for pointers (void*). Different machines may require different representations of this type (any pointer should be representable by void*) and char* is likely to be the most general definition in that it will work for byte addressed machines like Vaxen as well as most word addressed machines such as the ones I use. Consider how cfront should translate the following for a compiler with no support for void*: extern void* malloc (); Something like this appears in the source for cfront (or did upto 1.1). I may be treading on religious ground here, but I feel that the Gould C compiler is kicking rather more of a fuss than a C compiler ought... It is easy to change the type to which void is translated, mail me for precise details as I will have to go and look. Chris -- ======================================================================= Chris M Crampton UK JANET: cmc@uk.ac.rl.vd Rutherford Appleton Labs, ARPA: @ucl-cs.arpa:cmc@vd.rl.ac.uk Didcot, OXON, U.K. UUCP: ..!mcvax!ukc!rlvd!cmc +44 235 21900 ext. 6756