Messages in this thread | | | Date | Thu, 13 Jan 2005 23:52:22 +0100 | From | Han Boetes <> | Subject | Re: propolice support for linux |
| |
Ulrich Drepper wrote: > Aside from all the arguments about why this patch isn't good for > the kernel, everybody should be aware that the ProPolice gcc > patches are pretty unusable. They rely in recognizing certain > tree patterns which for some architectures do not exist, and for > others can look differently, depending on the optimization. To > paraphrase one of the gcc developers: "this kind of > functionality should be written to work _with_ gcc, not > _against_ it as the propolice patch does". > > Before you suggest using something like this patch you better > first inform yourself by asking the people who actually know the > code which is modified.
Ok I have a problem here. You are Ulrich Drepper and you are _the_ maintainer of glibc and I am Han Boetes and I am a C noob. It's like Kasparov trying to explain something to a club-chess-player.
I'm afraid that whatever explanation you give to me is over my head, you'll feel like talking to a dummy and I'll be terribly unsatisfied.
To avoid that I would like to ask you if you can show me some example-code, something I which can compile and run and see for myself, for the following situations:
1) Where an application compiled with PP is working worse or even failing where it would work right without PP.
2) Where a bufferoverflow can be exploited even though the application is compiled with PP.
As an example where PP does work right the test-code provided by the propolice maintainer:
/* test-propolice.c */ #define OVERFLOW "This is longer than 10 bytes" #include <string.h> int main (int argc, char *argv[]) { char buffer[10]; strcpy(buffer, OVERFLOW); return 0; }
# Han - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |