[MPlayer-dev-eng] [PATCH 2/7] Use Proxy-Authorization instead of Authorization for proxy auth
ubitux at gmail.com
Wed Nov 17 08:38:36 CET 2010
On Wed, Nov 17, 2010 at 08:23:21AM +0100, Reimar Döffinger wrote:
> On Wed, Nov 17, 2010 at 12:21:20AM +0100, Clément Bœsch wrote:
> > On Tue, Nov 16, 2010 at 10:12:58PM +0100, Reimar Döffinger wrote:
> > > Well, while it's very unlikely to be a _new_ issue with this patch,
> > > to review it properly I'd still have to check that the addition
> > > will not cause an integer overflow.
> > Changing encoded_len type from int to size_t may help?
> Maybe. Why not just use the solution that does not require thinking?
It's not really a matter of thinkink, I was just changing the current
code without changing the allocation procedure because it's not the
purpose of the patch.
> > > And the CPU (and honestly more code complexity) is something I just consider
> > > because, honestly, I can't see much of a point in using a "100 % correct"
> > > number.
> > Not sure I get what you mean. Anyway, I still find the allocation
> > procedure more appropriated, and I just updated the current code.
> The value is wrong anyway due to using encoded_len instead of out_len.
> I am say that calculating the precise value to allocate is a waste
> of developing, review and maintainance effort when all you need is
> a value >=.
> In addition having an extra malloc there is quite stupid, it should
> be something like
> encoded_len += 100;
> b64_usr_pass = malloc(encoded_len);
> av_strlcpy(b64_usr_pass, authstr);
> but maybe it's better to just leave that for later.
I have a pending patch (not yet sent) to change the current base64_encode
with call to FFmpeg one, and that code will need to be changed so yes, I
think it's better to leave it for later.
Not sent from a jesusPhone.
More information about the MPlayer-dev-eng