Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Aug 2013 12:23:39 -0400
From: Rich Felker <>
Subject: Re: SUN_LEN

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

- 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

- 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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.