Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Apr 1995 14:56:29 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        ache@freefall.cdrom.com, wollman@halloran-eldar.lcs.mit.edu
Cc:        CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Subject:   Re: cvs commit: src/sys/sys unistd.h
Message-ID:  <199504300456.OAA13571@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>   Enable _POSIX_SAVED_IDS and fix comment to describe current situation

>This should be left undefined so that programs call
>sysconf(_SC_SAVED_IDS) instead.

No, _POSIX_SAVED_IDS is one of 3 "Compile-Time Symbolic Constants" which
are required to be valid at compile time.  The others are _POSIX_JOB_CONTROL
and _POSIX_VERSION.  Of course, this is braindamaged except possibly for
_POSIX_VERSION.  The standard explicitly states that applications may
choose to call sysconf(_SC_SAVED_IDS) instead but this would only make a
difference if the runtime system is inconsistent with the compile time
system (i.e., broken).

Are there any large applications that handle all of the POSIX configuration
options to give maximal portability and maximal efficiency?  Stuff like
the following is required:

#include <limits.h>

#ifdef _POSIX_NO_TRUNC
#if _POSIX_NO_TRUNC == -1
/*
 * The option is not provided on any file, i.e., file names are always
 * silently truncated.
 */
 masses of code to deal with silent truncation of file names
#else
/*
 * The option is not provided on every file, i.e., long file names cause
 * error ENAMETOOLONG.
 */
 masses of code to deal with ENAMETOOLONG
#endif
#else
/*
 * The option must be interrogated at runtime.
 */
 masses of code to interrogate option at runtime and DTRT depending on
 the results.
#endif

Nested ifdefs for maximally portable/efficient handling of NAME_MAX
would also be required (if NAME_MAX is constant and small, then you
might want to handle truncation different from when NAME_MAX is
constant and large).

I think the compile time constants are too much trouble to use
(correctly) in most cases.  This problem is often avoided by using
them incorrectly :-(.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504300456.OAA13571>