FTBFS on Hurd

[Lubomir I. Ivanov]

On 27 August 2014 15:49, Salvo Tomaselli <tiposchi at tiscali.it> 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.
>

it makes sense not because of the NTFS as a design, but mostly because
of legacy C implementations in the Win32 API.
MAX_PATH is used everywhere in there and i assume the Qt related
wrappers are bound to it as well.
(...and unless they use the "\\?\" trick that is.)

>
>> 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.
>
> 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.

in my opinion this would suffice in subsurfacewebservices.cpp:

#ifndef PATH_MAX
#define PATH_MAX 260
#endif

the webservices codes potentially can write files to weird paths but
we are yet to encounter a user complain of sorts.
for instance on Win32, if the user has defined somehow his TEMP path
or USER path to be very weird and long, not only Subsurface will
brake, but even older Microsoft products like MS Office <Version>.

lubomir
--