Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> Yes, but we already have this one in config.h. If you have no other
> objection, I can add that.
I have no other "objection". It was not even an objection before. I
was just being lazy (in the bad sense) and you see, it worked!
Jan
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> char LinkBuffer[512];
> // Should be PATH_MAX but that needs autconf support
>
> What autoconf support do you need?
The code snippet you quoted from GNU fileutils has the inclusion of
limits.h wrapped in an HAVE_LIMITS_H
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> it. A question: is there a particular reason why you named the new
> function LyXReadLink? Would ReadLink cause a particular problem? [just
> that the other functions in filetools do not use that prefix]
Not really apart from the fact that I dis
.]
>
> In 1.1.x we should rewrite this to use LString.
I am afraid I found it easier to just convert everything to LString now
than to try to add up all the buffer sizes. The Code is much simpler
and cleaner in this way.
Here is the complete patch against vanilla 1.0.0. Do you guys do
Chan
[EMAIL PROTECTED] (Lars Gullik Bj?nnes) writes:
> v> // szBuffer is a 256 byte buffer! BOOM.
>
> And why not enlarge szBuffer to 512.
Note. It needs to contain: Direntry + " -> " + linkpath, so it needs
to be quite some more.
> v> LString szFile;
> v> huh? "sz = char []"?
>
> I don't ge
[EMAIL PROTECTED] (Lars Gullik Bj?nnes) writes:
> yes, perhaps it is safe, but better would be sure that we used posix
> funcs.
It seems to be that the whole symlink concept is not part of posix. It
is however in 4.3 BSD and the single UNIX specification. Which seems
to agree with fileutils, i.
+ LinkBuffer[nRead] = 0;
+ fullbinpath = LinkBuffer;
+ binpath = MakeAbsPath(OnlyPath(fullbinpath));
+ }
+ }
+ } while (FollowLink);
// Hardcoded dir
searchpath += LYX_DIR;
