Re: renaming apr_file_open_flags group defines
As I get no followup to my question, I'll just proceed with this patch and do the other previously discussed renames in the same fashion. Correct? Stas Bekman wrote: Justin Erenkrantz wrote: --On Sunday, September 19, 2004 8:19 PM -0400 Stas Bekman [EMAIL PROTECTED] wrote: FILE_OPEN_ is inconsistent with other file defines. It's usually FFOO, as in FINFO, so APR_FOPEN_ makes more sense, IMHO Agreed. I think APR_FOPEN_* makes more sense. -- justin Please let me know if this is the right change then. This patch (inlined and attached in case it wraps) is against HEAD. Should there be some deprecation tags for doxygen in it? Also I've changed: APR_FILE_NOCLEANUP = APR_FOPEN_NOCLEANUP instead of: APR_FILE_NOCLEANUP = APR_FOPEN_FILE_NOCLEANUP but I'm not sure if this is right. Finally should I replace the macros usage in apr itself? Index: apr/include/apr_file_io.h === RCS file: /home/cvs/apr/include/apr_file_io.h,v retrieving revision 1.153 diff -u -r1.153 apr_file_io.h --- apr/include/apr_file_io.h27 May 2004 20:29:01 -1.153 +++ apr/include/apr_file_io.h3 Oct 2004 14:32:43 - @@ -50,28 +50,49 @@ /* Note to implementors: Values in the range 0x0010--0x8000 are reserved for platform-specific values. */ -#define APR_READ 0x1 /** Open the file for reading */ -#define APR_WRITE 0x2 /** Open the file for writing */ -#define APR_CREATE 0x4 /** Create the file if not there */ -#define APR_APPEND 0x8 /** Append to the end of the file */ -#define APR_TRUNCATE 0x00010 /** Open the file and truncate to 0 length */ -#define APR_BINARY 0x00020 /** Open the file in binary mode */ -#define APR_EXCL 0x00040 /** Open should fail if APR_CREATE and file -exists. */ -#define APR_BUFFERED 0x00080 /** Open the file for buffered I/O */ -#define APR_DELONCLOSE 0x00100 /** Delete the file after close */ -#define APR_XTHREAD0x00200 /** Platform dependent tag to open the file -for use across multiple threads */ -#define APR_SHARELOCK 0x00400 /** Platform dependent support for higher -level locked read/write access to support -writes across process/machines */ -#define APR_FILE_NOCLEANUP 0x00800 /** Do not register a cleanup when the file -is opened */ -#define APR_SENDFILE_ENABLED 0x01000 /** Advisory flag that this file should - support apr_socket_sendfile operation */ -#define APR_LARGEFILE 0x04000/** Platform dependent flag to enable large file -support; WARNING see below. */ +#define APR_FOPEN_READ 0x1 /** Open the file for reading */ +#define APR_FOPEN_WRITE 0x2 /** Open the file for writing */ +#define APR_FOPEN_CREATE 0x4 /** Create the file if not there */ +#define APR_FOPEN_APPEND 0x8 /** Append to the end of the file */ +#define APR_FOPEN_TRUNCATE 0x00010 /** Open the file and truncate + to 0 length */ +#define APR_FOPEN_BINARY 0x00020 /** Open the file in binary mode */ +#define APR_FOPEN_EXCL 0x00040 /** Open should fail if APR_CREATE + and file exists. */ +#define APR_FOPEN_BUFFERED 0x00080 /** Open the file for buffered I/O */ +#define APR_FOPEN_DELONCLOSE 0x00100 /** Delete the file after close */ +#define APR_FOPEN_XTHREAD0x00200 /** Platform dependent tag to open + the file for use across multiple + threads */ +#define APR_FOPEN_SHARELOCK 0x00400 /** Platform dependent support for + higher level locked read/write + access to support writes across + process/machines */ +#define APR_FOPEN_NOCLEANUP 0x00800 /** Do not register a cleanup + when the file is opened */ +#define APR_FOPEN_SENDFILE_ENABLED 0x01000 /** Advisory flag that this + file should support + apr_socket_sendfile operation */ +#define APR_FOPEN_LARGEFILE 0x04000 /** Platform dependent flag to enable + large file support; WARNING see + below. */ +/* backcompat */ +#define APR_READ APR_FOPEN_READ +#define APR_WRITEAPR_FOPEN_WRITE +#define APR_CREATE APR_FOPEN_CREATE +#define APR_APPEND APR_FOPEN_APPEND +#define APR_TRUNCATE APR_FOPEN_TRUNCATE +#define APR_BINARY
Re: renaming apr_file_open_flags group defines
Justin Erenkrantz wrote: --On Sunday, September 19, 2004 8:19 PM -0400 Stas Bekman [EMAIL PROTECTED] wrote: FILE_OPEN_ is inconsistent with other file defines. It's usually FFOO, as in FINFO, so APR_FOPEN_ makes more sense, IMHO Agreed. I think APR_FOPEN_* makes more sense. -- justin Please let me know if this is the right change then. This patch (inlined and attached in case it wraps) is against HEAD. Should there be some deprecation tags for doxygen in it? Also I've changed: APR_FILE_NOCLEANUP = APR_FOPEN_NOCLEANUP instead of: APR_FILE_NOCLEANUP = APR_FOPEN_FILE_NOCLEANUP but I'm not sure if this is right. Finally should I replace the macros usage in apr itself? Index: apr/include/apr_file_io.h === RCS file: /home/cvs/apr/include/apr_file_io.h,v retrieving revision 1.153 diff -u -r1.153 apr_file_io.h --- apr/include/apr_file_io.h 27 May 2004 20:29:01 - 1.153 +++ apr/include/apr_file_io.h 3 Oct 2004 14:32:43 - @@ -50,28 +50,49 @@ /* Note to implementors: Values in the range 0x0010--0x8000 are reserved for platform-specific values. */ -#define APR_READ 0x1 /** Open the file for reading */ -#define APR_WRITE 0x2 /** Open the file for writing */ -#define APR_CREATE 0x4 /** Create the file if not there */ -#define APR_APPEND 0x8 /** Append to the end of the file */ -#define APR_TRUNCATE 0x00010 /** Open the file and truncate to 0 length */ -#define APR_BINARY 0x00020 /** Open the file in binary mode */ -#define APR_EXCL 0x00040 /** Open should fail if APR_CREATE and file -exists. */ -#define APR_BUFFERED 0x00080 /** Open the file for buffered I/O */ -#define APR_DELONCLOSE 0x00100 /** Delete the file after close */ -#define APR_XTHREAD0x00200 /** Platform dependent tag to open the file -for use across multiple threads */ -#define APR_SHARELOCK 0x00400 /** Platform dependent support for higher -level locked read/write access to support -writes across process/machines */ -#define APR_FILE_NOCLEANUP 0x00800 /** Do not register a cleanup when the file -is opened */ -#define APR_SENDFILE_ENABLED 0x01000 /** Advisory flag that this file should - support apr_socket_sendfile operation */ -#define APR_LARGEFILE 0x04000/** Platform dependent flag to enable large file -support; WARNING see below. */ +#define APR_FOPEN_READ 0x1 /** Open the file for reading */ +#define APR_FOPEN_WRITE 0x2 /** Open the file for writing */ +#define APR_FOPEN_CREATE 0x4 /** Create the file if not there */ +#define APR_FOPEN_APPEND 0x8 /** Append to the end of the file */ +#define APR_FOPEN_TRUNCATE 0x00010 /** Open the file and truncate + to 0 length */ +#define APR_FOPEN_BINARY 0x00020 /** Open the file in binary mode */ +#define APR_FOPEN_EXCL 0x00040 /** Open should fail if APR_CREATE + and file exists. */ +#define APR_FOPEN_BUFFERED 0x00080 /** Open the file for buffered I/O */ +#define APR_FOPEN_DELONCLOSE 0x00100 /** Delete the file after close */ +#define APR_FOPEN_XTHREAD0x00200 /** Platform dependent tag to open + the file for use across multiple + threads */ +#define APR_FOPEN_SHARELOCK 0x00400 /** Platform dependent support for + higher level locked read/write + access to support writes across + process/machines */ +#define APR_FOPEN_NOCLEANUP 0x00800 /** Do not register a cleanup + when the file is opened */ +#define APR_FOPEN_SENDFILE_ENABLED 0x01000 /** Advisory flag that this + file should support + apr_socket_sendfile operation */ +#define APR_FOPEN_LARGEFILE 0x04000 /** Platform dependent flag to enable + large file support; WARNING see + below. */ +/* backcompat */ +#define APR_READ APR_FOPEN_READ +#define APR_WRITEAPR_FOPEN_WRITE +#define APR_CREATE APR_FOPEN_CREATE +#define APR_APPEND APR_FOPEN_APPEND +#define APR_TRUNCATE APR_FOPEN_TRUNCATE +#define APR_BINARY APR_FOPEN_BINARY +#define APR_EXCL APR_FOPEN_EXCL +#define APR_BUFFERED APR_FOPEN_BUFFERED +#define APR_DELONCLOSE APR_FOPEN_DELONCLOSE
Re: renaming apr_file_open_flags group defines
[don't forget to Reply-All] William A. Rowe, Jr. wrote: At 05:02 PM 9/19/2004, you wrote: William A. Rowe, Jr. wrote: Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... About this group - smakes sense to me unless these flags are 'generic', e.g. apply-to other. And no, APR_OPEN_ isn't ideal, but APR_FILE_OPEN_ would be. So now that the veto has been removed, what's the best prefix to use? APR_FILE_OPEN_? APR_FOPEN_? other? There is no such apr_open_* today, so that would be wrong. APR_FILE_OPEN_* is right. But I'm not seeing anyone but you and I advocating for it. FILE_OPEN_ is inconsistent with other file defines. It's usually FFOO, as in FINFO, so APR_FOPEN_ makes more sense, IMHO -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_file_open_flags group defines
William A. Rowe, Jr. wrote: At 08:34 PM 9/17/2004, you wrote: This group wasn't discussed before, but it suffers from the same problem. #define APR_READ 0x1 /** Open the file for reading */ #define APR_WRITE 0x2 /** Open the file for writing */ #define APR_CREATE 0x4 /** Create the file if not there */ Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... About this group - smakes sense to me unless these flags are 'generic', e.g. apply-to other. And no, APR_OPEN_ isn't ideal, but APR_FILE_OPEN_ would be. So now that the veto has been removed, what's the best prefix to use? APR_FILE_OPEN_? APR_FOPEN_? other? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
renaming apr_file_open_flags group defines
This group wasn't discussed before, but it suffers from the same problem. #define APR_READ 0x1 /** Open the file for reading */ #define APR_WRITE 0x2 /** Open the file for writing */ #define APR_CREATE 0x4 /** Create the file if not there */ Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_file_open_flags group defines
At 08:34 PM 9/17/2004, you wrote: This group wasn't discussed before, but it suffers from the same problem. #define APR_READ 0x1 /** Open the file for reading */ #define APR_WRITE 0x2 /** Open the file for writing */ #define APR_CREATE 0x4 /** Create the file if not there */ Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... Veto - defer for 2.0 About this group - smakes sense to me unless these flags are 'generic', e.g. apply-to other. And no, APR_OPEN_ isn't ideal, but APR_FILE_OPEN_ would be.
