156324 - Define and document the safe PL_str functions

Status: NEW

(NSPR :: NSPR, enhancement)

Description

[Wan-Teh Chang]

The MSDN Flash newsletter just announced the new Strsafe functions
for Windows.  I'd like to review the PL_str API and make sure that
we have equivalent safe PL_str functions that handle buffers properly.
Moreover, these safe PL_str functions should be documented in the
NSPR Reference.

The Windows Strsafe functions are documented at
http://msdn.microsoft.com/library/en-us/dnsecure/html/strsafe.asp.

Comment 1

[Roger Chickering]

Here's what we don't have:

- an equivalent of StringCchCatN, which takes two limits: the size of the
  buffer, and the maximum number of chars to copy.  I've never missed this
  one.

- wide character versions of the PL_str functions.  Microsoft deals with
  wide characters by having StringCb versions of all of its String functions,
  where the limit passed in is in bytes instead of characters.  PL_str
  functions only operate on 8 bit characters, so size in bytes and size
  in characters are the same.

I don't see a need for wide character versions of the PL_str functions, but
that's because I'm not doing anything with wide characters; I'm using
multibyte characters instead which should work fine with the PL_str
functions.

As far as I am concerned, you could document the PL_str functions (actually,
I think the documentation in plstr.h is pretty adequate) and call this
bug fixed

Comment 2

[Wan-Teh Chang]

Thank you for the analysis, Roger.

We don't have an equivalent of StringCchCopyN either, but
this function isn't that useful.

Do you think we should recommend replacing strlen and
PL_strlen by PL_strnlen (the equivalent of StringCchLength)?
It seems that the value of PL_strnlen and StringCchLength
is in performance rather than safety if all the strings are
constructed with the safe string functions.

Comment 3

[Roger Chickering]

I don't think we should recommend the use of PL_strnlen over strlen.  
As you point out, if you use safe string methods that always result 
in 0 terminated strings such as PL_strncpyz and PL_strcatn, you don't 
have to worry about running off the end of a string in a call to strlen.

I think any performance benefit from PL_strnlen should be considered
entirely separate from a security analysis, and applied only where
it has a significant impact rather than broadly across the code base.

Comment 4

[Christophe Ravel]

The target milestone is already released. Resetting target milestone.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months and this bug has priority 'P2'.
:KaiE, could you have a look please?
For more information, please visit auto_nag documentation.