🚀 go-pugleaf

On Wed, 19 Aug 92 22:14:18 BST bothner@cygnus.com wrote:

>Thank you for your report.  Of course, our primary goal is to
>support g++, but I accept changes reduce dependencies on g++-specific
>features or extensions.  However, changes to work around bugs
>in a specific vendor's C++ compiler are less likely to get accepted.
seems a reasonable approach to me. However, it would be useful if there was a
README.nogcc file pointing out some of the likely problems.

>> o You need HP CC specific code to initialise vtables in strstrbufs.cc
>>         I conditionally compiled around this with HPCC_VTBL_DECLARATION
>
>Why doesn't the generic cront version work?  Is __vtbl__7filebuf
>the wrong type?  If so, what?

it's not the symbol that's the problem its the use of extern char vt_filebuf[1].

i.e. if you just refer to __vtbl__7filebut as a an extern char * then things seem
to work!

#if defined(HPCC_VTBL_DECLARATION)
// this may work on HP-UX using HP's CC
#define vt_filebuf (char*)__vtbl__7filebuf
#else
// This works for cfront.
#define vt_filebuf __vtbl__7filebuf
extern char vt_filebuf[1];
#endif

>>        similarly
>>        char *s = NULL; // doesn't NULL is void * 0
>>        char *s = (char*)NULL;  // does
>
>These I don't want to change.  If your compiler does not recognize
>(void*)0 as a NULL pointer, redefine NULL as 0 instead.
I soon realised that redefined NULL as 0 would have been the better fix to apply in
any case.

>The g++-include changes I don't think I want to bother with.
>I'm more include to suggest using Ron Guilmette's pupulate script,
>which generates include stub files (with extern "C" { #include_next <XX.h> })
>for system include file.
where can I get this script from?

I forgot to mention a couple of things:

i) all of the  tXX.C test programs need to explicitly return 0 when using HP CC.
I guess this is a side effect of the way that the initialisation is done. The HP
compiler detects main and when generating code inserats a call to _main as the
first thing in main. This differs from the normal practice of having a wrapper
which calls main and is the real entry point.

ii) the iostream/test tests don't work. In particular tFile and friends crash
before getting into main and the check-stdio tests don't work with I/O redirection
- i.e. they're output disappers when stdout/stderr are redirected, it doesn't go to
the screen and doesn't up in a file!

Also, what is the correct (ARM specified) behaviour wrt to enum names and top-level
functions? That is, are they allowed to clash or not?

enum a { b , c };
int b( char, char );

causes HP CC to complain. Is HP CC wrong here?

    	Cheers, Cos.

Cosmos Nicolaou

email:  can@ansa.co.uk (...uknet!ansa!can)      ANSA,
tel:    +44 223 323 010                         Poseidon House,
fax:    +44 223 359 779                         Castle Park,
                                                Cambridge,
                                                United Kingdom CB3 0RD
---