You get that I'm talking about the subsequent read back after copy, right? No need to be so competitive :)
Also, you're making strange presumptions about me having presumptions. I'm not trying to say you're wrong or a poor coder, Erik. I was simply offering my point of view. Before this thread dissolves into typical Plan 9 waste I'll admit that my first mistake was to make the poor decision to reply to a 9fans email. D On Jun 5, 2013, at 8:09 AM, erik quanstrom <quans...@quanstro.net> wrote: >> You're absolutely correct if the length of value to be copied is not >> validated prior to the copy. Then, an invalid page could be hit if no >> nil is present within the array or beyond. > > wrong. strncpy only copies up to the specified maximum. > the code is ugly but correct. > >> To be verbose, my bypassing of strncpy is due to issues I've >> encountered in multi-threaded code. e.g. Don't trust libc copy >> functions in MT envs, always check post call. > > this sounds like your saying that because you had trouble in > a multithreaded unix application, then without examining the > code at hand, it is pronounced to have the same issue. > > that sounds like equivocation to me. the code is correct. > and in all cases nul-terminated, and any unused bytes are > 0. > > i only object to strncpy because it requires extra work. seprint, > snprint are a bit heavy weight but tend to produce cleaner looking > code. ymmv. > > - erik >
