[Vm-dev] Re: [Pharo-users] issue with large file path on windows
btc at openinworld.com
Mon Aug 24 17:59:32 UTC 2015
On Mon, Aug 24, 2015 at 8:44 PM, Nicolai Hess <nicolaihess at web.de> wrote:
> 2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johansen at veloxit.no>:
>> On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess at web.de> wrote:
>> And If you want to review the changes:
>> 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess at web.de>:
>>> For those who had problems with pharo on windows and github based
>>> I built a windows vm with support for long paths:
>>> For browsing directories with large paths (FileList or Inspect),
>>> you may need one additional change in the image (But I am not really
>>> sure about that) :
>>> super initialize.
>>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].
>>> please test and give feedback.
>>> This wasn't as easy as I thought, and I had to make some more changes
>>> for the file permissions (the stat-functions don't work for files with
>>> long paths).
>>> Please test other file/folder operations.
>> - Is an alloca version really worth it for the potential problems?
> It is what Marcel used for the long path support in the squeak vm (I would
> have copy and paste the whole change, but I couldn't find the appropriate
> change for directory functions).
"Potential problems" sounded like something interesting I could learn.
Here is a summary...
On the use and abuse of alloca
* alloca five times faster than malloc (but is that necessary given file
operations likely take longer anyway?)
* most concerns with alloca no problem here e.g. its a very short
lifespan; the pointer is not returned from the function.
The Perils of alloca()
* remaining concern is potential stack exhaustion...
* is MAX_LONG_FILE_PATH=32kB significant today (but also consider
embedded application) ?
* counter argument, primitive functions are not likely to entered
Microsoft advises alloca  deprecated in favour of malloca  which
allocates either stack or heap depending on requested size
An example of a DIY malloca...
* might have the advantage of tuning MAX_ALLOCA_CUTOFF post-compilation
* minGW gcc might not have malloca
* if large allocations go on the heap, maybe MAX_LONG_FILE_PATH test not
required, just MAX_ALLOCA_CUTOFF
btw, perhaps rename CONVERT_MULTIBYTE_TO_WIDECHAR_PATH
to ALLOC_WIDECHAR_PATH_FROM_MULTIBYTE or similar
so its more obviously symmetrical with FREE_WIDECHAR_PATH.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev