From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3940 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: SUN_LEN Date: Wed, 21 Aug 2013 12:23:39 -0400 Message-ID: <20130821162339.GY20515@brightrain.aerifal.cx> References: <5214AC94.9090408@barfooze.de> <5214B4CF.4090202@barfooze.de> <20130821144552.GD30088@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1377102233 4098 80.91.229.3 (21 Aug 2013 16:23:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Aug 2013 16:23:53 +0000 (UTC) Cc: yukoba@accelart.jp To: musl@lists.openwall.com Original-X-From: musl-return-3944-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 21 18:23:54 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VCBCM-0000gF-8m for gllmg-musl@plane.gmane.org; Wed, 21 Aug 2013 18:23:54 +0200 Original-Received: (qmail 32334 invoked by uid 550); 21 Aug 2013 16:23:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32325 invoked from network); 21 Aug 2013 16:23:53 -0000 Content-Disposition: inline In-Reply-To: <20130821144552.GD30088@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3940 Archived-At: On Wed, Aug 21, 2013 at 04:45:52PM +0200, Szabolcs Nagy wrote: > * ?$B>.NSM* [2013-08-21 22:27:22 +0900]: ^^^^^^^^^^^ The fact that gmail seems to be using ISO-2022-JP by default for encoding Japanese headers suggests that maybe we need to add stateful encodings to iconv... :( > > > > So is this mean, you don't want to add glibc non-standard APIs to musl? This is a difficult question to answer directly. The factors that contribute to whether we want to add non-standard APIs are things like: - Does it meet a need that's otherwise unmet? - Is it ugly namespace pollution? (While there's no requirement to protect the namespace in _BSD_SOURCE or _GNU_SOURCE profiles, we try to avoid extreme ugliness.) - Does it have major historical precedent? - Does it have conflicting historical definitions on different systems? - Would it improve compatibility with binary apps/libraries or just build-time compatibility? - Is the number of apps affected so small that we could just recommend patches for them? For SUN_LEN, I think based on the above factors, it's okay for inclusion (with the proper namespace protection of course). > i think SUN_LEN can be added, but it should be under > _BSD_SOURCE because it violates the posix namespace > > #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) > #define SUN_LEN(s) (sizeof *(s) - sizeof (s)->sun_path + strlen((s)->sun_path)) > #endif This is insufficient, since sys/un.h does not expose strlen. We could either add a conditional declaration of strlen under this #if, or make an inline function for SUN_LEN that just does the strlen-like loop manually. I'm not sure what's best. Rich