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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: Lawrence Kirby Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/14 Message-ID: <829499628snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 147500697 x-nntp-posting-host: genesis.demon.co.uk references: <4knqun$ga1@nntp.Stanford.EDU> <4kpceq$e4b@solutions.solon.com> x-mail2news-path: genesis.demon.co.uk organization: none reply-to: fred@genesis.demon.co.uk newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-14T00:00:00+00:00 List-Id: In article dewar@cs.nyu.edu "Robert Dewar" writes: >Peter said: > >"delete() is not ANSI. remove() is ANSI. I have never seen a system that >didn't offer it, since the 3b1. It's certainly trivial to write. (A good >patch for portability is to write standard code, and have a set of >conditionally built modules to provide the standard functions in terms >of the not-standard but available on all old systems functions.)" > >Oops, that's right, it is indeed remove I meant (I don't know it because >I don't use it -- I don't use it because the Microsoft book says it is >not implemented in some systems). On the other hand, that same book says >that unlink is implemented in all systems, so clearly at least for the >moment unlink is safer to use if you are aiming at maximum portability. remove() is the ANSI defined function, unlink() is the Unix/POSIX defined function. I guess comp.lang.ada readers would be more interested in the latter as far as this thread is concerned but comp.lang.c readers should be using remove() unless they have a good reason not to. I believe the book is misleading you. I wonder though if Ada provides all of the functionality that the C standard library provides and if not whether the Ada POSIX bindings redress the holes. >Rememerb that gcc is targeted to more than 300 different C library >environments, and you want to absolutely minimize conditional stuff. gcc has been ported to environments over many years which have little or no ANSI C support. The situation now is somewhat different, not least because you can use gcc/glibc on many systems. By the sound of it GNAT is doing a similar service for up-to-date Ada. The considerations are different for code written now. >That's what I meant by having a strenuous view of portability. I would >rather guess that Peter is pretty Unix oriented, and of course we are >trying for a wider scope of portability than Unix! In which case you definitely want the ANSI C remove() over the Unix/POSIX unlink(). The only systems where unlink() is more likely to occur are very old systems since unlink() existed first. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------