Date: Mon, 11 Jun 2018 12:22:30 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334928 - head/lib/libc/stdlib Message-ID: <20180611092230.GB1939@kib.kiev.ua> In-Reply-To: <20180611141715.W1182@besplex.bde.org> References: <201806101754.w5AHsi4r061028@repo.freebsd.org> <20180611141715.W1182@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 11, 2018 at 03:48:52PM +1000, Bruce Evans wrote: > Change TYPE to unsigned char[sizeof(old TYPE)] and use memcpy() to assign > the variables to fix this with small churn and without the pessimizations > in this commit. This gives portable code back to K&R1978 + memcpy(), and > is as efficient as the above when the above works. On x86, even gcc-3.3 > produces a load and store for memcpy(p, q, sizeof(register_t)) when p and > q are void *. > > Change TYPE to unsigned char[n] and use a single memcpy() without a loop > to assign the variables to fix this with larger churn and with different > (smaller?) pessimizations than in this commit. Setup and initialization > for this method is also simpler. This uses the newfangled VLA feature, > and since n is variable for qsort(), builtin memcpy() with length n > doesn't work so well. Either results in the unacceptable stack use. I can limit the char[es] and memcpy to some value of es, but I do not see a point. I will not object if somebody decides to do it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180611092230.GB1939>