[Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name

["mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21009

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to Luiz Angelo Daros de Luca from comment #0)
> However, there seems to be some limitation on realpath:
> 
> 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 design,
       since it is impossible to determine a  suitable  size  for  the  output
       buffer,  resolved_path.   According  to  POSIX.1-2001  a buffer of size
       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 == NULL  feature,  not  standardized  in
       POSIX.1-2001, but standardized  in  POSIX.1-2008,  allows  this  design
       problem to be avoided.

Even old glibc versions (at least 2.5+) implemented the resolved_path == NULL 
feature. So I think we can assume any recent glibc alternative also has this.

> If autoconf checks for it, we could simply define a macro for it when
> canonicalize_file_name is not present like:
> 
> #ifndef HAVE_canonicalize_file_name
> #define canonicalize_file_name(name) realpath(name,NULL)
> #endif
> 
> This function is used only at:
> 
> ./libdwfl/find-debuginfo.c:388
> ./libdwfl/dwfl_build_id_find_elf.c:98
> 
> And both include system.h. So, the best place to conditionally define it
> might be system.h.
> 
> 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 already
implements the resolved_path == NULL feature. So I would simply change the two
callers of canonicalize_file_name (name) to realpath (name, NULL).

-- 
You are receiving this mail because:
You are on the CC list for the bug.