From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 21:46:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4E2106566B for ; Fri, 2 Apr 2010 21:46:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 88CED8FC17 for ; Fri, 2 Apr 2010 21:46:09 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 5EF27A5DD8B; Sat, 3 Apr 2010 05:46:08 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id kgqjwjf0B54g; Sat, 3 Apr 2010 05:46:01 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 4A64BA5DD68; Sat, 3 Apr 2010 05:45:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=kE5eD+5rvI9k9oJvqRqUypWONS80PHPQ2c0F5CcPIyTv8x7KpIQn6l8Us00jGVhUt 5QTo7+owjkbMC7tkoMrKg== Message-ID: <4BB66593.3020804@delphij.net> Date: Fri, 02 Apr 2010 14:45:55 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Garrett Cooper References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <86tyrvs3js.fsf@ds4.des.no> <20100402084640.GB19647@lonesome.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Mark Linimon , freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=, =?ISO-8859-1?Q?rgrav?= Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:46:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 2010/04/02 14:32, Garrett Cooper wrote: > 2010/4/2 Mark Linimon : >> On Thu, Apr 01, 2010 at 03:30:47PM +0200, Dag-Erling Smørgrav wrote: >>> And yes, I *will* keep harping on this until people Get It. >> >> You're harping at the wrong people. Complain to the application authors, >> not to the poor slobs trying to maintain the ports collection. >> >> There's a lot of crap code out there on the internet. If we want to >> insist that all the application authors both a) write good code and that >> b) understands how FreeBSD does things, well, we can do that, but it's >> not going to have much effect. >> >> Probably 75%+ of the application authors neither know nor care that >> their code is being run on anything other than Linux. In extreme >> cases we've enountered authors who outright refuse to accept our >> patches, either due to philosophical disagreement or just due to the >> xtra hassle. > > The problem actually was most likely the fact that the functionality > wasn't properly documented or that people didn't thoroughly read or > understand the documentation before implementing the feature. If > there's anything that I've learned from cleaning up messes in the past > (to be fair, some which I've created as well), it's that a lot of > incorrect logic is created by misunderstanding things and/or making > false assumptions on how things should work. To be fair, the usage of _LARGEFILE64_SOURCE IS documented, people just don't pay enough attention. GNU headers choose to use #ifdef _LARGEFILE64_SOURCE instead of #if _LARGEFILE64_SOURCE == 1, to be pedantic, the latter form is correct. [1] > But yes, zlib is buggy w.r.t. the item Xin Li mentioned and needed to > be fixed. Too many folks try to resolve application porting issues by > using inline: If we use Large File Summit's documentation, it's not at all zlib's issue. > #ifndef SOME_LARGELY_USED_CONSTANT_INTRODUCED_IN_VERSION_B > /* #define a constant or typedef a feature */ > #endif > > This generally quasi-works in versions A (assuming the application > runs and the developer upstream did their testing on version A's > software... heh) or version C (typically a Linux) developer decided > that they wanted to change the definition and dashed the consequences > about backwards compatibility in their code. kernel.org sources are > riddled with this kind of `decision making'. Applications aiming to be portable should not define _LARGEFILE64_SOURCE at all, on any *BSD platforms. And, if they really want to do that, they should either use - -D_LARGEFILE64_SOURCE or #define _LARGEFILE64_SOURCE 1 in the first place. No, it's not zlib's fault. We may workaround the application bug on FreeBSD by removing all these checks in zlib.h and zconf.h, as they doesn't affect FreeBSD's base system's headers at all, HOWEVER, it's still the application's bug and should be fixed upstream. [1] http://www.unix.org/version2/whatsnew/lfs20mar.html Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLtmWTAAoJEATO+BI/yjfBrwIH/Ap0FEtDRJ02ZKnTuUfjj25C c9n3QGH+26mhrzO1KP7pVyvW28zQCgH7RgOAdyXz6llWNbonSAg4/yN/80tWDk9w juIb/PfLxs8us/PbmUqkp0ZQATaUhmQO4Jw45LpBD0X7PYce7VhvednjWcFtNeLP v3f5MZ9inbDUPF6Bb7ErwJ2BGnFG2FGekCnKwgIAPN0DC61BrJ5PFVQm5lP1YVs3 WOJS3wU39xanzy87ZEv5Gh8SCtIgxcUa4A5G/+a1pStVXOcqL+DOd5nZQqCjlvPt r5+dLoFFpQNJAEeQwIXlgWQkjYfdCHTqNsPs4mGWEaEn8wMSKdknyuA/5X+R1Kk= =Uqae -----END PGP SIGNATURE-----