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: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/13 Message-ID: #1/1 X-Deja-AN: 147325300 references: <4kkdv4$ik4@nntp.Stanford.EDU> <4knqun$ga1@nntp.Stanford.EDU> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-13T00:00:00+00:00 List-Id: 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. 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 fair enough but it is not the attitude that gcc takes, where we are aiming for much more general portability. Over time, the two views will converge but not yet. I have found the Microsoft runtime reference manual very useful. For each function it indicates ANSI/Unix/Xenix/DOS/OS2 compatibility. There are many cases where the ANSI box is checked and other boxes are not. For instance, unlink is compatible with all systems but is NOT ANSI, on the other hand delete, which is the ANSI version, is not available on all systems. It just depends on what you are trying to achieve!