public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Alan Huang <mmpgouride@gmail.com>
Cc: Carlos Maiolino <cem@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs_db: fix complaints about unsigned char casting
Date: Fri, 17 Mar 2023 13:29:20 -0700	[thread overview]
Message-ID: <20230317202920.GJ11394@frogsfrogsfrogs> (raw)
In-Reply-To: <BCCAE5EE-0A38-42B7-B60E-8C60814FE286@gmail.com>

On Fri, Mar 17, 2023 at 06:43:40PM +0800, Alan Huang wrote:
> Is there any reason keep these definition with different types?  Question from a newbie...

Probably not, but char* handling in C is a mess if you don't specify
signedness -- on some arches gcc interprets "char" as "signed char", and
on others it uses "unsigned char".  The C library string functions all
operate on "char *", so if you start changing types you quickly end up
in compiler warning hell over that.

libxfs seems to use "unsigned char*" and "uint8_t *".  I don't know if
that was just an SGI thing, or merely a quirk of the codebase?  The
Linux VFS code all take "char *", though as of 6.2 the makefiles force
those to unsigned everywhere.  As far as directory entry and extended
attribute names go, all eight bits are allowed.

UTF8 encoding uses the upper bit of a char, which means that we really
want unsigned to avoid problems with sign extension when computing
hashes and things like that, because emoji and kanji characters are in
use around the world.

IOWS: it's a giant auditing headache to research what parts use the type
declarations they do, figure out what subtleties go with them, and
decide on appropriate fixes.  And in the end... the system still behaves
the same way it did.

--D

> Thanks,
> Alan
> 
> > 2023年3月17日 下午6:25,Carlos Maiolino <cem@kernel.org> 写道:
> > 
> > On Tue, Mar 14, 2023 at 06:01:10PM -0700, Darrick J. Wong wrote:
> >> From: Darrick J. Wong <djwong@kernel.org>
> >> 
> >> Make the warnings about signed/unsigned char pointer casting go away.
> >> For printing dirent names it doesn't matter at all.
> >> 
> >> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > 
> > Looks good, will test.
> > 
> > Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
> > 
> >> ---
> >> db/namei.c |    4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/db/namei.c b/db/namei.c
> >> index 00e8c8dc6d5..063721ca98f 100644
> >> --- a/db/namei.c
> >> +++ b/db/namei.c
> >> @@ -98,7 +98,7 @@ path_navigate(
> >> 
> >> 	for (i = 0; i < dirpath->depth; i++) {
> >> 		struct xfs_name	xname = {
> >> -			.name	= dirpath->path[i],
> >> +			.name	= (unsigned char *)dirpath->path[i],
> >> 			.len	= strlen(dirpath->path[i]),
> >> 		};
> >> 
> >> @@ -250,7 +250,7 @@ dir_emit(
> >> 	uint8_t			dtype)
> >> {
> >> 	char			*display_name;
> >> -	struct xfs_name		xname = { .name = name };
> >> +	struct xfs_name		xname = { .name = (unsigned char *)name };
> >> 	const char		*dstr = get_dstr(mp, dtype);
> >> 	xfs_dahash_t		hash;
> >> 	bool			good;
> > 
> > -- 
> > Carlos Maiolino
> 

  reply	other threads:[~2023-03-17 20:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <yd5KB_VD7Oe2M-1JTpW8yKsKQ7SaQV9hnFIguCvPI-CuHqrQHOECUVh2Ar9oGpOi5jLK1LKpQ0D_NqN-kz5eyw==@protonmail.internalid>
2023-03-15  1:01 ` [PATCH] xfs_db: fix complaints about unsigned char casting Darrick J. Wong
2023-03-17 10:25   ` Carlos Maiolino
2023-03-17 10:43     ` Alan Huang
2023-03-17 20:29       ` Darrick J. Wong [this message]
2023-03-18 13:59         ` Alan Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230317202920.GJ11394@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mmpgouride@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox