This seems to be a team project, with junior programmers involved. Since
the known bug (reference to invalid memory areas) is so blatent, I would
recommend code walk-thrus and other peer-review procedures be installed.
Make sure your entire team is using maximum error reporting using the
-Wall
Our application handles a non-global launch code (via an alarm). Someone has
inadvertently added a global flag to the code that handles the launch code. The code
in question only READS the global - it does not change it. I have demonstrated to
myself and my colleagues that this code cases a
Doesn't this amount to reading a value from an ill-defined location then
taking an action based on the value? Sounds like trouble brewing...
Dennis Leas
---
[EMAIL PROTECTED]
- Original Message -
From: Kevin OKeefe [EMAIL PROTECTED]
To: Palm Developer Forum [EMAIL
I realize we are reading from garbage. In this case whether we interpret the garbage
as true or false doesn't really matter (in terms of doing something potentially bad in
either case). I'm just wondering if the act of accessing the memory (which causes a
bus error on the emulator), will
I think the point is that not only is the value at the location garbage, but
the location being read from may change from invocation to invocation (or
the validity or reading from it may vary; not to be confused with the
validity of the data at the location). So sometimes it may give a bus
error,
Please, let me be clear here: we DO NOT think that this is ok - it is a bug that WILL
BE fixed. My problem is that the error is rare enough that fixing this and not seeing
the problem for a month does not guarantee that this was the cause of the error we are
seeing. I was hoping for some
The 68k really doesn't care about reading the wrong address, although you
could get an alignment fault by reading from an odd (as opposed to even)
address. I can't think of any I/O ports that will object to a random read,
although you could maybe clear some condition that hadn't been serviced
