NS_NewPipe with default segment size ignores max size

RESOLVED FIXED

Status

()

Core
Networking
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: jhp (no longer active), Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
From bug 315767:

Darin: "The problem is that we were passing 0 for the segmentSize of
the pipe, which causes the pipe to use its default configuration, ignoring the
value of maxSize passed to it.  The real fix to this bug is to change
NS_NewPipe to honor maxSize even when segmentSize is 0."
(Reporter)

Comment 1

12 years ago
Created attachment 215289 [details] [diff] [review]
patch

Moved the NS_NewPipe impl code out of the IDL file and into nsPipe3.cpp, so it can use the DEFAULT_SEGMENT_SIZE define.  I also special cased maxSize == PR_UINT32_MAX to pass a segmentCount of PR_UINT32_MAX, since in both cases this means "infinite", according to the docs.
Attachment #215289 - Flags: review?(darin)
(Reporter)

Comment 2

12 years ago
Hmm, this patch would break any embedders who are using this API, right?  How much does that matter, considering that it's not frozen?

Comment 3

12 years ago
No worries there.  The symbol is only exported by libxpcom_core.so, which doesn't even exist in a xulrunner build.

Comment 4

12 years ago
Comment on attachment 215289 [details] [diff] [review]
patch

Please add this new function to xpcom/build/dlldeps.cpp to avoid breaking the windows build :)
Attachment #215289 - Flags: review?(darin) → review+
(Reporter)

Comment 5

12 years ago
Checked in to trunk.  -> FIXED

Darin, do you think this needs to go on the 1.8 branch?
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 6

12 years ago
No, let's only put it on the 1.8 branch if there is a need.  People can work around this bug.
You need to log in before you can comment on or make changes to this bug.