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 difference. > 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... /D _______________________________________________ subsurface mailing list subsurface@hohndel.org http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface