On Mon, Nov 06, 2023 at 07:59:39AM +0100, Christoph Hellwig wrote: > On Fri, Nov 03, 2023 at 01:38:13PM -0700, Darrick J. Wong wrote: > > On Fri, Nov 03, 2023 at 05:02:10PM +0100, Christoph Hellwig wrote: > > > Clean up the code in hash.c to use the normal char type for all > > > high-level code, only casting to uint8_t when calling into low-level > > > code. > > > > > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > > > > The problem is deeper than just this, but we gotta start somewhere... > > Is it that much bigger? > > Beѕides the usual problem of casts hiding bugs I think we are fine, > but please double check: > > - the lowlevel xfs directory entry hashing code assumes unsigned > chars, because of that we long compiled with -funsigned-char just > for XFS, which got obsoleted by the kernel doing it entirely > after we've switched all the low-level code to use unsigned > char. > - given that traditional unix pathnames are just NULL terminate > by arrays and the 7-bit CI code doesn't even look at the > high bit we really don't care about signed vs unsigned except > for the usual C pitfall when casting or shiftting > > So as long as all the low-level code uses unsigned char we should > be fine. I'll go take a look, though that might take a day or two. --D
