FTBFS on Hurd
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
> > 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
In my mind anyone who uses a file path with more than 2000 characters gets
what they deserve...
More information about the subsurface