On Tue, Sep 04, 2012 at 04:26:32PM +0100, Jon Medhurst (Tixy) wrote: > On Tue, 2012-09-04 at 16:10 +0100, Peter Maydell wrote: > > On 4 September 2012 15:57, Jon Medhurst (Tixy) <tixy@xxxxxxxxxx> wrote: > > > diff --git a/string.h b/string.h > > > new file mode 100644 > > > index 0000000..f1aebdf > > > --- /dev/null > > > +++ b/string.h > > > @@ -0,0 +1,16 @@ > > > +#ifndef STRING_H > > > +#define STRING_H > > > + > > > +#include <stddef.h> > > > > I guess to be fully consistent we should provide our own > > stddef.h and stdint.h, but if it's not causing problems it's > > not worth the effort. > > That was my thinking, especially as the definitions might depend on > non-standard types and toolchain version - let sleeping dogs lie ;-) > > > > + > > > +extern void *(memcpy)(void *__dest, __const void *__src, size_t __n); > > > > I was going to complain about the weird parens around function > > names and inconsistent use of __ prefix on parameter names, > > but I see these all come straight from the existing string.c, > > so never mind :-) > > Yes, I thought they looked weird too, but I just copied the non-static > function prototypes straight out of string.c. The parentheses are there to suppress some inline macro expansions which happen if you build the GCC headers with optimisation turned on. We really should have our own versions of the relevant headers, but I avoided it out of laziness, on the assumption that we could fix it as needed. The nonstandard types are there out of simplicity/laziness ... this was never intended to remotely resemble a C environment. Since almost C types are equivalent to int or unsigned anyway, the simplified types "work". In a freestanding environment which isn't supposed to be C it would probably be overkill to define all the types, but it could be done if needed. Cheers ---Dave _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
