[Patch #2994165] Change signature of Tcl_FSGetNativePath and TclpDeleteFile

1 files changed, 9 insertions, 10 deletions

diff --git a/doc/FileSystem.3 b/doc/FileSystem.3
index bc52214..d53fccc 100644
--- a/doc/FileSystem.3
+++ b/doc/FileSystem.3
@@ -5,7 +5,7 @@
 '\" See the file "license.terms" for information on usage and redistribution
 '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
 '\" 
-'\" RCS: @(#) $Id: FileSystem.3,v 1.71 2010/04/04 15:03:07 dkf Exp $
+'\" RCS: @(#) $Id: FileSystem.3,v 1.72 2010/08/14 17:13:02 nijtmans Exp $
 '\" 
 .so man.macros
 .TH Filesystem 3 8.4 Tcl "Tcl Library Procedures"
@@ -139,7 +139,7 @@ const char *
 Tcl_Obj *
 \fBTcl_FSNewNativePath\fR(\fIfsPtr, clientData\fR)
 .sp
-const char *
+const void *
 \fBTcl_FSGetNativePath\fR(\fIpathPtr\fR)
 .sp
 Tcl_Obj *
@@ -742,14 +742,13 @@ a UTF-8 string representation if that is required by some Tcl code.
 \fBTcl_FSGetNativePath\fR is for use by the Win/Unix native
 filesystems, so that they can easily retrieve the native (char* or
 TCHAR*) representation of a path. This function is a convenience
-wrapper around \fBTcl_FSGetInternalRep\fR, and assumes the native
-representation is string-based. It may be desirable in the future to
-have non-string-based native representations (for example, on MacOSX, a
-representation using a fileSpec of FSRef structure would probably be
-more efficient). On Windows a full Unicode representation would allow
-for paths of unlimited length. Currently the representation is simply a
-character string which may contain either the relative path or a
-complete, absolute normalized path in the native encoding (complex
+wrapper around \fBTcl_FSGetInternalRep\fR. It may be desirable in the
+future to have non-string-based native representations (for example,
+on MacOSX, a representation using a fileSpec of FSRef structure would
+probably be more efficient). On Windows a full Unicode representation
+would allow for paths of unlimited length. Currently the representation
+is simply a character string which may contain either the relative path
+or a complete, absolute normalized path in the native encoding (complex
 conditions dictate which of these will be provided, so neither can be
 relied upon, unless the path is known to be absolute). If you need a
 native path which must be absolute, then you should ask for the native