On Tue, Oct 25, 2022 at 04:00:30PM -0700, Kees Cook wrote: > On Sun, Oct 23, 2022 at 10:23:56PM +0200, Gabriel Paubert wrote: > > On Sat, Oct 22, 2022 at 11:16:33AM -0700, Linus Torvalds wrote: > > > Practically speaking this might be a bit painful, because we've got > > > several different variations of this all due to all the things like > > > our debugging versions (see <linux/fortify-string.h> for example), so > > > some of our code is this crazy jungle of "with this config, use this > > > wrapper". > > > > I've just had a look at that code, and I don't want to touch it with a > > 10 foot pole. If someone else to get his hands dirty... > > Heh. Yes, fortify-string.h is a twisty maze. I've tried to keep it as > regular as possible, but I admit it is weird. On my list is to split > compile-time from run-time logic (as suggested by Linus a while back), > but I've worried it would end up spilling some of the ugly back into > string.h, which should probably not happen. As such, I've tried to keep > it all contained in fortify-string.h. > > Regardless, I think I'd rather avoid yet more special cases in the > fortify code, so I'd like to avoid using transparent union if we can. It > seems like -funsigned-char and associated fixes will be sufficient, > though, yes? I thought some of the motivation behind the transparent union was that gcc still treats `char` as a distinct type from `unsigned char`, so gcc's checker can still get upset and warn when passing a u8[] to a string handling function that expects a char[]. (Once the -funsigned-char changes go in, though, we should probably decide that s8[] is never a valid string.) Jason
