Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> Vandoorselaere Yoann <yoann@mandrakesoft.com> said:
> > This isn't *this* mythical function.
> > as i've already said, you LD_PRELOAD a library which provide a replacement
> > for dangerous function like strcpy...
>
> If strcpy(3) can check bounds, why on earth doesn't the libc one do so?
>
Probably because it is more slow ( + - 10% ).
>
> > Ps : i can't post the URL of the library i'm talking about...
> > i'm not allowed to until the press release is done.
> > And yes, it's LGPL'ed software :-)
>
> I'd really like to see it.
I'll post here when i'll be allowed to :-)
> Any way of doing as claimed I can think up
> offhand involve _massive_ slowdown, if they even work in all cases.
it work :-)
> BTW,
> gcc has this recently-aqcuired habit of inlining all sorts of functions,
> sometimes with quite a bit of help from the standard header files in
> glibc, so many of the targets for your replacement will be gone by the time
> the program runs.
Nope, we deal with that :)
<snip>
/*
* -------------- system library implementations -------------------
* Here is the story: if a C source file includes <string.h> and is
* compiled with -O, then by default strcpy() is expanded (to several
* memcpy()'s and a strcpy()) just like a macro. Thus, it is wise to
* bounds-check memcpy(). Furthermore, because the string "strcpy(,)"
* gets expanded even when the function is being declared, this code
* will not compile if optimized unless __NO_STRING_INLINES is defined
* (see the end of /usr/include/string.h). This is obviously a
* compiler/header-file specific thing. I am using gcc version
* egcs-2.91.66.
*/
</snip>
--
-- Yoann, http://prelude.sourceforge.net
It is well known that M$ products don't call free() after a malloc().
The Unix community wish them good luck for their future developments.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:15 EST