GNOME Bugzilla – Bug 642783
CamelLocalFolder: Let glibc's realpath() allocate for us
Last modified: 2011-03-08 18:10:05 UTC
Hi, PATH_MAX is not portable, as it's not mandated by POSIX. The attached patch uses dynamic allocation instead (realpath will allocate the necessary memory). I haven't been able to test it because git master requires some newer stuff I don't have yet.
Created attachment 181366 [details] [review] Don't use PATH_MAX for portability reasons
realpath() doesn't allocate memory. You still have to pass it a buffer, and you still need PATH_MAX to know how large to make the buffer. The POSIX documentation [1] hints that some implementations might return allocated memory if given a NULL buffer, but relying on this behavior is no more portable than using PATH_MAX. If you can find a more portable workaround I'll consider it. GLib or GIO might offer something similar. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/realpath.html
POSIX 2008 defines this behaviour: " If resolved_name is a null pointer, the generated pathname shall be stored as a null-terminated string in a buffer allocated as if by a call to malloc(). " http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html
Created attachment 182300 [details] [review] Only use realpath(foo, NULL) when building with GNU libc OK, how about this? glibc implements the POSIX.2008 behaviour, so it's fine, and we keep the PATH_MAX way for other platforms.
That looks good enough for now. There's an old GLib enhancement request for this type of issue in bug #111848. It's been getting some attention lately so maybe it will land soon and we can clean out all the messy #ifdef's.
Patch committed (with a few comments added) for 2.91.92: http://git.gnome.org/browse/evolution-data-server/commit/?id=b60d2b8f74702cfa26e24ed67dede58fb9aabddc
Thanks. The glib function would be useful here indeed.