Derek Price <[EMAIL PROTECTED]> 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. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
