From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112484 invoked by alias); 31 Dec 2016 15:36:35 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 109092 invoked by uid 48); 31 Dec 2016 15:36:22 -0000 From: "mjw at redhat dot com" To: elfutils-devel@sourceware.org Subject: [Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name Date: Sat, 31 Dec 2016 15:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: general X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mjw at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2016-q4/txt/msg00031.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D21009 Mark Wielaard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjw at redhat dot com --- Comment #1 from Mark Wielaard --- (In reply to Luiz Angelo Daros de Luca from comment #0) > However, there seems to be some limitation on realpath: >=20 > https://mail.gnome.org/archives/gtk-devel-list/2002-October/msg00197.html I assume that refers to this: BUGS The POSIX.1-2001 standard version of this function is broken by desi= gn, since it is impossible to determine a suitable size for the out= put buffer, resolved_path. According to POSIX.1-2001 a buffer of s= ize PATH_MAX suffices, but PATH_MAX need not be a defined constant, and = may have to be obtained using pathconf(3). And asking pathconf(3) does = not really help, since, on the one hand POSIX warns that the result = of pathconf(3) may be huge and unsuitable for mallocing memory, and on = the other hand pathconf(3) may return -1 to signify that PATH_MAX is = not bounded. The resolved_path =3D=3D NULL feature, not standardi= zed in POSIX.1-2001, but standardized in POSIX.1-2008, allows this des= ign problem to be avoided. Even old glibc versions (at least 2.5+) implemented the resolved_path =3D= =3D NULL=20 feature. So I think we can assume any recent glibc alternative also has thi= s. > If autoconf checks for it, we could simply define a macro for it when > canonicalize_file_name is not present like: >=20 > #ifndef HAVE_canonicalize_file_name > #define canonicalize_file_name(name) realpath(name,NULL) > #endif >=20 > This function is used only at: >=20 > ./libdwfl/find-debuginfo.c:388 > ./libdwfl/dwfl_build_id_find_elf.c:98 >=20 > And both include system.h. So, the best place to conditionally define it > might be system.h. >=20 > What's the correct approach? change the call or conditionally define a new > macro? I think we can assume everybody uses glibc or a modern alternative that alr= eady implements the resolved_path =3D=3D NULL feature. So I would simply change = the two callers of canonicalize_file_name (name) to realpath (name, NULL). --=20 You are receiving this mail because: You are on the CC list for the bug.