🚀 go-pugleaf

In article <17386@kuhub.cc.ukans.edu> BROWNRIGG@kuhub.cc.ukans.edu writes:
>Anybody out there have any experiences with AOS/VS C?
>

We have had AOS/VS C running at the University of Melbourne for about 5
years.

>In particular:
>
>-Is it a solid, stable product?
>

Yes. This, I might add, in in stark contrast to the AOS/VS F77 compiler,
which has given us nothing but trouble from the start. In fact we have
three versions on our system at present, because they ALL have bugs: it's
just a question of using the ones that work for the piece of code you
need to compile!!

>-Is it closer to ANSI standard conforming than the typical Unix compiler?
> Less conforming?
> Any portability problems to note?

Prototypes are not yet supported. The include files structures are not
standard. A typical problem is that using, say, 'atof()' works fine
without #include'ing <ctype.h> (I think that's the one), but of course
this gives you rubbish on another machine (a Sun, for example).

>
>-Are the run-time libraries reasonably complete, and not wanting?
>
You don't say whether you have MV/UX or not. One of the biggest problems
is porting UN*X code. To be fair, DG have done a good job here, making
AOS/VS look like unix, but there can be some *real* headaches. Several
include files do not exist, and of course there is no analog for many
unix functions. Fork() does not handle file descriptors properly.

If you do not have MV/UX or do not want to port unix code, you shouldn't
have any problems.

>-Efficient execution, good optimization?
>

Yes.

Richard Brown
(pbrown@munda.ph.unimelb.edu.au)