On 20/03/2015 17:47, Isaac Dunham wrote:
I'm not sure I follow you on the malloc/free/realloc bit:
-as far as I know, getenv() does not malloc() anything, but returns
the numeric value of a pointer within char ** environ

 getenv() is not a problem indeed. (Reading is rarely a problem,
it's writing that's tricky.)


-according to the manpage, putenv() does not copy the string, but
modifies environ by inserting a pointer to the string.
If the environ buffer is too short, environ may be expanded by
calling realloc() - is this what you refer to?

 Yes, partly. But you would *also* have to copy the string. You
cannot have an environment variable pointing into a temporary buffer,
that you may overwrite on subsequent reads. Sure, it's very unlikely
to happen, given the kind of data coming out of the netlink, but you
cannot guarantee it won't. Generally, you don't want to store pointers
to short-lived storage.


since I'm using pointers into msgbuf.

 I don't think you can do that safely. You can use pointers into
msgbuf for the current event's lifetime, because nothing's going to
overwrite msgbuf during that span; but the environment is more
permanent.


I'm thinking that it may make sense to use
        getkey(char *key, char *buf, size_t n);
in places that use
        getenv(key);

 Yes, I think it's the right solution. Don't tie your key-value store
interface to a given implementation. :)


I should probably replace the memset() before read() with
msgbuf[len] = 0; after read().

I was just using a hammer to deal with strlen possibly overrunning
the buffer, should we ever read something that ends with a partial
KEY=VAL pair and no NUL terminator.

 The function you're looking for is strnlen().


[ circular buffer code ]
If that's desired, someone else will need to do it.

 I already have that code in skalibs. But as I said, I'm not going
to skalibsify busybox - as much as I'd like it, it is too slippery
a slope.


I waited as long as I did in hope that someone else would pick it up.

 Same here. Thanks for being even less patient than I am. ;)

--
 Laurent

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to