Up to [cvs.NetBSD.org] / src / sys / rump / dev / lib / libugenhc
Request diff between arbitrary revisions
Default branch: MAIN
Current tag: phil-wifi-20190609
Revision 1.27 / (download) - annotate - [select for diffs], Mon Sep 3 16:29:37 2018 UTC (5 years, 6 months ago) by riastradh
Branch: MAIN
CVS Tags: thorpej-futex-base,
thorpej-futex,
thorpej-cfargs-base,
phil-wifi-20200421,
phil-wifi-20200411,
phil-wifi-20200406,
phil-wifi-20191119,
phil-wifi-20190609,
pgoyette-compat-20190127,
pgoyette-compat-20190118,
pgoyette-compat-1226,
pgoyette-compat-1126,
pgoyette-compat-1020,
pgoyette-compat-0930,
pgoyette-compat-0906,
netbsd-9-base,
netbsd-9-3-RELEASE,
netbsd-9-2-RELEASE,
netbsd-9-1-RELEASE,
netbsd-9-0-RELEASE,
netbsd-9-0-RC2,
netbsd-9-0-RC1,
netbsd-9,
isaki-audio2-base,
isaki-audio2,
is-mlppp-base,
is-mlppp,
bouyer-xenpvh-base2,
bouyer-xenpvh-base1,
bouyer-xenpvh-base,
bouyer-xenpvh,
ad-namecache-base3,
ad-namecache-base2,
ad-namecache-base1,
ad-namecache-base,
ad-namecache
Branch point for: thorpej-cfargs
Changes since 1.26: +5 -5
lines
Diff to previous 1.26 (colored)
Rename min/max -> uimin/uimax for better honesty. These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended. HOWEVER! Some subsystems have #define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b)) even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation. To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it. I have left a handful of bootloaders that are too annoying to compile-test, and some dead code: cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4)) It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them. Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!)