Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ncar!unmvax!uokmax!servalan!epmooch!ben From: ben@epmooch.UUCP (Rev. Ben A. Mesander) Newsgroups: comp.sys.amiga.programmer Subject: Re: SAS gripes (was New Eiffel-like OOP language) Message-ID: Date: 23 Jun 91 15:39:10 GMT References: <1991Jun16.063222.1304@csis.dit.csiro.au> <1991Jun17.161534.323@nntp-server.caltech.edu> <15547@exodus.Eng.Sun.COM> <1991Jun21.164424.3364@nntp-server.caltech.edu> Organization: Elvis Presley Museum Of Obsolete Computing Hardware Lines: 24 In article <1991Jun21.164424.3364@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: [...] >>Also you should read the section on large macros, which describes the >>limits and why you might want to use lc1b rather than lc1 if you have >>large macros, and last but not least, if you normally programmed on a >>SystemV UNIX machine you would not have been suprised at all by the >>behaviour of scanf in the Lattice library. It is more accurate to say >>that the Lattice scanf is most un-BSD like. > >Admittedly, I'm heavly influenced from BSD. However, I thought that their >scanfs() were similar. I have always treated them as if they were in my code >and they work okay on both BSD and SystemV. I don't think it's BSD or USG behavior to dereference null pointers, but SAS's scanf does do this sometimes. It also writes to location zero. Use the source, Luke, and grab a different scanf from somewhere. SAS is a pretty darn good Amiga C compiler, an excellent debugger, but the library has some cruft in it. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |