Comment 36 for bug 235200

(In reply to comment #6)
> you didn't mean to keep this printf in, right?

oops, indeed not

> so create a new internal API for FTP... or is it the case that the
> nsFTPChannel's mContentLength is only ever used with GetContentLength?

yeah, it is.

> ok, please come up with a better solution for LL_MAXUINT if you don't
> want to simply use it.

I'll use LL_MaxUint() - I was just not aware it existed. bug 245923 filed.

> it also seems like nsUint64 would be handy in some cases, no?

indeed. I was kinda trying to only touch netwerk/ in this patch. Bug 245927
filed; adding dependency for now...

(In reply to comment #7)
> i also saw this code passing 64-bit values to nsITransportEventSink. i guess
> those get silently downcast to 32-bit values.

yes, nsInt64 has an operator PRUint32()

> at some point we need to rev all
> of our progress APIs to work with 64-bit values. my gut feeling is that we'll
> need to preserve existing progress APIs (even though they are not frozen) just
> because of the fact that so many extensions and embedders already use them.
> nsIWebProgressListener is effectively frozen whether we like it or not! :-(

that's unfortunate :( there's always the possibility of nsIWebProgressListener2
of course...