Bug 4892 – dup2(1, OPEN_MAX) return is not POSIX.1 conformant

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 4892 - dup2(1, OPEN_MAX) return is not POSIX.1 conformant

Summary:	dup2(1, OPEN_MAX) return is not POSIX.1 conformant

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	kernel (Show other bugs)
Sub Component:
Version:	6.0
Hardware:	i386 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Michael K. Johnson
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	1999-09-03 15:10 EDT by Jay Turner
Modified:	2015-01-07 18:37 EST (History)
CC List:	2 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2000-04-22 02:09:02 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Glen Foster 1999-09-03 15:10:52 EDT

According to POSIX.1 (page 149, 6.2.1.4, lines 70-74), a
call to dup2(1, sysconf(_SC_OPEN_MAX)) should set errno to
EBADF, but instead (incorrectly) sets errno == EMFILE.

This is seen running the PCTS on a stock 6.0 Intel system.

Comment 1 Cristian Gafton 2000-01-04 17:25:59 EST

Assigned to dledford

Comment 2 Cristian Gafton 2000-01-04 17:26:59 EST

Assigned to dledford

Comment 3 Bill Nottingham 2000-02-05 18:31:59 EST

Still exists in 2.2.15pre5.

Comment 4 Doug Ledford 2000-04-22 02:09:59 EDT

Last I knew, this is a backwards compatibility issue.  In order to keep older
binaries from breaking on new kernels that support thousands of open files in a
single application, the kernels have to *pretend* like OPEN_MAX is 1024, like it
used to be.  However, to those applications that know about it, they can call
setrlimit() to increase the number of files allowed.  As far as I know, the
result of this situation is that we have some differing error returns and this
is by design.  If that's wrong, then I'm sure Alan can correct it ;-)

Note You need to log in before you can comment on or make changes to this bug.