[PATCH setxkbmap] Eliminate limitations on path length.

[olafBuddenhagen at gmx.net]

Hi,

On Wed, Feb 16, 2011 at 09:07:46AM +0100, Mark Kettenis wrote:
> From: Van de Bugger <van.de.bugger at gmail.com> Date: Wed, 16 Feb 2011
> 00:15:52 +0300

> > ...by using dynamically allocated buffers. No need in PATH_MAX,
> > MAXPATHLEN. No more "Path too long" errors.
> 
> Not really.  Instead fopen(3) will fail and a more cryptic "Didn't
> find" error message will be printed.  There really is very little
> benefit in dynamicaly allocating paths.  All OSes have a fixed maximum
> path length, even the Hurd (contrary to what people claim).

However, that fixed maximum length is not really known at compile time
-- it might change depending on system configuration, or between
versions, or even at runtime, depending on the specific filesystems in
use. In reality, PATH_MAX is just an arbitrary constant with no real
meaning.

Of course there is also the sophisticated pathconfig() interface, where
you can provide a base path, so it can (at least in theory) take
specific filesystem limitations in account. Using that correctly
requires a lot of consideration though. You are still screwed when
constructing a path that crosses mountpoints. And then there can also be
limitations on the length and or number of indidivdual path components.
This really gets insanely complex; trying to check a path length up
front is very nigh impossible to get right.

In short, using dynamic allocation and checking for error returns is
actually the *pragmatic* approach.

-antrik-