On Fri, Mar 20, 2015 at 10:09:59PM +0100, Laurent Bercot wrote: > On 20/03/2015 17:47, Isaac Dunham wrote: > >I'm not sure I follow you on the malloc/free/realloc bit: <snip> > >-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.
Out of curiousity: why would it be unsafe if you call clearenv() before overwriting that buffer? > >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. :) Thanks. Just in case you're suggesting something that allows using the unmodified contents of a uevent file: it isn't really practical to use a storage method that doesn't have each value ending with a \0, since we will be using string comparisons and don't want to call strdup()-type stuff on reads. > >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(). Ah yes. That should work. Thanks, Isaac Dunham _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
