Re: Solaris sed based apache filtering module (mod_sed)
Minor changes : Fixed remaining warnings :
* warning: array subscript has type 'char'
* warning: suggest parentheses around assignment used as truth value
* warning C4018: '<' : signed/unsigned mismatch
Here is the diff :
diff -r 071789bf9134 regexp.c
--- a/regexp.c Sun Jun 29 12:52:34 2008 -0700
+++ b/regexp.c Fri Aug 08 17:49:35 2008 -0700
@@ -396,6 +396,7 @@ static int _advance(char *lp, char *ep,
char *bbeg;
char neg;
int ct;
+int epint; /* int value of *ep */
while (1) {
neg = 0;
@@ -440,11 +441,15 @@ static int _advance(char *lp, char *ep,
return (0);
case CBRA:
-vars->braslist[*ep++] = lp;
+epint = (int) *ep;
+vars->braslist[epint] = lp;
+ep++;
continue;
case CKET:
-vars->braelist[*ep++] = lp;
+epint = (int) *ep;
+vars->braelist[epint] = lp;
+ep++;
continue;
case CCHR | RNGE:
@@ -516,8 +521,10 @@ static int _advance(char *lp, char *ep,
goto star;
case CBACK:
-bbeg = vars->braslist[*ep];
-ct = vars->braelist[*ep++] - bbeg;
+epint = (int) *ep;
+bbeg = vars->braslist[epint];
+ct = vars->braelist[epint] - bbeg;
+ep++;
if (ecmp(bbeg, lp, ct)) {
lp += ct;
@@ -526,8 +533,10 @@ static int _advance(char *lp, char *ep,
return (0);
case CBACK | STAR:
-bbeg = vars->braslist[*ep];
-ct = vars->braelist[*ep++] - bbeg;
+epint = (int) *ep;
+bbeg = vars->braslist[epint];
+ct = vars->braelist[epint] - bbeg;
+ep++;
curlp = lp;
while (ecmp(bbeg, lp, ct))
lp += ct;
diff -r 071789bf9134 sed0.c
--- a/sed0.cSun Jun 29 12:52:34 2008 -0700
+++ b/sed0.cFri Aug 08 17:49:35 2008 -0700
@@ -343,7 +343,7 @@ swit:
}
*--tp = '\0';
-if (lpt = search(commands)) {
+if ((lpt = search(commands)) != NULL) {
if (lpt->address) {
command_errf(commands, SEDERR_DLMES, commands->linebuf);
return -1;
@@ -437,8 +437,8 @@ jtcommon:
commands->cp--;
if (*commands->cp == '\0') {
-if (pt = commands->labtab->chain) {
-while (pt1 = pt->lb1)
+if ((pt = commands->labtab->chain) != NULL) {
+while ((pt1 = pt->lb1) != NULL)
pt = pt1;
pt->lb1 = commands->rep;
} else
@@ -454,12 +454,12 @@ jtcommon:
commands->cp--;
*--tp = '\0';
-if (lpt = search(commands)) {
+if ((lpt = search(commands)) != NULL) {
if (lpt->address) {
commands->rep->lb1 = lpt->address;
} else {
pt = lpt->chain;
-while (pt1 = pt->lb1)
+while ((pt1 = pt->lb1) != NULL)
pt = pt1;
pt->lb1 = commands->rep;
}
@@ -926,6 +926,7 @@ static char *ycomp(sed_commands_t *comma
static char *ycomp(sed_commands_t *commands, char *expbuf)
{
charc;
+int cint; /* integer value of char c */
char *ep, *tsp;
int i;
char*sp;
@@ -953,11 +954,12 @@ static char *ycomp(sed_commands_t *comma
sp++;
c = '\n';
}
-if((ep[c] = *tsp++) == '\\' && *tsp == 'n') {
-ep[c] = '\n';
+cint = (int) c;
+if((ep[cint] = *tsp++) == '\\' && *tsp == 'n') {
+ep[cint] = '\n';
tsp++;
}
-if(ep[c] == commands->sseof || ep[c] == '\0') {
+if(ep[cint] == commands->sseof || ep[cint] == '\0') {
command_errf(commands, SEDERR_TSNTSS, commands->linebuf);
}
}
diff -r 071789bf9134 sed1.c
--- a/sed1.cSun Jun 29 12:52:34 2008 -0700
+++ b/sed1.cFri Aug 08 17:49:35 2008 -0700
@@ -152,7 +152,7 @@ static void grow_gen_buffer(sed_eval_t *
*/
static void appendmem_to_linebuf(sed_eval_t *eval, const char* sz, int len)
{
-int reqsize = (eval->lspend - eval->linebuf) + len;
+unsigned int reqsize = (eval->lspend - eval->linebuf) + len;
if (eval->lsize < reqsize) {
grow_line_buffer(eval, reqsize);
}
@@ -186,7 +186,7 @@ static void append_to_holdbuf(sed_eval_t
static void append_to_holdbuf(sed_eval_t *eval, const char* sz)
{
int len = strlen(sz);
-int reqsize = (eval->hspend - eval->holdbuf) + len + 1;
+unsigned int reqsize = (eval->hspend - eval->holdbuf) + len + 1;
if (eval->hsize <= reqsize) {
grow_hold_buffer(eval, reqsize);
}
@@ -210,7 +210,7 @@ static void append_to_genbuf(sed_eval_
Re: mod_status slots
Jordi Prats wrote: I don't know about other implications of changing this line. I've just tested it using prefork both restarting and reloading apache. What do you think about this little change? How's your proposed patch interact with a server using slots 1-16, 128-136 when they gracefully restart the server with a lower number of maxclients?
Re: svn commit: r683626 - in /httpd/httpd/trunk: CHANGES modules/dav/fs/repos.c
On Fri, Aug 8, 2008 at 5:28 AM, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 07, 2008 at 03:12:00PM -, Jeff Trawick wrote:
> > --- httpd/httpd/trunk/modules/dav/fs/repos.c (original)
> > +++ httpd/httpd/trunk/modules/dav/fs/repos.c Thu Aug 7 08:12:00 2008
> > @@ -1475,10 +1475,8 @@
> > /* append this file onto the path buffer (copy null term) */
> > dav_buffer_place_mem(pool, &fsctx->path1, dirent.name, len + 1,
> 0);
> >
> > -
> > -/* ### Optimize me, dirent can give us what we need! */
> > status = apr_stat(&fsctx->info1.finfo, fsctx->path1.buf,
> > - APR_FINFO_NORM | APR_FINFO_LINK, pool);
> > + APR_FINFO_TYPE | APR_FINFO_LINK, pool);
> > if (status != APR_SUCCESS && status != APR_INCOMPLETE) {
> > /* woah! where'd it go? */
> > /* ### should have a better error here */
> >
>
> Nit pick: on Unix APR_FINFO_PROT is needed too, to support the
> executable property...
plz show me where; I'm blind; thanks!
Re: mod_wombat and luasocket
Have you looked in the httpd error log.
I bet the processing httpd process died with a segfault or something similar.
Regards
Rüdiger
> -Ursprüngliche Nachricht-
> Von: Corsix
> Gesendet: Freitag, 8. August 2008 15:12
> An: dev@httpd.apache.org
> Betreff: Re: mod_wombat and luasocket
>
> Seems I was wrong; commenting out that call doesn't make luasocket
> load. This still leaves the main question unresolved though; why does
> require"socket" cause a blank response (as even a standard error would
> be caught by mod_wombat's usage of lua_pcall)?
>
> 2008/8/8 Corsix <[EMAIL PROTECTED]>:
> > Hi,
> >
> > While using mod_wombat and attempting to use luasocket (with require
> > "socket"), I get a white screen. Assuming test.lua is:
> > -- code --
> > function handle(r)
> > r:write "Start\n"
> > require "socket"
> > r:write "Done\n"
> > end
> > -- end code --
> > The expected output when requesting this page via a web
> browser would give:
> > Start
> > Done
> > If "socket" is changed to "lpeg" (assuming you have LPEG installed),
> > or the require line is commented out, then yes, that is the output.
> > However, as-is, the response is a blank screen. As far as I
> can tell,
> > the cause is this part of luasocket's usocket.c:
> > /* code */
> >
> /*
> -*\
> > * Initializes module
> >
> \*
> -*/
> > int socket_open(void) {
> >/* instals a handler to ignore sigpipe or it will crash us */
> >signal(SIGPIPE, SIG_IGN);
> >return 1;
> > }
> > /* end code */
> > After commenting out the call to signal and recompiling,
> the above Lua
> > code will happily load socket.
> >
> > Why does commenting out this call cause luasocket to now load, and
> > what undesired consequences are there of doing this?
> >
> > Peter
> >
>
Re: mod_wombat and luasocket
Seems I was wrong; commenting out that call doesn't make luasocket
load. This still leaves the main question unresolved though; why does
require"socket" cause a blank response (as even a standard error would
be caught by mod_wombat's usage of lua_pcall)?
2008/8/8 Corsix <[EMAIL PROTECTED]>:
> Hi,
>
> While using mod_wombat and attempting to use luasocket (with require
> "socket"), I get a white screen. Assuming test.lua is:
> -- code --
> function handle(r)
> r:write "Start\n"
> require "socket"
> r:write "Done\n"
> end
> -- end code --
> The expected output when requesting this page via a web browser would give:
> Start
> Done
> If "socket" is changed to "lpeg" (assuming you have LPEG installed),
> or the require line is commented out, then yes, that is the output.
> However, as-is, the response is a blank screen. As far as I can tell,
> the cause is this part of luasocket's usocket.c:
> /* code */
> /*-*\
> * Initializes module
> \*-*/
> int socket_open(void) {
>/* instals a handler to ignore sigpipe or it will crash us */
>signal(SIGPIPE, SIG_IGN);
>return 1;
> }
> /* end code */
> After commenting out the call to signal and recompiling, the above Lua
> code will happily load socket.
>
> Why does commenting out this call cause luasocket to now load, and
> what undesired consequences are there of doing this?
>
> Peter
>
mod_wombat and luasocket
Hi,
While using mod_wombat and attempting to use luasocket (with require
"socket"), I get a white screen. Assuming test.lua is:
-- code --
function handle(r)
r:write "Start\n"
require "socket"
r:write "Done\n"
end
-- end code --
The expected output when requesting this page via a web browser would give:
Start
Done
If "socket" is changed to "lpeg" (assuming you have LPEG installed),
or the require line is commented out, then yes, that is the output.
However, as-is, the response is a blank screen. As far as I can tell,
the cause is this part of luasocket's usocket.c:
/* code */
/*-*\
* Initializes module
\*-*/
int socket_open(void) {
/* instals a handler to ignore sigpipe or it will crash us */
signal(SIGPIPE, SIG_IGN);
return 1;
}
/* end code */
After commenting out the call to signal and recompiling, the above Lua
code will happily load socket.
Why does commenting out this call cause luasocket to now load, and
what undesired consequences are there of doing this?
Peter
Re: svn commit: r683626 - in /httpd/httpd/trunk: CHANGES modules/dav/fs/repos.c
On Thu, Aug 07, 2008 at 03:12:00PM -, Jeff Trawick wrote:
> --- httpd/httpd/trunk/modules/dav/fs/repos.c (original)
> +++ httpd/httpd/trunk/modules/dav/fs/repos.c Thu Aug 7 08:12:00 2008
> @@ -1475,10 +1475,8 @@
> /* append this file onto the path buffer (copy null term) */
> dav_buffer_place_mem(pool, &fsctx->path1, dirent.name, len + 1, 0);
>
> -
> -/* ### Optimize me, dirent can give us what we need! */
> status = apr_stat(&fsctx->info1.finfo, fsctx->path1.buf,
> - APR_FINFO_NORM | APR_FINFO_LINK, pool);
> + APR_FINFO_TYPE | APR_FINFO_LINK, pool);
> if (status != APR_SUCCESS && status != APR_INCOMPLETE) {
> /* woah! where'd it go? */
> /* ### should have a better error here */
>
Nit pick: on Unix APR_FINFO_PROT is needed too, to support the
executable property... but it gets picked up by stat anyway, and Win32
doesn't expose that property.
joe
mod_status slots
Hi all, I've seen that mod_status shows the number of slots available as the ServerLimit directive. In my opinion this is not meaningful because if you set the MaxClient directive to a lower value it does not reflect on the available slots on mod_status. I would like to suggest to change this behaviour by just changing a line: diff -Naur httpd-orig/modules/generators/mod_status.c httpd-mod/modules/generators/mod_status.c --- httpd-orig/modules/generators/mod_status.c 2008-01-02 10:43:52.0 +0100 +++ httpd-mod/modules/generators/mod_status.c 2008-08-08 10:04:26.0 +0200 @@ -848,7 +848,7 @@ status_flags[SERVER_GRACEFUL] = 'G'; status_flags[SERVER_IDLE_KILL] = 'I'; ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit); -ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit); +ap_mpm_query(AP_MPMQ_MAX_DAEMON_USED, &server_limit); return OK; } I don't know about other implications of changing this line. I've just tested it using prefork both restarting and reloading apache. What do you think about this little change? regards, -- Jordi
