jsparkes@bwdls49.bnr.ca (Jeff Sparkes) (05/11/91)
It's dereferencing a null menu pointer. If you have menus on more than one button: hold one down, and then press a button that brings up another menu. Boom! -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 Never trust a psychic who hasn't won the lottery. Twice.
stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (05/11/91)
In article <jsparkes.673896965@bwdls49>, jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: |> |> It's dereferencing a null menu pointer. If you have menus on more |> than one button: hold one down, and then press a button that brings up |> another menu. Boom! That's gross! How about the following fix. -- Andreas Stolcke stolcke@icsi.berkeley.edu International Computer Science Institute stolcke@ucbicsi.bitnet 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126 *** menus.c.dist Tue Apr 23 07:17:14 1991 --- menus.c Fri May 10 17:32:06 1991 *************** *** 569,576 **** } ! /* if we haven't recieved the enter notify yet, wait */ ! if (ActiveMenu && !ActiveMenu->entered) continue; done = FALSE; --- 569,576 ---- } ! /* if we haven't received the enter notify yet, wait */ ! if (!ActiveMenu || !ActiveMenu->entered) continue; done = FALSE;
mrm@nss1.com (Michael R. Miller) (05/15/91)
In article <1991May11.004433.14527@agate.berkeley.edu> stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) writes: >In article <jsparkes.673896965@bwdls49>, jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: >|> >|> It's dereferencing a null menu pointer. If you have menus on more >|> than one button: hold one down, and then press a button that brings up >|> another menu. Boom! > >That's gross! How about the following fix. > >-- >Andreas Stolcke stolcke@icsi.berkeley.edu >International Computer Science Institute stolcke@ucbicsi.bitnet >1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126 > >*** menus.c.dist Tue Apr 23 07:17:14 1991 >--- menus.c Fri May 10 17:32:06 1991 >*************** >*** 569,576 **** > > } > >! /* if we haven't recieved the enter notify yet, wait */ >! if (ActiveMenu && !ActiveMenu->entered) > continue; > > done = FALSE; >--- 569,576 ---- > > } > >! /* if we haven't received the enter notify yet, wait */ >! if (!ActiveMenu || !ActiveMenu->entered) > continue; > > done = FALSE; This is not a correct solution. C compilers are NOT constrained to resolve the '||' test in any particular order resulting in the test "!ActiveMenu->entered" possibly being accomplished prior to the checking of the validity (non-NULLness) of ActiveMenu. This can still core dump if compiled under some C compilers. Presuming the intent of the test is correct, _A_ correct way to implement this test is: if (!(ActiveMenu && ActiveMenu->entered)) continue; There isn't enough context here to determine if the intent of the test is correct or not. A guess would be that the intent is valid but that's only a guess. Michael R. Miller XZaphod: uunet!xzaphod!michael
kucharsk@solbourne.com (William Kucharski) (05/16/91)
In article <1991May15.094059.8696@nss1.com> mrm@nss1.com (Michael R. Miller) writes: >This is not a correct solution. C compilers are NOT constrained to >resolve the '||' test in any particular order resulting in the test >"!ActiveMenu->entered" possibly being accomplished prior to the >checking of the validity (non-NULLness) of ActiveMenu. This can >still core dump if compiled under some C compilers. Wrong; if your compiler does resolve the second reference it's broken. From page 191 of K&R: "The || operator groups left-to-right. It returns 1 if either of its operands is non-zero and 0 otherwise. Unlike |, || guarantees left-to-right evaluation; moreover, the second operand is not evaluated if the value of the first operand is non-zero." BTW, the same thing (except the second operand is not evaluated if the first argument is 0) applies for the "&&" operator. -- | William Kucharski, Solbourne Computer, Inc. | Opinions expressed above | Internet: kucharsk@Solbourne.COM | are MINE alone, not those | uucp: ...!{boulder,sun,uunet}!stan!kucharsk | of Solbourne... | Snail Mail: 1900 Pike Road, Longmont, CO 80501 | "It's Night 9 With D2 Dave!"
stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (05/16/91)
In article <1991May15.094059.8696@nss1.com>, mrm@nss1.com (Michael R. Miller) writes: |> In article <1991May11.004433.14527@agate.berkeley.edu> stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) writes: |> >! /* if we haven't received the enter notify yet, wait */ |> >! if (!ActiveMenu || !ActiveMenu->entered) |> > continue; |> |> This is not a correct solution. C compilers are NOT constrained to |> resolve the '||' test in any particular order resulting in the test |> "!ActiveMenu->entered" possibly being accomplished prior to the |> checking of the validity (non-NULLness) of ActiveMenu. This can |> still core dump if compiled under some C compilers. |> |> Presuming the intent of the test is correct, _A_ correct way to |> implement this test is: |> |> if (!(ActiveMenu && ActiveMenu->entered)) |> continue; |> Don't believe it. If your C compiler does not evaluate || strictly left to right (or evaluates the right operand even though the first one is != 0) you better get a new compiler. Look it up in any C reference manual (K+R, ANSI, what have you). That's the whole *point* in having || (and &&) next to | (and &). The alternative solution you proposed makes use of the same principle, mutatis mutandis for the `&&' operator. -- Andreas Stolcke stolcke@icsi.berkeley.edu International Computer Science Institute stolcke@ucbicsi.bitnet 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126