On 31 Aug 2016 at 17:41, Mark Rutland wrote: > > The plugin marks them actually const, so the const_cast() is needed to > > "forget" that marking and treat it as a normal variable. (And PaX Team > > noted that this is the name used in C++ already.) > > From having a look around, my understanding is that with C++ this is > only valid if the underlying object is not const (i.e. it's only valid > to remove constness from a pointer or reference which had itself added > constness to a non-const object). > > I see that GCC is happy to constant-fold function pointers in const > objects it has visibility of; example below. Making the objects > themselves const is bound to lead to fragility (e.g. static inline > functions in a header behaving differently from related functions in > another file). > > Have I misunderstood something?
it's all correct but it's also not what PaX does for exactly this reason. instead we only constify types where no global variable instances are accessed directly. for directly accessed global variables we use __read_only and pax_open/close_kernel calls. ideally, this should be done for all cases and then const_cast would no longer be needed however that requires some non-trivial work on the plugin side.
