Hi, More noise: a typo alert below:
On Tue, Oct 9, 2018 at 5:14 PM Selva Nair <selva.n...@gmail.com> wrote: > Hi > > On Tue, Oct 9, 2018 at 4:39 PM Steffan Karger <stef...@karger.me> wrote: > >> Hi, >> >> On 08-10-18 18:09, Lev Stipakov wrote: >> > From: Lev Stipakov <l...@openvpn.net> >> > >> > In Visual Studio when unary minus is applied to unsigned, >> > result is still unsigned. This means that when we use result >> > as function formal parameter, we pass incorrect value. >> >> Good catch. I had to look it up, but I think this is actually undefined >> behaviour. 6.5 point 5 of C99 says: >> >> "If an exceptional condition occurs during the evaluation of an >> expression (that is, if the result is not mathematically defined or not >> in the range of representable values for its type), the behavior is >> undefined." >> >> Remarkably, even with -Wall -Wextra -pedantic, GCC 7.3 does not throw >> any warnings. But some tests show that GCC does what one might expect >> when reading this code: cast to a signed value. >> > > In fact the issue here is not the unary minus, but the unsigned to signed > conversion. So when there is no scope for overflow all is good. If there is > overflow, unsigned->signed conversion is ill-defined -- cast doesn't fix > it. In fact the cast is meaningless here (see more on that below): > > Although C99 std does not seem to be explicit about unary minus of > unsigned, the practice in C even before that was to subtract the number > from the largest possible value and add 1: as in K&R A7.4.5 (p. 204 in my > copy): > > "If the operand is unsigned, the result is computed by subtracting the > value from the largest value of the promoted type" > > So unary minus of unsigned itself is well-defined. Actually even the unary > minus of unsigned is computed using the above rule for signed: > Typo alert: signed and unsigned inverted in the last sentence, in case anyone really read all that.. > "If the operand is signed, the result is computed by promoted operand to > its unsigned type, applying -, and converting back to the signed type".!! > > So what the cast achieves is a an additional iteration of conversions > which gains nothing. > > >> I'm just not sure whether we should add casts, or stop using the 'hack' >> of supplying a negative value to frame_add_to_extra_frame. Maybe we >> should add a frame_remove_from_extra_frame function instead. What do you >> think? >> > > If the logic could be changed that should be preferred. > > Selva >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
