an easy way to help with footprint

[Alec Flett]

Hey, if there are any C or C++ hackers that want to contribute but
haven't found an easy way, here's an easy way to help.

In wandering around the code today, I discovered that there were vast
amounts of data in the html parsing library that resided in read-write
memory, that really could go into read-only memory. I filed
http://bugzilla.mozilla.org/show_bug.cgi?id=200330 with a fix. Also see
http://bugzilla.mozilla.org/show_bug.cgi?id=200139 for a simpler example.

The benefits of having stuff in the read-only section of a library include:
- data can be shared by multiple processes if two processes load the
same dll.
- the linker can better organize the sections to pack as much readonly
data into memory as possible
- on small devices, readonly data can be placed in ROM without fear of
it being paged into RAM

So here's how you can do this.. take a .so that you'd like to attack.
The bigger the .so the better.. do this trick:

first find all the candidates for const-ness:

nm libfoo.so | cut -b10- | grep -i "^[bd] " | c++filt | cut -d_ -f2- >
const-data

This will generate a list of candidate symbols for const-ness
(yes there are better ways to do this, but this works on both linux and
mac, and maybe others)

from there, you can search your code for those symbols:

find -name '*.h' -or -name '*.cpp' | xargs -n20 grep -w -n -f const-data

run this from inside emacs, and you can just Ctrl-` your way through the
list and examine if the given symbol should be made const.

If/when you find some good possibilities in a library, please file a bug
against the library, CC me, and attach a patch. I will gladly review.

A few guidelines: Requiring any kind of casting to account for your
const changing is the wrong approach. If done correctly, you will
probably be changing some APIs to account for the newly-found constness
of the data. The bugs quoted above are perfect examples. Ideally, you
should not have ANY extra casting as a result of this work.

Good luck!

Alec