Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 04 Aug 2015 18:01:51 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Ambiguous pointer increments

On 2015-07-28 00:23, magnum wrote:
> The beignet OpenCL driver complained about oldoffice kernel, "multiple
> unsequenced modifications to 'p'" for things like the below:
>
> -               for (i = 0; i < 32; i += 2)
> -                       W[i >> 1] = (uint)*p++ | (*p++ << 16U);
>
> I already changed it but I'm curious - no other driver complained.
>
> +               for (i = 0; i < 32; i += 2) {
> +                       W[i >> 1] = (uint)*p++;
> +                       W[i >> 1] |= (*p++ << 16U);
> +               }
>
> Originally I thought they (the use/increments of p) were guaranteed to
> be left-to-right but after this I'm not sure at all. Anyone know for
> sure? Alexander Cherepanov perhaps? In case it matters, OpenCL is C99.

Others already answered the question but I'd like add some notes.

1. The behavior is undefined even if there is only one modification of a 
variable in an expression but this variable is accessed in another place 
in this expression without being separated by a sequence point. E.g. 
i|i++ is prohibited.

2. There are several operators which introduce sequence points into 
expressions (in addition to function calls) -- && || , ?:

3. "*p++ << 16U" could result in undefined behavior in C99. *p is of 
type ushort (an unsigned 16-bit value according OpenCL spec). It's 
promoted to int (signed 32-bit value) before shifting and shifting it by 
16 bits can yield a value outside of representable range which is UB in 
C99. From a short look at OpenCL spec, OpenCL fully define bit shifts so 
it's ok in it. OTOH "16U" looks a bit suspicious. Perhaps its author 
thought that this will promote the left operand of << to unsigned int 
(similar to "(uint)" in the first part of expression) which it probably 
doesn't.

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ