This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: seekdir dereferences null
> -----Original Message-----
> From: duane ellis [mailto:duane-newlib@duaneellis.com]
> Sent: Friday, December 05, 2008 14:07
> To: Schwarz, Konrad
> Cc: Eric Blake; newlib@sources.redhat.com
> Subject: Re: seekdir dereferences null
> Two well known quick examples are: ARM7 does not, CortexM3 do
> not have
> MMU/MPU support.
Uh, I beg to differ. See chapter 9, "Memory Protection Unit",
in DDI0337G_cortex_m3_..._trm.pdf. Also, see chapters B3 and B4
(about the standard MMU and MPU in ARMv4/5) in DDI0100e_arm_arm.pdf.
While there are processors out there that don't have
this support, my feeling is they are dying out. In fact,
I recently read an interview with the CEO of ARM, where the
interviewer "scolded" ARM for trailing the competition (I think
NIOS was used as an example) in memory protection support.
> An MPU/MMU also implies there is an operating system that configured
> them, newlib is an extremely common "bare metal" standard
> library where
> there is no such thing.
> Then there are many cases where the OS does nothing with the
> MMU/MPU -
> For example: "ThreadX" and "uC/OS-II" and others
In those processors I have looked at (admittedly not every one),
it is possible to set up the MMU/MPU independently of the
operating system. Consider an MPU: this is basically a set of
range registers that define the allowed access ranges. The
registers can be statically initialized.
Modern embedded processor TLBs with variable page sizes have enough
entries to use them like an MPU, except that typically special
instructions are needed to write to the TLB; MPU registers are
normally memory mapped.
<rant>
A lot of embedded software makes poor use of the
hardware available to it. People need to RTFM more.
</rant>
> Secondly - assert()
>
> While, "assert" is viable - the problem is it *GOES*AWAY*
> when debug is
> disabled.
>
> That is why - I suggested the "#if
> defined(PARMCHECKING_ENABLED) to keep
> it enabled!
NDEBUG does not need to be identical for every translation unit.
You can compile the library differently from the application.
In fact, I wouldn't be surprised if it were legal to use different
values within a single translation unit by re-including <assert.h>
after every change. As it turns out, it is: C99, 7.2: "The assert()
macro
is redefined according to the current state of NDEBUG each time
that <assert.h> is included".
<some more rant>
This is an example of the same thing. Instead of using existing
mechanisms, people invent new stuff, often awkward.
<sorry about that>
Regards,
Konrad