Re: renaming apr_filetype enum entries
At 04:20 PM 9/19/2004, Stas Bekman wrote: So if that's fine with everybody and now Bill has pulled down his veto, the only thing to wait for is the APR_1_1 branch to appear? Any plans for that? APR_1_0 should be created soon, before new progress. HEAD should be 1_1 till we release it.
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_filetype enum entries
On Sun, Sep 19, 2004 at 04:41:49PM -0500, William A. Rowe, Jr. wrote: At 04:20 PM 9/19/2004, Stas Bekman wrote: So if that's fine with everybody and now Bill has pulled down his veto, the only thing to wait for is the APR_1_1 branch to appear? Any plans for that? APR_1_0 should be created soon, before new progress. HEAD should be 1_1 till we release it. Know your tools, boys. We don't have to create a 1.0 branch right now. Head can be 1.1. If we want 1.0 releases, *then* we create a branch. It is easy to do that, based on the 1.0 tag. There is no need at all to hold any development whatsoever. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: renaming apr_filetype enum entries
On Sun, Sep 19, 2004 at 06:01:01PM -0400, Stas Bekman wrote: Greg Stein wrote: ... IMO, projects should just use the API of the oldest major revision that they can, and forget a bunch of compat stuff. If a project codes against version 1.0, then it will work for everything after that. mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and it'll probably support 2.2 as well. So if those defines are added in apr 1.1 we can't use them w/o the compat layer, to support older libapr. That's what I'm saying: don't use them. Make your life easier and forget the compat layer. For some people, they'll go ahead and code to the new 1.1 API, and they'll use the better symbol names. But, your call. :-) ... It will transparently work with both if we use APR_REG and friends. I don't want to add a bunch of #ifdef code to httpd if it isn't needed. Right, but there were just few opinions so far of whether both should be supported or not. I just thought that the decision wasn't cast in stone yet. Both *WILL* be supported. There is no question to that. That's an absolute baesd on the compat rules. The only way to avoid supporting both is to shoot for a 2.0 release, and I'll veto any change that forces a 2.0 so darned soon. I would expect to live in 1.x land for at least a couple years. When our API gets too kludgy because of deprecation or whatever, *then* we move to 2.0 and clear that out. I believe the only question on the table is whether the short form macros (e.g. APR_REG) are part of the API, or whether they are deprecated. But they *will* still exist. ... Well, what you're really doing is providing a 1.1 API to all users. I understand the motivation, but I'm not personally interested in that for httpd. You mean, you'd like to keep the old short defines used across httpd? and inside libapr? Just in httpd. APR can use the new macros, of course. Cheers, -g -- Greg Stein, http://www.lyra.org/
Bug in unix apr_stat involving the name field.
The following works on win32 but not on linux. Looks like the name field of
apr_file_t is never set on unix so the value is garbage.
apr_file_t finfo;
apr_status_t s = apr_stat(finfo, filename,
APR_FINFO_NAME |
APR_FINFO_SIZE,
pool);
if (s == APR_SUCCESS)
{
std::cout Path+Name: finfo.fname std::endl;
std::cout Name: finfo.name std::endl;
std::cout Size: finfo.size std::endl;
}
I'm using apr-1.0.0
Thanks,
Scott Greig
Altair Engineering, Inc.
Re: Bug in unix apr_stat involving the name field.
At 11:53 AM 9/20/2004, you wrote: The following works on win32 but not on linux. Looks like the name field of apr_file_t is never set on unix so the value is garbage. are you testing the .valid bit APR_FINFO_FNAME value? There are scenarios on every platform when specific fields cannot be set, it's important to check the .valid bits. If apr_stat(, APR_FINFO_NAME, poll) returns APR_SUCCESS, that would be a bug, the correct return code is APR_INCOMPLETE. It would be -totally- wrong to just stuff the name passed for Unix, because some Unix file systems, e.g. mounted from Samba, HFS (Mac OS), and others can return another file from a non-canonical name. Bill
RE: Bug in unix apr_stat involving the name field.
I had fixed my problem by memset-ing my apr_finfo_t to 0 before calling apr_stat, then checking for a non-null name before using it. I was not testing for the valid bit, I'll change to this method. So apr_stat is working correctly. Thanks for the information. - Scott -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, September 20, 2004 1:39 PM To: Scott Greig Cc: dev@apr.apache.org Subject: Re: Bug in unix apr_stat involving the name field. At 11:53 AM 9/20/2004, you wrote: The following works on win32 but not on linux. Looks like the name field of apr_finfo_t is never set on unix so the value is garbage. are you testing the .valid bit APR_FINFO_FNAME value? There are scenarios on every platform when specific fields cannot be set, it's important to check the .valid bits. If apr_stat(, APR_FINFO_NAME, poll) returns APR_SUCCESS, that would be a bug, the correct return code is APR_INCOMPLETE. It would be -totally- wrong to just stuff the name passed for Unix, because some Unix file systems, e.g. mounted from Samba, HFS (Mac OS), and others can return another file from a non-canonical name. Bill
����������� �������� ����. ��OE����O�A��E. ���A��E��E. �O��C���A.
- -, -, -, , , CASHCARRY, , , , , . : : ___ . OEOAE. AEE. EEA. OCA. . ( ) . Raben. new 25-31 2004 () ___ ,, , , . . ,,. ,, (, , ), , . * eoece ooe oa oe. oeoae. aee. * ocoe aa eeaa oao. * ca: oaa, aee, oca. * ca eo ooo. caca eo. cace eca. caco coca. ca aoo oaa. ceca acoa . oaa oecca ae cao. !!! : a) : ( * RABEN * * . . * * ( .) b) :Raben ( ), -. ) - . -: * - "AXE CONSULTING" (). 7 .Biedronka, Champion. CARREFOURElektromis S.A. CARREFOUR, Champion, STOS, SCA PR .ProcterGamble, Polsmak, Henkel Polska, Hochland, Pasco, Browar Dojlidy, Miraculum, Cadbury Wedel . * Raben * Skanska - * Quantum Softwear S.A.- , * , .E.Leclerc, Carrefour. : 25 2004 . 1- . . . 2-,. Centrum Ekspedycyjno - Rozdzielczego.. 3-- Raben. .1 ( IKEA. - Quantum Softwear S.A. , . 4- ( , )(3 ). . 5-.( , ): -- E.Leclerc, Carrefour, Geant10 000 30 000 2. - Galeria Mokotow. BLUE CITY (240 2). . *** HETMAN (). 6- Mega Centrum Marki M1 ( : PRAKTIKER , DECATHLON, Media Markt, REAL, IKEA - :240002). : , 10 2004 : 900,- .. -- ( . ) 940,- .. - V.I.P. ( 1 10 ) 10 2004: 1000,- .. -- 01 2004 . - 3 % 5% . . , 2003-2004 !!! : NEOPLAN -- - - ( () . ), ,-,HETMAN***()Rzymski***(), -, , ,, ( ), - , , . : 250 -, , - ( "", "", "", "", "", , -, , " ", " ", "", "", "MERX", "-", "", " ", "I ", "", "", , "-", "",(SPAR ), (SPAR ), "" (.-), "" () ) ICIC - ,. , , , . attachment: auchan.gifattachment: biedronka.gifattachment: carrefour.gifattachment: champion.gifattachment: geant.gifattachment: ikea.gifattachment: leclerc.gifattachment: lidl.gifattachment: logo.gifattachment: tel.gif
Re: cvs commit: apr/atomic/win32 apr_atomic.c
On Mon, 20 Sep 2004 [EMAIL PROTECTED] wrote:
ake 2004/09/20 12:20:12
Modified:atomic/win32 apr_atomic.c
Log:
WIN64: avoid unresolved external error with 64 bit build
{
+#if (defined(_M_IA64) || defined(_M_AMD64))
+return InterlockedExchangeAdd(mem, val);
+#else
return ((apr_atomic_win32_ptr_val_fn)InterlockedExchangeAdd)(mem, val);
+#endif
}
Doesn't this just mean that the definition of apr_atomic_win32_ptr_val_fn
is wrong on win64? Wouldn't it be cleaner to redefine that on win64
instead of these two #if #else cases?
--Cliff
[Fwd: Re: cvs commit: apr/atomic/win32 apr_atomic.c]
meant to reply to [EMAIL PROTECTED] also Original Message Subject: Re: cvs commit: apr/atomic/win32 apr_atomic.c Date: Mon, 20 Sep 2004 18:42:24 -0400 From: Allan Edwards [EMAIL PROTECTED] To: Cliff Woolley [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Doesn't this just mean that the definition of apr_atomic_win32_ptr_val_fn is wrong on win64? Wouldn't it be cleaner to redefine that on win64 instead of these two #if #else cases? The problem is with the use of a typedef to remap the function. It makes the compiler think there is an external function called InterlockedExchangeAdd when it really is an intrinsic function. So redefining for win64 does not work (in fact no remapping would be needed for win64 since it matches the typedef). Allan
