Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!josw
From: josw@mcvax.uucp (Jos Warmer)
Newsgroups: net.lang.c++
Subject: porting C++ to SUN3
Message-ID: <7021@boring.mcvax.UUCP>
Date: Fri, 25-Jul-86 07:36:07 EDT
Article-I.D.: boring.7021
Posted: Fri Jul 25 07:36:07 1986
Date-Received: Fri, 25-Jul-86 21:56:26 EDT
Organization: CWI, Amsterdam
Lines: 109
Apparently-To: rnews@mcvax


I have just managed to make a port to SUN3 
(SUN 3/75, running Sun UNIX 4.2 release 3.0).
Thanks for all the suggestions about how to port C++, they were very
helpfull and I couldn't have done without them.
There are however some special fixes needed for the SUN3, which
I have not seen before on the net, so I will summarize them:

---------------------------------------------------------------------
strlen:
On a VAX strlen can handle nil-argument and delivers the value 0.
On the SUN strlen can't handle a nil-argument and a segmentation violation
occurs. To fix this change every call to strlen into a call to sun_strlen.
Add the next line as the first line to cfront.h:

	#define   strlen(string)   sun_strlen(string)

and add a new procedure sun_strlen at the end of main.c:

	#undef strlen
	int sun_strlen(char* s)
	{
	    if( s == 0 ) {
		return 0;
	    } else {
		return strlen(s);
	    }
	}

The #undef is needed to stop sun_strlen from calling itself recursively.

The C library function fputs also uses strlen, so it can not handle
nil-arguments too. Fputs and fprintf are used in the macros putst 
and putstring in token.h. To fix this redefine these macros in token.h
into :

	#define putstring(s)	( s == 0 ? 0 : fputs(s,out_file) )
	#define putst(ss)	( ss == 0 ? 0 : fprintf(out_file,"%s ",ss) )
---------------------------------------------------------------------
BUG in lex.c:
The cfront program assumes that cpp lines are of the form:

# <nr> "<filename>"<NL>

where <nr>       is a number
      <filename> is the name of a source file
      <NL>       is the newline character '\n'

There may be no characters between the last quote(") and the newline 
character. If there are such characters you get the following error message:

    un expected eol on # line

Which is a strange message anyway, because this error is reported
only if cfront does not find a newline character.
On the SUN3 cpp puts a space after the last quote, and sometimes
even a number.  I don't know the meaning of this number,
but it makes cfront creating this error message and it stops compiling.

The fix I made is to ignore everything between the last quote and the
newline character. The change is made in src/lex.c.
This is the diff file:

diff lex.c.original lex.c.fixed
950c950
< 				if (get(c) != '\n') error("unX eol on # line");
---
> 				while (get(c) != '\n') ;

---------------------------------------------------------------------
BUG in simpl.c:
Problem with de-refencing nil pointer. The next file makes the C++
compiler dump core on the SUN3. On our VAX11/780 running Unix4.3BSD
it produces the warning:
    "a.c", line 7: warning: maybe no value returned from hoi()

This error occurs when there is a return statement between "{" and "}"
and after the final "}" follows a ";".

a.c:
	int hoi()
	{
	    {
		return(9);
	    }   
	    ;
	}

The remedy is to delete the final ";".


This problem isn't really fixed, because I don't know where the nil pointer
comes from. It only gives an internal error with a line number instead
of dumping core.
Here is the diff file:

diff simpl.c.original simpl.c.fixed
540a541,545
> 				Pexpr Pexpr_tmp = tail->e;
> 				if( Pexpr_tmp == 0 ){
> 				    error('i',"fct.simpl() deref nil");
> 				}
> 

The error report of the fixed compiler is:
    "a.c", line 7: internal <<cfront 10/10/85>> error: fct.simpl() deref nil
---------------------------------------------------------------------
-- 

	Jos Warmer,       josw@mcvax.UUCP