HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]

[Dag-Erling Smørgrav]

Xin LI <delphij at gmail.com> writes:
> Tom Uffner <tom at uffner.com> writes:
> > Michael Butler <imb at protected-networks.net> writes:
> > > This breaks most (if not all) of the QT4-dependent ports for the
> > > lack of a definition of "off64_t".
> > it also breaks multimedia/mplayer, graphics/ImageMagick, and
> > print/ghostscript8 & everything that depends on it.
> Just because they used to compile DOES NOT mean they were right.  It's
> NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see:
>
> http://www.delorie.com/gnu/docs/glibc/libc_13.html

Nor is it correct on Linux.  As the above link says, _LARGEFILE64_SOURCE
is a hack that was introduced to ease the transition from 32-bit off_t
to 64-bit off_t.  The correct idiom is to define _FILE_OFFSET_BITS to 64
before including <sys/types.h> and <sys/stat.h>.

http://www.delorie.com/gnu/docs/glibc/libc_13.html

That was *fourteen years ago*, almost to the day.  There is *no* excuse
for using this hack today.  *Especially* in software that was written
long after that document was published.  *Especially* when all you need
to do to get it right is add AC_SYS_LARGEFILE to configure.ac and use
off_t, struct stat and stat() / lstat() (without the "64" suffix) as if
none of this had ever happened.

And yes, I *will* keep harping on this until people Get It.

DES
-- 
Dag-Erling Smørgrav - des at des.no