https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #11 from Tomas Kalibera <tomas.kalibera at gmail dot com> --- (In reply to LIU Hao from comment #10) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > > Thanks for the patch. Updated locally. I will test it against trunk as soon > as I get a little time. Thanks. Re Jeff's comment from the mailing list: > I guess we're going to depend on the builtin-format always appearing > first in the chain? While it's probably true in practice, I doubt we > really want to depend on that. > > Is there any sensible way to distinguish between the builtin format and > one that comes from the source? I didn't find any elegant way to find out whether a format attribute is a built-in attribute in check_function_format(). So unless I overlooked something (which is very much possible), it would make the patch more intrusive. handle_format_attribute() has that information in flags (ATTR_FLAG_BUILT_IN). Maybe handle_format_attribute() could add the flags (or only a boolean whether it is a builtin attribute) to the attribute tree, so that check_function_format() can access it, e.g. similarly to how no_sanitize does it. Would this be better? And if so, is there a recommended place in the format attribute tree where it should be added to?
