Some patches to please Debian 💯️

[illwieckz]

The Debian package applies two patches by @twolife:

• https://udd.debian.org/patches.cgi?src=crunch-dxtc&version=0.56.2-1

So we better have the fixes upstream and them not having to apply any patch.

The first patch, I totally rewrote it to be much more generic.
The second patch, I simply added the initialization of *p to nullptr to the original patch.

I reworded the commit messages in better ways.

For knowledge, the need for those patches were triggered by Debian Hurd… We don't support that, but the actual patches are generic clean-up and improvements that are always good to have. Especially it removes one ifdef for FreeBSD and makes the code use a more modern version of realpath().

So in the end the code is in better shape and even has less system-specific branches: more portable with less branches.

[twolife]

Hi,
Usually I don't like to bother people with patches for Hurd (this is a toy project IMHO); but as you pointed out, in this case the resulting code is better and more portable.
Thank you for taking the time to merge theses patches !

[slipher]

realpath one seems suspicious. Apple's man page doesn't say anything about a null buffer being allowed.

[illwieckz]

Bruh… is this 32 years old ?

February 16, 1994 

So did we found something in macOS that is even older than their bash from 2007 and their make from 2006 ? 💀️

In comparison the FreeBSD man page:

RETURN VALUES
     On success, the realpath() function returns resolved_path	if  it	was  not
     NULL,  or	a pointer to a null-terminated string which must be freed by the
     caller if it was.

STANDARDS
     The realpath() function conforms to IEEE Std 1003.1-2001 ("POSIX.1").

March 18, 2026

And the Linux man page:

DESCRIPTION
       If resolved_path is specified as NULL, then realpath() uses
       malloc(3) to allocate a buffer of up to PATH_MAX bytes to hold the
       resolved pathname, and returns a pointer to this buffer.  The
       caller should deallocate this buffer using free(3).

STANDARDS

      POSIX.1-2008.

HISTORY

       4.4BSD, POSIX.1-2001, Solaris.

       POSIX.1-2001 says that the behavior if resolved_path is NULL is
       implementation-defined.  POSIX.1-2008 specifies the behavior
       described in this page.

So both Linux and FreeBSD implement POSIX.1-2008, just FreeBSD doesn't mention that version, but describe the standardized behavior.

I found this page:

• https://cloudstreet-dev.github.io/macOS-and-Unix/part1-foundations/posix-compliance.html

It says:

macOS’s UNIX 03 certification means it has passed The Open Group’s test suite demonstrating compliance with:

    Single UNIX Specification version 3 (SUS v3)
    POSIX.1-2001
    Related standards

You can verify this:

# Check POSIX version supported
$ getconf _POSIX_VERSION
200112

# Check UNIX version (SUS)
$ getconf _XOPEN_VERSION
600

Some people are even doubting that macOS is an Unix (Apple’s macOS UNIX certification is a lie):

I can guarantee you with 100% certainly not a single macOS installation in the entire history of macOS.
--- https://www.osnews.com/story/141633/apples-macos-unix-certification-is-a-lie/

Though half of the things (maybe more) to do to make it matches the certification, I wouldn't want them, and you must not do them (and that's would be too old, what we don't want).

So if their Unix certification isn't one, what about their POSIX conformance ?

Well, actually, if they do follow POSIX.1-2001 and no more, then, according to what said FreeBSD: “the behavior if resolved_path is NULL is implementation-defined.”.

Damn, we're in BIG 2026 and macOS is still stuck on POSIX.1-2001??? That's not 1994, but that's still 25 years old…

macOS brings so much pain, has painful ergonomy and is so painful to develop for…

[illwieckz]

This is said to be a copy of macOS man page from macOS 10.12.0, as hosted by FreeBSD:

• https://man.freebsd.org/cgi/man.cgi?query=realpath&apropos=0&sektion=3&manpath=macOS+10.12.0&format=html

It says:

DESCRIPTION]
     As a permitted extension to the standard, if resolved_name is NULL,  memory
     is  allocated for the resulting absolute pathname, and is returned by real-
     path().  This memory should be freed by a call to free(3)	when  no  longer
     needed.

This copy of the macOS man page from macOS 26.5.2 says the same:

• https://man.freebsd.org/cgi/man.cgi?query=realpath&apropos=0&sektion=3&manpath=macOS+26.5.2&format=html

In this Mozilla Bugzilla, someone named timeless says 16 years ago

:(, it turns out this is a 10.6 feature, and some of our boxes are 10.5.
-- https://bugzilla.mozilla.org/show_bug.cgi?id=550463#c5

[illwieckz]

Here is the man page copied straight from a macOS Tahoe, and it's dated from 2008, and it describes the behavior for POSIX 2008 (while not naming any standard):

REALPATH(3)                Library Functions Manual                REALPATH(3)

NAME
     realpath – returns the canonicalized absolute pathname

SYNOPSIS
     #include <stdlib.h>

     char *
     realpath(const char *restrict file_name, char *restrict resolved_name);

DESCRIPTION
     The realpath() function resolves all symbolic links, extra “/”
     characters, and references to /./ and /../ in file_name.  If the
     resolved_name argument is non-NULL, the resulting absolute pathname is
     copied there (it must refer to a buffer capable of storing at least
     PATH_MAX characters).

     As a permitted extension to the standard, if resolved_name is NULL,
     memory is allocated for the resulting absolute pathname, and is returned
     by realpath().  This memory should be freed by a call to free(3) when no
     longer needed.

     The realpath() function will resolve both absolute and relative paths and
     return the absolute pathname corresponding to file_name.  All components
     of file_name must exist when realpath() is called.

RETURN VALUES
     On success, the realpath() function returns the address of the resulting
     absolute pathname, which is resolved_name if it was non-NULL, or the
     address of newly allocated memory.  If an error occurs, realpath()
     returns NULL.  If resolved_name was non-NULL, it will contain the
     pathname which caused the problem.

VARIANTS
     Defining _DARWIN_C_SOURCE or _DARWIN_BETTER_REALPATH before including
     stdlib.h will cause the provided implementation of realpath() to use
     F_GETPATH from fcntl(2) to discover the path.

ERRORS
     The function realpath() may fail and set the external variable errno for
     any of the errors specified for the library functions alloca(3),
     getattrlist(2), getcwd(3), lstat(2), readlink(2), stat(2), and strdup(3).

LEGACY SYNOPSIS
     #include <sys/param.h>
     #include <stdlib.h>

     The include file <sys/param.h> is necessary.

LEGACY DESCRIPTION
     In legacy mode, the last component of file_name does not need to exist
     when realpath() is called.

SEE ALSO
     free(3), getcwd(3), compat(5)

HISTORY
     The realpath() function first appeared in 4.4BSD.

macOS 26.5                       April 5, 2008                      macOS 26.5

[illwieckz]

So it looks like the man page linked from the Apple website is obsolete. The NULL argument is supported since a lot of time. That's a very good news, as macOS not being obsolete isn't always something we can expect…

[slipher]

LGTM