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)