Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!pacbell!att!ihnp4!ihuxy!nowlin
From: nowlin@ihuxy.ATT.COM (Jerry Nowlin)
Newsgroups: comp.sys.atari.st
Subject: Aztec C for the ST
Keywords: c compiler, buggy, late
Message-ID: <2542@ihuxy.ATT.COM>
Date: 31 May 88 20:46:24 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 62

I recently purchased Aztec C for the Atari ST from MANX Software Systems
under a 30 day money back guarantee.  Unfortunately, I sent it back.  The
following is part of a letter I sent to MANX Software Systems on May 29th. 
I left out the part about my good experiences with their CP/M and MS-DOS
versions of Aztec C and the part about them shipping me an empty disk in
the first place and the lack of speed with which they corrected that
problem.  This posting refers strictly to the technical problems I had with
their Atari ST C compiler.  I thought it might keep some people from making
the same mistake I did.  I waited almost two years for this product and I
was very disappointed.

===========================================================================
Problem 1.

Yesterday I finally had time to take a look at Aztec C for the Atari ST.
First I scanned the documentation again (remember I'd had it for three
weeks already) and installed it on my hard disk.  Then I used the example
from section 3.3, page Tut.6 of the tutorial to compile a simple hello
world program.  Unfortunately when I tried "cc hello" all I got was a
temporary file and no ".o" file.  I read the compile section of the
document in detail and could see no reason why I shouldn't have gotten a
".o" file but I eventually tried using the "-t" option to create a ".asm"
file and then used the assembler to explicitly create a ".o" file.  I was
then able to use the linker to get an executable that worked, almost.

Problem 2.

I included a statement in my hello world that printed one line to standard
error (stderr) in order to see how your buffering would effect the order of
output and if redirection would be supported independently for the two
standard output streams.  Your manual talks about stderr in a couple of
places.  Section 2.1 of the library chapter mentions stderr as one of the
three "preopened files" and in section 3.3 it is mentioned as the only
stream to be unbuffered by default.  I could not get the standard error
output to show up anywhere.  I had no problem with standard out when used
implicitly with a simple printf() or explicitly with a fprintf(stdout,).
Standard error is sadly missing.

Problems 3. (the clincher)

I then went on from a simple hello world program to a more complicated
version of the standard UNIX where(1) command that I have working in
Alcyon, Lattice, and Megamax.  When I tried to compile it in Aztec I got
two very disturbing undefined symbols from the linker.  It couldn't find
xbios() or gemdos().  I tried linking with all the libraries that came with
the Aztec system but no luck.  Then I checked the standard osbind.h header
to see how they got around this problem and discovered that Aztec has
decided that the library routine names that all the other C compilers have
found acceptable weren't good enough.  They had to use different ones.
Since different osbind.h headers have been the source of several bugs in
the past I have coded my programs with direct library calls to avoid
problems between different versions of osbind.h.  Now you come along and
decide to make even the library routine names different.
===========================================================================

Since it took me a total of about two hours to uncover this many problems I
returned my copy of Aztec C and don't intend to bother with any MANX
products from now on.  Has anyone else purchased Aztec C for their ST yet?
I'd be interested in different (opposing) opinions.

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)