Date: Thu, 22 Jan 1998 18:44:34 +0200 (IST) From: Eli Zaretskii To: "X DOT PONS AT UAB DOT ES" cc: djgpp AT delorie DOT com Subject: Re: access() in DJGPP and TC/BC In-Reply-To: <01ISNOZW1WPE008ULX@cc.uab.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 22 Jan 1998, X DOT PONS AT UAB DOT ES wrote: > I have found a problem when porting TC/BC code to DJGPP because of > the different meanings of the accesibility mode ("amode", the second > parameter) of the access() function. The values of the mode parameter for `access' are not portable between different systems. Some systems define the x_OK symbolic constants (and these symbols should be used when they are defined), others don't. On Unix, `access' doesn't predict well the actual accessability of files, since it doesn't use the effective user id (it's a long story). This makes `access' very non-portable. In addition, it is very expensive on some systems. For those reasons, I would suggest to avoid `access' altogether and use `stat' instead. `stat' is POSIX and is therefore much more portable, even to DOS compilers such as TC. > - Ask if anybody knows a reason for that difference. AFAIK, there's no special reason, but TC is not the only compiler, and being compatible with it would probably mean being incompatible with some other compiler. > - Post to the group my proposal to avoid this. It is a small #include > that can be included both in DJGPP and TC/BC codes and that allows > using DJGPP notation under TC/BC. Nevertheless, be aware that it > does not solve the confusion when access() is (was) already written > using TC/BC numerical codes instead of the proposed words. > > > #ifdef __DJGPP__ > #include > #else > #include > #endif > > #if defined (__BORLANDC__) || defined (__TURBOC__) > > #define F_OK 0 I think the following is a better way: #ifndef F_OK #define F_OK 0 #endif #ifndef R_OK #define R_OK 4 #endif etc.