bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setproctitle()


From: Peter Seebach
Subject: Re: setproctitle()
Date: Tue, 04 May 2010 02:34:29 -0500

In message <address@hidden>, Jim Meyering writes:
>Thanks for volunteering.  Yes, this would be useful.
>There are many implementations floating around.

There are indeed a ton.

>Can you assign copyright to the FSF?

I think I can.  There is some ambiguity about the IP agreement at $dayjob,
but we do in general contribute some stuff to the FSF, so I can probably
route it through the open source contribution mechanism.

My thought is that the first step towards a setproctitle() implementation
is a pure stub.  The function returns void anyway, and I'm not aware of any
usage where anyone but a human user scanning the 'ps' list cares whether it
worked.  Then, specific implementations can be tweaked.

For BSD libc, of course, no implementation is needed.

For glibc, there is a beautiful bit of trickery available.  The
program invocation name really *is* argv[0], apparently.  You can
thus scan consecutive strings from there, until you find something
that aligns with environ[0], and have a pretty good guess that
you've found the length of the arguments...  If nothing's moved.
I'm not sure how to cleanly check whether anything has moved.  (The
key to this all is that you are allowed to generate a pointer one
past the end of an array, and even though you can't dereference
it, you can compare it to other pointers for equality/inequality,
though not for less-than/greater-than.  So if the address just past
the end of argv[argc-1] is the same address as environ[0], you can
iterate through a bit further checking for values that can be known
to be part of a contiguous block...

The alternative is to have something like setproctitle_init().  My
guess is that the ideal case would be to use setproctitle_init()
if possible, but if someone calls setproctitle() without doing so,
make reasonable guesses.

My original plan had been to release the ensuing code into the public domain
so that people could use it arbitrarily; in particular, I wanted to use it
with a hunk of code where I really don't want to create any license
interdependency issues...  I'm sort of torn here, because on the one hand,
I would love to see this in gnulib so people will stop needing to reinvent
it so much, but that does imply losing the right to use the code in
conjunction with, say, any of the proprietary stuff we sometimes ship.
Which would be inconvenient.  (More concretely, the program for which I
need this is LGPLv*2*.)

-s




reply via email to

[Prev in Thread] Current Thread [Next in Thread]