From: He X <xw897002528@gmail.com>
To: musl@lists.openwall.com
Subject: Re: Re: fallback to no translations when gettext("")
Date: Sat, 25 Mar 2017 10:36:29 +0800 [thread overview]
Message-ID: <CAPG2z0_Z8CQZj0Obchu7H262WHkuxYpVnghRkmiZJt+X7NZF7g@mail.gmail.com> (raw)
In-Reply-To: <20170324183637.GI17319@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
I tested a full-symbol version and found that tar segfaulted due to 'argp'.
Tar is using its own internal implementation of argp, instead of linking to
the one most musl-based distros are using - argp-standalone. In other
words, that internal implementation is not compatible with musl and there's
no actual bug in tar.
I am satisfied with add -largp, but one more question: what's the reason
for not adding argp to musl? I can understand execinfo is hard to add (from
mail)and fts is waiting for changes of API(in wiki). They're not portable
for adding, so what's wrong with argp then? I did not find any mail related
to this question. And I am sorry if i missed anything.
He X
2017-03-25 2:36 GMT+08:00 Rich Felker <dalias@libc.org>:
> On Thu, Mar 23, 2017 at 01:05:55PM +0800, He X wrote:
> > Hi, rich, happy that you merged the changes related to dcngettext(). But
> > you seems forget this simple patch and did not get it with those changes.
> > So i bump it again now. Hope you do not mind if you still remember it.
> >
> > He X
> >
> > 2017-03-04 16:08 GMT+08:00 He X <xw897002528@gmail.com>:
> >
> > > following http://www.openwall.com/lists/musl/2017/02/13/8 ,
> > > http://www.openwall.com/lists/musl/2017/03/04/1 and
> > > http://www.openwall.com/lists/musl/2017/02/13/5:
> > >
> > > > gnu tar showed me segfaults, because he passed a zero msgid1 causing
> > > __mo_lookup segfault, we should add a check in dcngettext to avoid
> it(if
> > > (!msgid1) goto notrans;):
> > >
> > > #2 0x00007ffff7d82a6f in dcngettext (domainname=0x6737a0 "tar",
> > > msgid1=0x0, msgid2=0x0, n=1,
> > > category=5) at src/locale/dcngettext.c:211
>
> Indeed, I did forget. But looking at it more closely, according to the
> GNU gettext manual I think this is a bug in GNU tar:
>
> "If the argument is NULL the result is undefined."
>
> https://www.gnu.org/software/gettext/manual/html_node/
> Interface-to-gettext.html
>
> Whether we commit this patch or not, I think it should be reported as
> a bug in GNU tar.
>
> Given that the API documentation says a NULL pointer is not valid
> here, my leaning, in alignment with existing musl practice, is _not_
> to make it silently "work" but to leave it crashing, so that this sort
> of bug is caught. But if the documentation is wrong and the practice
> of passing null pointers here is widely accepted we can reconsider.
>
> Rich
>
[-- Attachment #2: Type: text/html, Size: 3582 bytes --]
prev parent reply other threads:[~2017-03-25 2:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 8:08 He X
2017-03-23 5:05 ` He X
2017-03-24 18:36 ` Rich Felker
2017-03-25 2:36 ` He X [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPG2z0_Z8CQZj0Obchu7H262WHkuxYpVnghRkmiZJt+X7NZF7g@mail.gmail.com \
--to=xw897002528@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).