Date: Fri, 23 Jan 2015 13:36:19 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Rui Paulo <rpaulo@me.com> Subject: Re: mount_smbfs Message-ID: <20150123213619.GP1949@funkthat.com> In-Reply-To: <ED004DCD-35B9-4F2E-9F5D-41BF33E66F01@bsdimp.com> References: <54B9DCD1.3040306@foxvalley.net> <4759EAA0-D4AA-4923-9350-B7E753819169@me.com> <6E32991C3BD8465DB8DB0E65DFDA47AA@ad.peach.ne.jp> <20150123195403.GO1949@funkthat.com> <ED004DCD-35B9-4F2E-9F5D-41BF33E66F01@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote this message on Fri, Jan 23, 2015 at 13:21 -0800:
>
> > On Jan 23, 2015, at 11:54 AM, John-Mark Gurney <jmg@funkthat.com> wrote:
> >
> > Daisuke Aoyama wrote this message on Sat, Jan 24, 2015 at 03:07 +0900:
> >> Quick hack patch is attached.
> >
> > Please use {l,b}e16dec, or if the code is suppose to be native endian,
> > make it dependant on __NO_STRICT_ALIGNMENT and add the proper endian
> > swap, not __arm__ as there are other arches that require the same fix...
>
> If there???s just a couple of places that need this, don???t bother making them dependent
> on __NO_STRICT_ALIGNMENT. That clutters things up a bit too much. Given the 3
> or 4 places this is used, and the relative infrequency of the calls, just doing a memcpy
> unconditionally is always correct and reduces the risk of one branch of the #if being
> changed w/o the other. Since it is already using NBENCODE(), I think that using
> {l,b}e16enc (not dec) would be a larger code churn.
Clearly neither of us looked at the code closely... NBENCODE should be
rewritten to take a pointer and use le16enc... Then memsetw should just
call NBENCODE internally as it goes...
Also, as this is in contrib, the patch should be submitted upstream...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150123213619.GP1949>