Bob Friesenhahn wrote:
On Sun, 21 Dec 2003, Guido Draheim wrote:
Well, that doesn't work that well if you are writing a C++ POSIX binding
and don't want to duplicate those data structures. But I see you point.
Maybe I should make the affected functions artificially templated, this
would get th
Bob Friesenhahn wrote:
On Sun, 21 Dec 2003, Guido Draheim wrote:
My configure script needs to have access to the values that
AC_SYS_LARGEFILE sets since including config.h is not sufficient for
all applications. Sometimes the options *must* be specified on the
compiler command line to work. Th
On Sun, 21 Dec 2003, Guido Draheim wrote:
> > Well, that doesn't work that well if you are writing a C++ POSIX binding
> > and don't want to duplicate those data structures. But I see you point.
> > Maybe I should make the affected functions artificially templated, this
> > would get things right
On Sun, 21 Dec 2003, Guido Draheim wrote:
> >
> > My configure script needs to have access to the values that
> > AC_SYS_LARGEFILE sets since including config.h is not sufficient for
> > all applications. Sometimes the options *must* be specified on the
> > compiler command line to work. Therefor
Florian Weimer wrote:
Bob Friesenhahn wrote:
I recommend defining your own equivalents to off_t & ino_t (if needed)
which are *always* 64 bits wide. Only your library implementation
uses the system off_t & ino_t definitions and they are not used in
your public library headers. This way your l
Bob Friesenhahn wrote:
On Sun, 21 Dec 2003, Jeff Sheinberg wrote:
Paul Eggert writes:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> > I'm writing a library that will require large-file support on 32-bit GNU
^^
> > plat
Bob Friesenhahn wrote:
> I recommend defining your own equivalents to off_t & ino_t (if needed)
> which are *always* 64 bits wide. Only your library implementation
> uses the system off_t & ino_t definitions and they are not used in
> your public library headers. This way your library has a cons
On Sun, 21 Dec 2003, Jeff Sheinberg wrote:
> Paul Eggert writes:
> > Florian Weimer <[EMAIL PROTECTED]> writes:
> >
> > > I'm writing a library that will require large-file support on 32-bit GNU
>^^
> > > platforms (so
Paul Eggert writes:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> > I'm writing a library that will require large-file support on 32-bit GNU
^^
> > platforms (so that off_t and ino_t are 64 bits wide, otherwise data
Florian Weimer <[EMAIL PROTECTED]> writes:
> I'm writing a library that will require large-file support on 32-bit GNU
> platforms (so that off_t and ino_t are 64 bits wide, otherwise data
> structure layout would change). What is the canonical way to enforce
> this?
AC_SYS_LARGEFILE
> I guess i
On Sat, 20 Dec 2003, Florian Weimer wrote:
> I'm writing a library that will require large-file support on 32-bit GNU
> platforms (so that off_t and ino_t are 64 bits wide, otherwise data
> structure layout would change). What is the canonical way to enforce
> this?
I recommend defining your own
Florian Weimer wrote:
I'm writing a library that will require large-file support on 32-bit GNU
platforms (so that off_t and ino_t are 64 bits wide, otherwise data
structure layout would change). What is the canonical way to enforce
this?
I guess it's not a good idea to force applications to includ
12 matches
Mail list logo
