FTBFS on Hurd

Dirk Hohndel dirk at hohndel.org
Wed Aug 27 07:15:16 PDT 2014

On Wed, Aug 27, 2014 at 02:49:46PM +0200, Salvo Tomaselli wrote:
> In data mercoledì 27 agosto 2014 14:12:41, Lubomir I. Ivanov ha scritto:
> > for the Win32 API and NTFS MAX_PATH actually makes sense, for POSIX
> > PATH_MAX from limits.h, not so much.
> > to what exact area of subsurface are you referring to - is it
> > subsurfacewebservices.cpp by any chance?
> Yes, I used git grep and it seems the only occurrence of that.
> I am not aware of the windows complications because I've never written any C 
> that was supposed to run on windows in my life.

You and me both. It's scary to be maintaining a project with 60+% of its
users running on Windows and at the same time having NO CLUE about
Windows... :')

> > anything past 259 bytes might be a bit weird. it's a filepath more
> > than 3 times the width of a terminal screen in ASCII or ~128
> > characters of 2byte unicode origin.
> > a growing buffer could be optional at places, but i don't see it as
> > crucial for most cases.
> Well consider that currently on linux it allocates 4096 bytes for a filepath, 
> which is a bit huge.

I'd say it's sufficient and given the memory use overall it makes no

> So do you think that just adding a define would be okay?
> In any case the snprintf doesn't check the return value at the moment so the 
> string might be truncated, but with such a huge limit is quite unlikely.

Is there a reason you can't use something like 4096? I have no experience
with Hurd, either, so I'm not sure if there is a reason that would be a
bad idea.

In my mind anyone who uses a file path with more than 2000 characters gets
what they deserve...


More information about the subsurface mailing list