Google Code Exporter
Google Code Exporter
``` This is good to know -- thanks for doing the tests. DEEPBIND indeed can cause trouble -- I've had problems with it before. Though given test 3, it looks...
``` In my testing, we saw some problems when compiling with -O2, with using __etext. Based on that and the results you showed with dlopen(), I think it's premature to...
``` Yeah, I think etext might end up being a dead-end. In testing on my Ubuntu 11.10 machine, literal strings aren't actually being put into the .text section at all....
``` The documentation says this: --- You may use this built-in function in either a macro or an inline function. However, if you use it in an inlined function and...
``` The three sections are ordered: .text [gap] .rodata .data On the older RHEL5 system, there is no .rodata, so it's simply: .text [gap] .data So yes, the existing code...
``` Hmm, an interesting idea. However, I think this is best done as a pre-processing step -- you could use a simple grep command (under unix, it would be something...
``` Let me mention safe-by-default/design again. ;) Calling such a function once is simple. Once there, the check will always be done. Manually calling grep is more work likely to...
``` This is a fair point, but it's also true that it's easy to forget to call the function. Presumably you'd make the grep/etc part of your build workflow (a...
``` > but it's also true that it's easy to forget to call the function. You could enable the error or warning by default to combat that. > Presumably you'd...
``` Please? ``` Original comment by `olafvdspek` on 4 Oct 2011 at 10:31