On Thu, Aug 11, 2011 at 2:06 PM, Michael Herf<herf@xxxxxxxxx> wrote:
I'm compiling libevent on Solaris.
ev_off_t appears to be #define'd as off_t on UNIX machines ("#define
ev_off_t off_t" in util.h).
However, on this machine, off_t is first defined in *stdio.h*!
Additionally, my app uses the following defines to make stdio 64-bit aware:
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
Of course, libevent does *not* compile with these flags, and so off_t is 32
bits when the library is built, and then it's 64 bits in my app!
This makes for all sorts of fun when calling evbuffer_add_file.
I suspect other OSes have a consistent off_t and so this case isn't insane.
But *why* is ev_off_t based on stdio in this case (is this a Solaris
accident)?
My patch for now is to use "always be 64-bit" for ev_off_t (like the Windows
code does). Any other suggestions to make this more bulletproof?
i.e. #define ev_off_t ev_int64_t
Here's what I think makes the most sense here: we should first off
invoke the magic flags while building libevent that use largefile
stuff wherever possible internally. This is disgustingly nonportable,
but not _so_ bad in practice. In libevent 2.0, we can do so by adding
stuff to CFLAGS or adding appropriate defines to util-internal.h and
making sure that we pull it in everywhere. In libevent 2.1, we should
use the new evconfig-private.h mechanism for autoconf-based
definitions that only want to apply during the library build.
But for our headers, we should just do something like
#if _EVENT_SIZEOF_OFF_T == 8
#define ev_off_t ev_int64_t
#else
#define ev_off_t ev_int32_t
#endif
This is a possible fix IMO for 2.1. I'm not sure weether doing it for
2.0 is API/ABI safe.