FYI, We are having serious issues (reboots, etc) on the project that
generated this bug report, and cannot appear to find any
pointer/bounds issues that would cause that type of behavior. We've
removed most all of the operational code. Of course, we are building
on an arbirary version of
As Steve Franks wrote:
FYI, We are having serious issues (reboots, etc) on the project that
generated this bug report, and cannot appear to find any
pointer/bounds issues that would cause that type of behavior.
However, just to remind you, the subject of this bug report is
*solely* to fix the
However, just to remind you, the subject of this bug report is
*solely* to fix the slightly misleading picture in the docs that made
you think __malloc_heap_end were an address when it is actually a
variable pointing to an address.
That's what I recalled. Eric's upgrade to immediate importance
Probably if the pictures had
*__malloc_heap_end == __heap_end
instead of
__malloc_heap_end == __heap_end
that would do the trick. At least in my mind.
Steve
On 3/29/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
Update of bug #19445 (project avr-libc):
Category:
As Steve Franks wrote:
Probably if the pictures had
*__malloc_heap_end == __heap_end
instead of
__malloc_heap_end == __heap_end
that would do the trick. At least in my mind.
It has a point, but it's not very exact either: it suggests
__malloc_heap_end were a pointer which
It has a point, but it's not very exact either: it suggests
__malloc_heap_end were a pointer which it isn't.
You did earlier say 'it's a variable that points to heap_end', however.
Hence the confusion, I think?
Steve
___
AVR-libc-dev mailing list
