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 [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-----------------------------------------------------------------------------
