*From*: Owen Taylor <otaylor redhat com>*To*: Sven Neumann <sven gimp org>*Cc*: drlion-dated-1091219837 02c327 teepee ath cx, gtk-devel-list gnome org, Jan Kratochvil <lace jankratochvil net>*Subject*: Re: MATH_MOD: Include in GLib?*Date*: Mon, 26 Jul 2004 11:17:48 -0400

On Mon, 2004-07-26 at 06:41, Sven Neumann wrote: > Hi, > > Jan Kratochvil <lace jankratochvil net> writes: > > > On Mon, 26 Jul 2004 10:43:21 +0200, Sven Neumann wrote: > > > Daniel Brockman <drlion deepwood net> writes: > > ... > > > > #define MOD(x, m) ((x) >= 0 ? (x) % (m) : (m) + (x) % (m)) > > ... > > > If at all it would have to be G_MOD(x). But I doubt that > > > the semantics of such a macro are obvious enough and that it would be > > > of general usefulness. > > > > I consider this macro as a generally used workaround of a bug in C standard. > > I intuitively expect the result of "x%m" will be 0..(m-1), not the C result > > of -(m-1)..(m-1). It has similiar position as G_N_ELEMENTS(). > > The result of "x%m" will be 0..(m-1) provided that you respect the > fact that the modulo operator is undefined on negative operands. The > behaviour is machine-dependent and you should simply avoid to use > modulo with signed variables. Are you sure about this? In my understanding, the C standard defines division as truncation towards zero. And then defines: a % b == a - b * (a / b) Regards, Owen

**Attachment:
signature.asc**

**Follow-Ups**:**Re: MATH_MOD: Include in GLib?***From:*Dave Benson

**References**:**MATH_MOD: Include in GLib?***From:*Daniel Brockman

**Re: MATH_MOD: Include in GLib?***From:*Sven Neumann

**Re: MATH_MOD: Include in GLib?***From:*Jan Kratochvil

**Re: MATH_MOD: Include in GLib?***From:*Sven Neumann

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