bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] same, utimecmp should depend on minmax


From: Paul Eggert
Subject: Re: [bug-gnulib] same, utimecmp should depend on minmax
Date: Fri, 20 May 2005 14:12:22 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

Derek Price <address@hidden> writes:

> Isn't there some sense to assuming that if <limits.h> or <sys/param.h>
> define MIN & MAX on a system, then including said header is the
> "correct" way of getting the definition on one of these systems?

Perhaps, if the macros there are correct.  Sometimes a header will
define MIN and not MAX, or vice versa.

I just checked, and 5 headers on my Debian 3.0r1 host define MIN
directly: sys/param.h, linux/cycx_drv.h, linux/efs_fs.h,
linux/if_tun.h, and linux/isicom.h.  I don't know how many define
it indirectly.

Nine headers on my Solaris 10 box define MIN directly:

Mrm/Mrm.h
Xm/TextP.h
fm/fmd_api.h
fm/fmd_fmri.h
sys/fs/hsfs_rrip.h
sys/ldterm.h
sys/mdb_modapi.h
sys/sysmacros.h
utility.h

Again, I don't know how many define it indirectly.

More and more this is starting to sound like a loser situation.
Perhaps we should give up on these predecessor #includes entirely, and
warn users that they must include minmax.h after they include any file
that might possibly include a system file.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]