GNOME Bugzilla – Bug 764817
[PATCH] Fix build on Hurd (because of PATH_MAX)
Last modified: 2016-04-14 21:32:03 UTC
Created attachment 325635 [details] [review] Git commit gegl does not build on GNU/Hurd since version 0.3.0; this is due to PATH_MAX used, which is optional in POSIX and not provided on purpose on GNU/Hurd. The actual issue is that PATH_MAX is used to build a static sized buffer for realpath -- it is possible to use the POSIX.1-2008 behaviour of it, passing null as second parameter so it returns the result as new buffer. This also reverts commits 5d715eee845ef1ab30490259a114902d0b6533ed, since it considered realpath(buf, NULL) as GNU extension, while it really is POSIX.
from the man page: <quote> 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). </quote> I think that using g_free is wrong (see for example the comment in bin/gegl.c)
Why do we fiddle with such libc functions at all? Is resolved_path() (as in without symlinks) really needed here? I doubt it. Let's simply create a GFile from the passed path right away and then use g_file_get_path() which is guaranteed to return an absolute path, on all platforms. Let GIO handle all the platform stuff, that's what it's supposed to do.
resolved - as in without symlinks, not only turned into an absolute path without ../ or other relative components is indeed necessary transformation of input provided to both ffmpeg, libpng and probably other c based loaders.
Created attachment 326053 [details] [review] Git commit
commit 594b2fae9c96981428e8fd9e2cd6198221f814f3 Author: Pino Toscano <toscano.pino@tiscali.it> Date: Thu Apr 14 23:19:03 2016 +0200 Use modern realpath() everywhere Assume everywhere that the realpath() implementation has the POSIX.1-2008 behaviour, i.e. allowing NULL as second parameter and thus returning a newly allocated buffer; it is not just a GNU extension. Also, this behaviour was assumed in other parts of gegl, so there should be no regression. This commit also reverts commit 5d715eee845ef1ab30490259a114902d0b6533ed.