Nor is it a bug that they're applied to the file rather than stored in
some magic secret database where they survive reinstalls, which the
prior wording seems to suggest was the eventual intention.
It is worth noting that they change the target file, so still say that.
Tell the user how to list flags right away, not at the very end.
Do not repeat "for the program" 6 times for each flag letter, it's a
noise by itself already and the italics of .Ar program exacerbates it.
Make the list of flags compact but manually add breaks between the
pairs of enable/disable flags.
binutils-2.19.1 tries to create one note section for all adjacent loadable
note sections, instead of the old behavior where each note is in its own
section. The fix looks at the section headers instead of the program headers
for the note.
avoid wasting OS flag bits. In the future we'll probably use fileassoc to
achieve this (once there is a way to make fileassoc persistent) or in the
shorter term libelf, so that we can add and remove the note on demand instead
of burning bits on each binary. Of course since this is a tool, this means
that we'll need to think about how to handle libelf...
by christos@. The comment reads:
# This program is set 0550 because, as security(8) states, it has
# the potential to deplete kernel memory, under certain conditions.