Date: Thu, 19 Oct 1995 16:48:10 +1000 From: Bruce Evans <bde@zeta.org.au> To: terry@lambert.org, wollman@lcs.mit.edu Cc: bakul@netcom.com, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510190648.QAA01589@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > ] #define ARG_MAX 65536 /* max bytes for an exec function */ >> >> > Type: Bogus. >> >> Type: POSIX. Type: Bogus. >> BZZZZT! Wrong, but thanks for playing. You can ask David or John >> about the memory-fragmentation issues which mandate the use of a Defining it makes it part of the ABI and inhibits future changes such as changing it to another fixed value or solving the memory fragmentation problems and making the limit indeterminate (POSIX 2.8.4 says it shall not be defined if it is indeterminate). Few programs use ARG_MAX, but those that do may break unnecessarily if it is changed. The limit should also be OS-dependent to support emulation of bogus definitions of it in other OS's. E.g., in Linux it is 128K, so Linux programs that rely on it may break. Both Linux and FreeBSD should leave it undefined so that applications are forced to use sysconf() if they want to know about it. The emulation support for Linux would then be trivial (just return the FreeBSD limit is sysconf()). >> > ] #define CHILD_MAX 40 /* max simultaneous processes */ >> >> > Type: Administrative (compile time override) >> >> Type: Bogus but POSIX. Type: Bogus (fails POSIX standards tests). This is another POSIX limit that shall be left undefined if its value is indeterminate. Its value is indeterminate because it may be changed by setrlimit(). This limit is sometimes bogusly redefined in kernel config files without changing its value in the <sys/syslimits.h>. Then the advertised value is wrong even in the default case. (the kernel just uses the redefined value for the default rlimit, so the effect is the same as if all programs started with a setrlimit()). >> >> > Required by: The ability for a user program to fork(2) the system to >> > death. >> >> BZZZZT! This value should be modifiable at run time. (It isn't yet.) BZZZZT! :-) The maximum number of child processes is modifiable at runtime (using setrlimit()) and sysconf() correctly returns the modified value. >> > ] #define LINK_MAX 32767 /* max file link count */ >> > Type: Pragmatic >> Type: POSIX. Type: Bogus. This is another POSIX limit that shall be left undefined if its value is indeterminate. Its value is indeterminate because it depends on the file system. File systems and sysconf() handle it more or less correctly. >> > ] #define MAX_CANON 255 /* max bytes in term canon input line */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. There is a related limit TTYHOG whose value (1024) is nowhere near the advertised limit. Defining the limit correctly would make it part of the ABI and interfere with future improvements, as above. Fortunarely, this limit is even less useful than ARG_MAX, so perhaps nothing depends on it. >> > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ >> > Type: Standard (Interoperability, Legacy) >> > Required by: NFS, YP >> > Reason: Excess groups are truncated by the NFS external ID >> > representation mechanism. In point of fact, this >> > limit should be 8 to ensure interoperability with >> > older SVR3/SVR4 systems. >> >> No, the NFS and RPC code have their own kluges to deal with broken >> systems. >You mean that they should. Try mounting an SVR4.0.2 NFS volume from a >BSD system, and then accessing it from a credential with > 8 groups. Unfortunately fixing limits in FreeBSD (by making them indeterminate) won't affect compatibility. >> > ] #define OPEN_MAX 64 /* max open files per process */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. S Same as for CHILD_MAX. >> > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. A pain in the ABI, as above. Under Linux, PIPE_BUF is 4095. If the limit is actually 512 under FreeBSD, then Linux programs that expect to write 4095 atomically to pipes can't be emulated properly. >[ ... BC_ * ... ] >> > Type: Bogus >> >> Type: POSIX. >> >> > Required by: A user space program >> >> Required by: IEEE-CS technical committee P1003.1. >> >> Any user-space program that executes `bc' to do arithmetic, or uses >> the LC_COLLATE localization support, or executes `expr' to do >> arithmetic. >Yetch. >Revised-Type: Gross, but POSIX [a-zA-Z]etch. Interferes with ABI compatibility at the library level. Fewer problems with emulation because other OS's have their own libraries. Summary: 1,$s/^Type:.*/Type: Bogus/ Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510190648.QAA01589>