Define and document the safe PL_str functions

Assigned to


16 years ago
11 years ago


(Reporter: Wan-Teh Chang, Assigned: Wan-Teh Chang)


Firefox Tracking Flags

(Not tracked)




16 years ago
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


16 years ago
Severity: normal → enhancement
Priority: -- → P1
Target Milestone: --- → 4.3
Version: other → 4.2

Comment 1

16 years ago
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

- 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

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

16 years ago
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

16 years ago
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.


15 years ago
Priority: P1 → P2
QA Contact: wtchang → nspr

Comment 4

11 years ago
The target milestone is already released. Resetting target milestone.
Target Milestone: 4.3 → ---
You need to log in before you can comment on or make changes to this bug.