From mboxrd@z Thu Jan 1 00:00:00 1970 References: <03dd9a6798effc7cf713d579f6bbc0e6@isd.dp.ua> <636BFA64-E5C9-417C-AD9E-E6BCEAACB02B@gmail.com> <51AF3F6A.8000605@gmx.de> From: Don Bailey Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <6E52B34A-D48E-4656-9B28-09B3363560CA@gmail.com> Date: Wed, 5 Jun 2013 08:29:25 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [9fans] lpdaemon Topicbox-Message-UUID: 63bf9052-ead8-11e9-9d60-3106f5b1d025 You get that I'm talking about the subsequent read back after copy, right? N= o need to be so competitive :) Also, you're making strange presumptions about me having presumptions. I'm n= ot trying to say you're wrong or a poor coder, Erik. I was simply offering m= y point of view. Before this thread dissolves into typical Plan 9 waste I'll admit that my fi= rst mistake was to make the poor decision to reply to a 9fans email.=20 D On Jun 5, 2013, at 8:09 AM, erik quanstrom 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. >=20 > wrong. strncpy only copies up to the specified maximum. > the code is ugly but correct. >=20 >> 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. >=20 > 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. >=20 > that sounds like equivocation to me. the code is correct. > and in all cases nul-terminated, and any unused bytes are > 0. >=20 > 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. >=20 > - erik >=20