From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 22:42:20 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60D5937B404; Mon, 7 Jul 2003 22:42:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B931443FAF; Mon, 7 Jul 2003 22:42:19 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h685gJAI017646; Tue, 8 Jul 2003 01:42:19 -0400 (EDT) Date: Tue, 8 Jul 2003 01:42:18 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <008201c344fc$392c0760$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: ttyname_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 05:42:20 -0000 On Tue, 8 Jul 2003, David Xu wrote: > I found our ttyname_r has different return type than POSIX: > http://www.opengroup.org/onlinepubs/007904975/functions/ttyname.html > and POSIX says: > If successful, the ttyname_r() function shall return zero. > Otherwise, an error number shall be returned to indicate the error. > > libc implements it as following format: > char * ttyname_r(int fd, char *buf, size_t len); > and when success, it returns non-NULL pointer, it almost has opposite > meaning with POSIX. > This causes some pthread tests failed here. I seem to remember this issue coming up before, but I don't recall what the outcome was. FWIW, Solaris defines ttyname_r both ways (according to to ttyname_r(3C)): #ifdef _POSIX_PTHREAD_SEMANTICS int ttyname_r(int fildes, char *name, size_t namesize); #else char *ttyname_r(int fildes, char *name, int namelen); #endif I'd support changing it, but I don't know whether we'd need a library version bump to do that. -- Dan Eischen