From owner-freebsd-arch@FreeBSD.ORG Wed Apr 30 11:04:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1058137B401; Wed, 30 Apr 2003 11:04:47 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78EB743F93; Wed, 30 Apr 2003 11:04:43 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h4UI4Ulu001958; Wed, 30 Apr 2003 21:04:30 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h3UI39b5006835; Wed, 30 Apr 2003 21:03:09 +0300 (EEST) (envelope-from netch) Date: Wed, 30 Apr 2003 21:03:09 +0300 From: Valentin Nechayev To: "Jacques A. Vidrine" , Paul Richards , "W. Josephson" , freebsd-arch@FreeBSD.org Message-ID: <20030430180309.GB312@iv.nn.kiev.ua> References: <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430164135.GB26508@madman.celabo.org> X-42: On Organization: Dark side of coredump Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 18:04:47 -0000 Wed, Apr 30, 2003 at 11:41:35, nectar (Jacques A. Vidrine) wrote about "`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)": JAV> Package X defines a function named `strlcpy', that works well for JAV> Package X and may or may not have any relationship to the `strlcpy' JAV> we all know and love from OpenBSD. As already said in discussion in cvs-all@, this is why ports infrastructure exists and has such features as now. You can't do full redesign of the whole FreeBSD for any new application which potentially can run on it but has its own and highly specific insects inside. If application is inconsistent, as qpopper in this example, with current libc, it's better to add something similar to `#define strlcpy qp_strlcpy' to its headers, instead of making changes in libc. If there are a few hundreds of such ports, your approach can be reasonable; but I can't see any reason making things such way for the only one program, and bad program (qpopper's history has too many exploits and its coding style is as ugly as seven sins together). Adding one patch to port is better. Moreover, due to extremal uglyness of qpopper, I think it anyway requires more steps (as static linking with libparanoia, for instance). JAV> Guess which scenario applied before my commit to make strlcpy/strlcat JAV> weak references? which applies now? which would apply if we broke JAV> strlcpy/strlcat into another library? Is strlcpy defined with different interface and/or semantics in any standard, including written, as Single Unix Spec, or real, as local tradition or GNU software? I don't know such issues. JAV> JAV> Oh, of course. I forgot that we only support applications written for JAV> FreeBSD. I thought we should be a decent platform for ISO C and POSIX JAV> applications as well, but that is clearly foolishness. JAV> ISO C and Posix doesn't know strlcpy(). ISO C defines, AFAIR, that all function names matching /^str/ are reserved for future implementations, but it's unreal to forecast seeing another strlcpy() in it. -netch-