On Sat, Aug 6, 2011 at 7:01 PM, Svante Signell <[email protected]> wrote: > Maybe checking against PATH_MAX is a better idea as I did in the (in > this case needless) wget patch proposal sent earlier to the ML. Do you > propose to use the same test for getcwd part as well?
getcwd() is more complicated because getcwd(NULL, 0) is not specified by POSIX [1], and is not really connected to the availability of PATH_MAX. [1] actually has an example of how to use getcwd() portably without imposing an arbitrary limit, which should work. Using getcwd(NULL, 0) is also a possibility of course, but I would test against __GLIBC__ rather than PATH_MAX to determine its availability (and let the compilation fail if neither __GLIBC__ nor PATH_MAX are defined). Testing for the actual behavior with an autoconf test [2] would be the perfect thing to do, but in my view __GLIBC__ would be an acceptable compromise. Of course, it's ultimately the Debian and upstream maintainer's decision to decide what is acceptable. They're the ones who take responsibility when merging patches, who will have to maintain the code in the long run, and who will have to handle the bug reports if something is wrong with them. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html [2] http://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Tests > So in conclusion: Can we agree that tests can be based on PATH_MAX > existence or not, and skip __GNU__, __GLIBC__ etc constructs? There's no generic rule unfortunately. -- Jérémie Koenig <[email protected]> http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/ca+kcsayzvzvu1rbjaeyek4zrw15ogatht6mimdcm3h_mjry...@mail.gmail.com
