d1579b2d70
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!) |
||
---|---|---|
.. | ||
bold8x16.h | ||
DejaVu_Sans_Mono_12x22.h | ||
Droid_Sans_Mono_9x18.h | ||
Droid_Sans_Mono_12x22.h | ||
Droid_Sans_Mono_19x36.h | ||
files.wsfont | ||
gallant12x22.h | ||
glass10x19.h | ||
glass10x25.h | ||
Go_Mono_12x23.h | ||
lucida16x29.h | ||
omron12x20.h | ||
qvss8x15.h | ||
sony8x16.h | ||
sony12x24.h | ||
vt220iso8x8.h | ||
vt220iso8x16.h | ||
vt220koi8x10.h | ||
vt220l8x8.h | ||
vt220l8x10.h | ||
vt220l8x16.h | ||
wsfont.c | ||
wsfont.h | ||
wsfontdev.c |