On 03/20/2013 18:02, Miller Puckette wrote:
On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc.
yep. that's why i said that the only real solution would be to provide a more-or-less complete set of fileIO-functions: sys_lseek, sys_stat (including f-variants).
I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms.
which would be possible if we provided the full set. of file accessors. (but to repeat, this is not really a Pd-problem, and could (and maybe should) be solved in an auxiliary lib).
For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3).
which i think is a good enough approach. but of course there's a catch: sys_open() will gracefully handle UTF-8 filenames, whereas on some platforms open() will not. so with your solution, soundfiles with non-ascii chars will fail to open on W32.
since open_via_path() is so often used to determine the full path of a file somewhere in the searchpath, it might be a good idea to wrap that functionality into a find_via_path() function that returns the canonicalized filename. it would be great if that filename would be mangled in a way so UTF8 doesn't make problems any more, but i think this is simply not possible with the way w32 handles opening such filenames.
fgmadsr IOhannes