Re: [Libevent-users] off_t confusion

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

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.

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.