Closed Bug 596405 Opened 14 years ago Closed 14 years ago

Remove scary language from nsIFile target/path

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jduell.mcbugs, Unassigned)

Details

nsIFile.idl contains warnings about the native versions of path/target being potentially unsafe to pass to stdlib/NSPR function (it's silent about the non-native versions, which is confusing).

It sounds like with the demise of OS 9, we can remove the scary language and make it clear that one can safely construct a new nsIFile with a string gotten from GetPath (and also GetNativePath?  Is there a difference now?), and be guaranteed to get the same file.
These warning are correct, and have to do with Windows, not OS9. On Windows some files cannot be represented by a native path, so the only safe way to open them is with a unicode path.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.