apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] bucket type "capabilities" flags
Date Tue, 19 Jun 2001 11:06:14 GMT
Cliff Woolley <cliffwoolley@yahoo.com> writes:

> +/**
> + * apr_bucket_type_t flags
> + */
> +#define APR_BUCKET_FLAGNONE     0x00000000
> +#define APR_BUCKET_FLAGSETASIDE 0x00000001
> +#define APR_BUCKET_FLAGSPLIT    0x00000002
> +#define APR_BUCKET_FLAGCOPY     0x00000004
> +#define APR_BUCKET_FLAGSENDFILE 0x00000010
> +#define APR_BUCKET_FLAGMETADATA 0x00000100
> +#define APR_BUCKET_FLAGALLFNS						\

how about a '_' after FLAG?  as long as they are already we might as
well make them a little more readable :)

re APR_BUCKET_FLAGSENDFILE: all that matters is that the bucket
represents an apr_file_t...  whether or not somebody is going to use
apr_sendfile() or something else shouldn't be important to the bucket
code, should it?  perhaps it should be renamed to APR_BUCKET_FLAGFILE

a couple of really tiny nits about APR_BUCKET_FLAGALLFNS...

. ALLFNS doesn't mean all functions, it just means all of the cool

. ALLFNS will surely change in the future, but what is the way to get
  the bucket types updated appropriately?  I suspect that if we do
  away with ALLFNS and instead "spell it out" in the bucket type
  definitions it will be most obvious what to update


possible phase 2 change...

would it be bad to have an accessor function for the file descriptor?
otherwise, the doc for APR_BUCKET_FLAGSENDFILE should mention that if
the bucket has this flag then the apr_file_t * has to be at the magic
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message