Disconnect between bucket and filter enums?

[Justin Erenkrantz <je...@ebuilt.com>]

One last warning concerning modules/http/http_protocol.c.  No patch 
as I'm not sure which enum is right.

"http_protocol.c", line 502: warning: enum type mismatch: arg #4
"http_protocol.c", line 593: warning: enum type mismatch: arg #4
"http_protocol.c", line 642: warning: enum type mismatch: arg #4

Those lines concern the mode variable into the bucket read functions.
apr_util has BLOCK_READ and NONBLOCK_READ.  The filters have similar 
(but not exactly the same) names and honor a third value PEEK.  IIRC, 
most compilers start enums at 0 - so I doubt the mismatch is hurting 
us as long as we don't pass PEEK to the buckets.  It does look like 
the filter code (ap_http_filter) is using the PEEK enum for 
keepalive/pipelining detection (not being passed to the buckets 
though).  Since we are using the PEEK value, I don't think we can 
just toss the ap_input_mode_t enum.

Here are the relevant enums:

typedef enum {
    APR_BLOCK_READ,
    APR_NONBLOCK_READ
} apr_read_type_e;

typedef enum {
    /** The filter shouldn't return until data is received or EOF is hit
     *  or an error occurs. */
    AP_MODE_BLOCKING,
    /** The filter should process any available data/status as normal,
     *  but will not wait for additional data. */
    AP_MODE_NONBLOCKING,
    /** The filter should return ::APR_SUCCESS if data is available or
     *  ::APR_EOF otherwise.  The filter must not return any buckets of
     *  data.  Data returned on a subsequent call, when mode is
     *  ::AP_MODE_BLOCKING or ::AP_MODE_NONBLOCKING. */
    AP_MODE_PEEK
} ap_input_mode_t;

I'll let someone who is more familiar with the bucket code and who has
httpd commit access figure this out if they want to.  =)  -- justin

RE: Disconnect between bucket and filter enums?

[Sander Striker <st...@apache.org>]

> On Mon, 23 Jul 2001, Ryan Bloom wrote:
>
> > > Those lines concern the mode variable into the bucket read functions.
> > > apr_util has BLOCK_READ and NONBLOCK_READ.  The filters have similar
> > > (but not exactly the same) names and honor a third value PEEK.  IIRC,
> > > most compilers start enums at 0 - so I doubt the mismatch is hurting
> > > us as long as we don't pass PEEK to the buckets.  It does look like
> > > the filter code (ap_http_filter) is using the PEEK enum for
> > > keepalive/pipelining detection (not being passed to the buckets
> > > though).  Since we are using the PEEK value, I don't think we can
> > > just toss the ap_input_mode_t enum.
> >
> > This was done specifically because of the way enums work in C.  We
> > need both enums, because filters have more modes than buckets, and
> > filters are a part of Apache, whereas buckets are a part of APR-util.
> > Not much we can do about this, other than to lower the warning level,
> > or cast.
>
> I've brought this up before and don't remember getting any response... so
> anything is better than what's there now as far as I'm concerned.  My
> vote: officially santion using a cast to get rid of the warning, document
> the dependency heavily in the header file, and change the places in Apache
> where a conditional is used to do the conversion to a simple cast.

If the two are so dependent, this should be reflected in the ap_input_mode_t
enum like so IMHO (this ofcourse next to the documentation as suggested
by Cliff):

typedef enum {
    AP_MODE_BLOCKING    = APR_BLOCK_READ,
    AP_MODE_NONBLOCKING = APR_NONBLOCK_READ,
    AP_MODE_PEEK
} ap_input_mode_t;


Sander

Re: Disconnect between bucket and filter enums?

[Cliff Woolley <cl...@yahoo.com>]

On Mon, 23 Jul 2001, Ryan Bloom wrote:

> > Those lines concern the mode variable into the bucket read functions.
> > apr_util has BLOCK_READ and NONBLOCK_READ.  The filters have similar
> > (but not exactly the same) names and honor a third value PEEK.  IIRC,
> > most compilers start enums at 0 - so I doubt the mismatch is hurting
> > us as long as we don't pass PEEK to the buckets.  It does look like
> > the filter code (ap_http_filter) is using the PEEK enum for
> > keepalive/pipelining detection (not being passed to the buckets
> > though).  Since we are using the PEEK value, I don't think we can
> > just toss the ap_input_mode_t enum.
>
> This was done specifically because of the way enums work in C.  We
> need both enums, because filters have more modes than buckets, and
> filters are a part of Apache, whereas buckets are a part of APR-util.
> Not much we can do about this, other than to lower the warning level,
> or cast.

I've brought this up before and don't remember getting any response... so
anything is better than what's there now as far as I'm concerned.  My
vote: officially santion using a cast to get rid of the warning, document
the dependency heavily in the header file, and change the places in Apache
where a conditional is used to do the conversion to a simple cast.

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

Re: Disconnect between bucket and filter enums?

[Ryan Bloom <rb...@covalent.net>]

On Monday 23 July 2001 01:19, Justin Erenkrantz wrote:
> One last warning concerning modules/http/http_protocol.c.  No patch
> as I'm not sure which enum is right.
>
> "http_protocol.c", line 502: warning: enum type mismatch: arg #4
> "http_protocol.c", line 593: warning: enum type mismatch: arg #4
> "http_protocol.c", line 642: warning: enum type mismatch: arg #4
>
> Those lines concern the mode variable into the bucket read functions.
> apr_util has BLOCK_READ and NONBLOCK_READ.  The filters have similar
> (but not exactly the same) names and honor a third value PEEK.  IIRC,
> most compilers start enums at 0 - so I doubt the mismatch is hurting
> us as long as we don't pass PEEK to the buckets.  It does look like
> the filter code (ap_http_filter) is using the PEEK enum for
> keepalive/pipelining detection (not being passed to the buckets
> though).  Since we are using the PEEK value, I don't think we can
> just toss the ap_input_mode_t enum.
>
> Here are the relevant enums:
>
> typedef enum {
>     APR_BLOCK_READ,
>     APR_NONBLOCK_READ
> } apr_read_type_e;
>
> typedef enum {
>     /** The filter shouldn't return until data is received or EOF is hit
>      *  or an error occurs. */
>     AP_MODE_BLOCKING,
>     /** The filter should process any available data/status as normal,
>      *  but will not wait for additional data. */
>     AP_MODE_NONBLOCKING,
>     /** The filter should return ::APR_SUCCESS if data is available or
>      *  ::APR_EOF otherwise.  The filter must not return any buckets of
>      *  data.  Data returned on a subsequent call, when mode is
>      *  ::AP_MODE_BLOCKING or ::AP_MODE_NONBLOCKING. */
>     AP_MODE_PEEK
> } ap_input_mode_t;
>
> I'll let someone who is more familiar with the bucket code and who has
> httpd commit access figure this out if they want to.  =)  -- justin

This was done specifically because of the way enums work in C.  We need both enums,
because filters have more modes than buckets, and filters are a part of Apache, whereas
buckets are a part of APR-util.  Not much we can do about this, other than to lower the
warning level, or cast.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------