[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210821141846.k4n4eorn4ifk5lfj@xps.yggdrasil>
Date: Sat, 21 Aug 2021 19:48:46 +0530
From: Aakash Hemadri <aakashhemadri123@...il.com>
To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Larry Finger <Larry.Finger@...inger.net>,
Phillip Potter <phil@...lpotter.co.uk>,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] staging: r8188eu: restricted __be16 degrades to
int
On 21/08/20 05:10PM, Fabio M. De Francesco wrote:
> Building on the objections you had from Greg I suggest that, before attempting
> anew to address problems like these, you get a better understanding of the topics of
> native and network endianness and of the API that (conditionally) swap bytes
> in a variable between little endian and big endian representation.
>
> To start with, please note that the following code leads to tests for "v.vub[0] == 0xDD"
> which is true on little endian architectures while "v.vub[0] == 0xAA" is true on big
> endian ones...
>
> union {
> u32 vud;
> u8 vub[4];
> } v;
>
> v.vud = 0xAABBCCDD;
>
> Also note that API like cpu_to_be32(), htonl(), be32_to_cpu(), ntohl, and the likes are
> used to (conditionally) swap bytes (i.e., change the arrangement of the bytes in a
> multi-bytes variable).
>
> Casts have very different purposes and usage patterns and, above all, they cannot
> magically change the endianness of a variable.
>
> Regards,
>
> Fabio
>
Thanks for the explanation Fabio!
Will rework and send it through!
Thanks,
Aakash Hemadri
Powered by blists - more mailing lists