[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: Time for 2.4.5 ??
From:       Guenter Knauf <fuankg () apache ! org>
Date:       2013-05-30 18:47:33
Message-ID: 51A79EC5.5060201 () apache ! org
[Download RAW message or body]

Hi Daniel,
On 25.05.2013 05:46, Guenter Knauf wrote:
> On 25.05.2013 02:06, Guenter Knauf wrote:
>> On 24.05.2013 23:45, Daniel Gruno wrote:
>>> That's fine by me, I'm not married to 'sleep' (although I do like a good
>>> nap)
>> hehe, ok; I look into it soon.
> done.
>
> Found another small docu bug:
>
> r:unescape(string) -- Unescapes an URL-escaped string:
>
> local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5"
> local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5'
>
> the function call should here be r:unescape(url) ...

I have meanwhile all the compiler warnings reduced down to one:
.\lua_request.c(574) : warning C4244: 'return' : conversion from 
'apr_off_t' to 'int', possible loss of data

this is a somehwat tricky one, and I'm not sure whats the best way to 
fix it; clearly a cast wouldnt help here since r->remaining is 
apr_off_t, so a cast to int would indeed be a loss of data ...
so the function needs to return the 64-bit apr_off_t:

Index: lua_request.c
===================================================================
--- lua_request.c	(revision 1486269)
+++ lua_request.c	(working copy)
@@ -569,7 +569,7 @@
      return r->useragent_ip;
  }

-static int req_remaining_field(request_rec *r)
+static apr_off_t req_remaining_field(request_rec *r)
  {
      return r->remaining;
  }

but then the problem would be shifted to req_dispatch() where we only 
have APL_REQ_FUNTYPE_INT - should we add there a new type 
APL_REQ_FUNTYPE_INT64? Or do you have a better idea?

Gün.



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic