Paul Eggert wrote: > > I'm open to this. What prefix would you propose instead of 'x'? > > The usual English-language name for this sort of thing is "saturation > arithmetic", but SATURATED_ADD is kind of long. LLVM uses "sat" for saturated > operations, perhaps the prefix "SAT" will do.
Fine with me. > I could probably find uses for a new intprops.h macro INT_ADD_SAT (a, b) macro > that would behave like INT_ADD_WRAPV (a, b, r) except it would return a > saturated result instead of storing a wraparound-on-overflow result into *R > and > returning an overflow indicator. This would be more general than a size_t-only > approach. That would be nice: it would allow to write more complex expressions in a more natural way. > It would be a little tricky, though, since A and B might not be the > same type and then how does one define saturation? would it be relative to the > type of A+B? For unsigned types, saturation would be defined as "undefined value through overflow". The addition of an overflown 'unsigned short' and an in-bounds 'unsigned int' would be an overflown 'unsigned int' - since you don't know how many overflown 'unsigned short' have been summed into the first argument. For subtraction, I would not define anything - I see no use for subtracting possibly overflown values. Would you plan to support the concept for signed types as well? Bruno
