HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/25/90)
Well, I shipped out version II of c68 more than a week ago and I received nearly no comment on it, though I do not assume it is perfect at the moment. ...there is a typographical error in outgas.c: fputsf instead of fputs (it used to be fprintf). Meanwhile, I found no bugs except that I changed my opinion that fold_const may fold constants across casts (it is in the comments). I hope that c68 reliablity is so good that you can use it as your every-day compiler (I do so since long ago). Please do so and report bugs eventually to me. C.v.W.
andreas@nixhhs.UUCP (Andreas Wettengel) (07/26/90)
In article <25598@nigel.udel.EDU> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >Well, I shipped out version II of c68 more than a week ago and I >received nearly no comment on it, though I do not assume it is perfect >at the moment. Well, there is a problem with c68lib and the calls the compiler generates for it. The names are now all in "user name space". If you have a function called "ldiv", your division of long integers will fail. It would certainly be better to use implementation reserved names beginning _[A-Z_]. Btw, the same is true for call* and len in other/call.c... The old c68 used different names, so if you compiled your libc.a using c68, you have to recompile the following files: lib/ansi: ctime.c strtol.c strtoul.c rand.c scanf.c lib/other: doprintf.c lrand.c printk.c curses.c (Those are the ones that I found.) >I hope that c68 reliablity is so good that you can use it as your >every-day compiler (I do so since long ago). I do so also; now that it has nice error messages, it is even better. Andreas -- Andreas Wettengel | Nixdorf Computer AG Tel. +49 40/6371-2423 | Ueberseering 33 (...uunet!)unido!nixhhs!andreas | 2000 Hamburg 60 NERV: nixhhs!andreas.eunet | West Germany
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/30/90)
well, the names of the compiler support library are perhaps not in their final state. The original plan was to use the ACK compiler support routine together with IEEE floating point stuff. Unfortunately, I am not sure if single-precision floating point stuff is in the routines posted to this group. But the time was restricted and other points got a higher priority... C.v.W. P.S.: recompile everything with the new compiler release.