develooper Front page | perl.perl5.porters | Postings from January 2019

Re: [perl #133760] Please define _GNU_SOURCE unconditionally onLinux to make memmem() available

Thread Next
From:
Luis Ressel
Date:
January 12, 2019 21:19
Subject:
Re: [perl #133760] Please define _GNU_SOURCE unconditionally onLinux to make memmem() available
Message ID:
20190112011742.0f4080fc@vega.skynet.aixah.de
On Thu, 10 Jan 2019 18:14:38 -0800
"James E Keenan via RT" <perlbug-followup@perl.org> wrote:

> How can I safely test this behavior?

You can't just install musl on a system that uses a different libc;
it'd pave over essential components of that other libc. Your best bet
is to download an image of a distro that uses musl (for example
https://alpinelinux.org/, that's only a few 100 MB large), and run that
in a VM or from a USB drive.

> > Please define _GNU_SOURCE unconditionally to fix this issue.
> >   
> 
> My initial reaction:  That's overkill.  We should detect 'musl' first
> and only then extend use of _GNU_SOURCE.
> 
> But this is not an area of expertise for me, so others should comment.

I disagree. glibc too only defines memmem() conditionally (#ifdef
__USE_GNU, which itself is enabled under various circumstances, for
example if _GNU_SOURCE is defined). That Perl currently works on glibc
systems is pure luck (__USE_GNU is probably already defined for other
reasons), and this might change at any time.

The glibc manpage for memmem() even explicitly states that you should
define _GNU_SOURCE if you're using it. Considering that this is a very
ugly bug, which doesn't show itself during build time, but
silently corrupts data at runtime, I'd strongly recommend to enable
_GNU_SOURCE for both musl and glibc.

Thanks a lot!

Luis Ressel

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About