Bommels05/Mozilla
Bommels05/Mozilla
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
49,926 Commits 3,986 Branches 0 Tags
Commit Graph

13 Commits

Author SHA1 Message Date
jefft%netscape.com
6d0a1b30c9 fixed bug 21417 - [Performance] nsMsgLineStreamBuffer use PL_strlen to determine how many bytes left in the buffer; eliminate using PL_strlen() to speed up the performance; r=mscott, bienvenu; a=chofmann 
git-svn-id: svn://10.0.0.236/trunk@56230 18797224-902f-48f8-a5cc-f745e15eee43
 1999-12-20 14:58:05 +00:00
dmose%mozilla.org
0efb7c174c updated xPL license boilerplate to v1.1, a=chofmann@netscape.com,r=endico@mozilla.org 
git-svn-id: svn://10.0.0.236/trunk@52910 18797224-902f-48f8-a5cc-f745e15eee43
 1999-11-06 03:43:54 +00:00
mscott%netscape.com
899ebce13b Bug #16814 --> i found a problem which may be causing us to block in the imap protocol when downloading larger 
attachments or images. Basically, the nsMsgLineStreamBuffer class had a fence post bug when determining
if it had enough room to read in more bytes. If the # of free bytes in the stream buffer was 1 byte and we
had just one byte of data left to read in from the incoming stream, we would fail to read in that one byte.
r=sspitzer


git-svn-id: svn://10.0.0.236/trunk@51292 18797224-902f-48f8-a5cc-f745e15eee43
 1999-10-20 21:01:58 +00:00
putterman%netscape.com
9dbd192f71 Use ctor/dtor counter macros on non xpcom classes. reviewed by mscott. no bug. 
git-svn-id: svn://10.0.0.236/trunk@50330 18797224-902f-48f8-a5cc-f745e15eee43
 1999-10-10 22:32:54 +00:00
warren%netscape.com
de60d2685c Removed NS_BASE_STREAM_EOF in favor of returning a count of 0 from Read to indicate EOF. Renamed GetLength to Available. Fixed a number of places where AppendElement's broken error code wasn't checked. 
git-svn-id: svn://10.0.0.236/trunk@46637 18797224-902f-48f8-a5cc-f745e15eee43
 1999-09-09 22:05:05 +00:00
alecf%netscape.com
4aa767d9b0 switch to nsCRT routines and PR_TRUE/PR_FALSE to reduce include dependancy 
git-svn-id: svn://10.0.0.236/trunk@46281 18797224-902f-48f8-a5cc-f745e15eee43
 1999-09-08 03:08:27 +00:00
sspitzer%netscape.com
de502ae869 fix for #9896. make nsMsgLineBuffer work for buffers that use CR, LF, and CRLF. (before, only CRLF and LF worked.) the mac uses CR, and we'd lose the last line of the newsrc file. 
git-svn-id: svn://10.0.0.236/trunk@40982 18797224-902f-48f8-a5cc-f745e15eee43
 1999-07-24 18:15:19 +00:00
mscott%netscape.com
6f4da8e339 Use MSG_LINEBREAK instead of LINEBREAK. 
git-svn-id: svn://10.0.0.236/trunk@29363 18797224-902f-48f8-a5cc-f745e15eee43
 1999-04-27 03:06:34 +00:00
mscott%netscape.com
f3bdda604d nsMsgLineStreamBuffer::ReadNextline now returns # bytes read. 
nsMsgLineStreamBuffer now lets you pass in the delimeter string to be used for determing the end of a line. This allows the function to be platform friendly with line endings...


git-svn-id: svn://10.0.0.236/trunk@29126 18797224-902f-48f8-a5cc-f745e15eee43
 1999-04-25 19:51:08 +00:00
mscott%netscape.com
56bebb25c7 Fix fence post case in nsMsgLineBufferStream::ReadNextLine when we read n bytes and n == the size of the buffer...we were over-writing the n+1th byte with a null terminator. 
Add (unimplemented) feature to nsMsgLineBufferStream to give caller the choice of allocating new memory for new lines or not.


git-svn-id: svn://10.0.0.236/trunk@28604 18797224-902f-48f8-a5cc-f745e15eee43
 1999-04-22 01:53:19 +00:00
mscott%netscape.com
851f1890b8 for nsMsgLineStreamBuffer, let caller choose if they want CRLFs at the end of the new lines or not. 
git-svn-id: svn://10.0.0.236/trunk@28372 18797224-902f-48f8-a5cc-f745e15eee43
 1999-04-20 23:44:34 +00:00
mscott%netscape.com
ff42292739 add new class nsMsgLineStreamBuffer which is used to efficiently read out lines from an input stream by buffering unprocessed content in a buffer. 
git-svn-id: svn://10.0.0.236/trunk@27928 18797224-902f-48f8-a5cc-f745e15eee43
 1999-04-16 22:05:33 +00:00
alecf%netscape.com
3f6df41daf move files over from src into linkable library 
git-svn-id: svn://10.0.0.236/trunk@24486 18797224-902f-48f8-a5cc-f745e15eee43
 1999-03-19 22:55:08 +00:00