From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: karish@pangea.Stanford.EDU (Chuck Karish) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/15 Message-ID: <4kuble$35k@nntp.Stanford.EDU>#1/1 X-Deja-AN: 147657444 references: <4knqun$ga1@nntp.Stanford.EDU> organization: Mindcraft, Inc. newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-15T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Chuck asked (replying to me): > >">Of course GCC has a much more agressive view of portability, but it >>certainly would be nice to see more standardization here, > >I don't understand. Do you have portability problems when you use >gcc in ANSI mode?" >Yes we do. gcc takes the view that it should work in all common C >environments (i.e. those in use today), whether or not they are ANSI >compliant. Early on when I started writing some C runtime code for >GNAT (or more accurately interfacing to standard C runtime routines), >I followed the ANSI standard. As I mentioned before the particular >example I remember is that I used the return value of sprintf, >assuming it returned int. My code worked on several systems, and >then failed on SunOS, and I was told -- oh yes, everyone knows that >you cannot use the returned value of sprintf. Now of course it is >the case that there must be available on SunOS a conforming library, >but we require gcc to work with all commonly used environments without >any special fiddling in choosing libraries. While I applaud the attempt to make gcc work even with broken C libraries, I don't think it's particularly productive to describe gcc as being flawed when this turns out not to be possible. >That's what I meant by >saying that gcc has a more strenuous view of portability. Chuck's >view of portablity seems to be "use ANSI, and too bad if it doesn't >work for you". That's not the way I work and it's not the way I've described my approach in this thread. >That's fair enough but it is not the attitude that >gcc takes, where we are aiming for much more general portability. There are limits to what can be accomplished this way. ANSI C and traditional C are different languages. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu