Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 24 Mar 2004 11:17:12 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Cc: gshyam AT denver DOT india DOT mentorg DOT com, harsh_arora AT mentorg DOT com Subject: Re: 1.5.5.1 sysconf() NOT implemented for _SC_STREAM_MAX and _SC_TZNAME_MAX? Message-ID: <20040324161712.GA5261@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com, gshyam AT denver DOT india DOT mentorg DOT com, harsh_arora AT mentorg DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i On Wed, Mar 24, 2004 at 08:18:11PM +0000, Ghanshyam wrote: >I found some problem in sysconf() system call with respect to following >assertions defined in "IEEE std 2003.1 -1992 Test methods for measuring >conformance to POSIX-part1" document > > >10(A) If STREAM_MAX is defined when the header is included: > A call to sysconf(_SC_STREAM_MAX) either returns -1 without changing errno > or returns a value greater than or equal to {STREAM_MAX}. >Otherwise: > A call to sysconf(_SC_STREAM_MAX) either returns -1 without changing errno > or returns a value greater than or equal to {_POSIX_STREAM_MAX}. > >11(A) If TZNAME_MAX is defined when the header is included: > A call to sysconf(_SC_TZNAME_MAX) either returns -1 without changing errno > or returns a value greater than or equal to {TZNAME_MAX}. >Otherwise: > A call to sysconf(_SC_TZNAME_MAX) either returns -1 without changing errno > or returns a value greater than or equal to {_POSIX_TZNAME_MAX}. > >********when called with argument _SC_STREAM_MAX or _SC_TZNAME_MAX, It >returns -1 but set errno to 22 (EINVAL) but is should not modify its >value. > >By looking into code, I found that sysconf() is not implemented for these >argument values! Please calm down. >Is any one going to address these in near future? Sorry, no. Were you under the impression that cygwin is guaranteed to conform to some posix standard or that people would be actively fixing any problems reported in posix compliance? Unfortunately, neither is true. As I've previously noted, you could always contribute patches yourself. Alternately, (and I know that Mentor knows about this) you could engage the services of Red Hat or some other organization to implement whatever you need. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/