apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Miscellaneous newbie issues
Date Wed, 01 Dec 2004 01:39:11 GMT
I'm migrating log4cxx (http://logging.apache.org/log4cxx) over to use 
APR instead of maintaining its #if'd hacks and inline Solaris 
assembler.  I run into a few curiousities and I thought that I would 
throw them out here for feedback before deciding if they are really 
bugs or features.

1. APR uses of WIN32 instead of _WIN32

Microsoft C++, Borland C++ et al document _WIN32 as a predefined 
preprocessor macro but does not predefine WIN32.  Visual Studio will 
typically add a WIN32 macro to its generated project files, I assume 
for backward compatibility with code that predates the use of _WIN32.  
Could use of WIN32 be replaced with _WIN32 to eliminate the need to 
have the driver try to figure out what the compiler already knows (and 
likely introduce inconsistencies when cross-compiling for Win64)?  If 
not could conditions involving WIN32 be modified so they pass if either 
WIN32 or _WIN32 is defined?  _WIN64 appears to be the predefined macro 
for 64-bit Windows.

2. APR_INT64_C not resolved for g++

The following code will fail to compile with g++ 3.3.3 on Linux and Mac 
OS/X (but will compile with Microsoft CL and gcc)

#include <apr.h>
int main(int argc, char** argv) {
apr_int64_t foo = APR_INT64_C(1000);
}

with an "INT64_C undeclared (first use this function)" error.  I assume 
the same problem would exist with APR_TIME_C in apr_time.h.  I've 
worked around the problem by adding definitions for INT64_C in my 
source to handle the case where they aren't available:

#include <apr.h>

#if !defined(INT64_C)
#define INT64_C(c) c ## LL
#endif



3. Dates earlier than 1 Jan 1970 have negative microseconds when 
exploded.

In explode_time in unix/time.c (haven't checked other platforms), the 
lines:

     time_t tt = (t / APR_USEC_PER_SEC) + offset;
     xt->tm_usec = t % APR_USEC_PER_SEC;

will result in tm_usec having a negative value when t < 0 and the tt 
structure being rounded forward toward the epoch date.  Probably the 
simplest fix, is just to check if tm_usec is less than zero, then add 
APR_USEC_PER_SEC to it and substract one from tt.

4. Not clear that you don't independently compile apr-iconv

I attempted to build apr-iconv by itself under Linux and was having no 
fun as build/rules.mk had paths like /opt/subversion-1.1.0 and had the 
APR major version as 0, etc.  I futzed trying to get it to build, but 
have up and moved to apr-util which apparently does compile apr-iconv 
as part of its build process.




Mime
View raw message