On Fri, 27 Jun 2025, Richard Biener wrote: > > I think such a warning should be based on an attribute on the time_t type > > that means "warn for implicit truncation of this type" (I'm less clear on > > why warnings for implicit widening conversions *to* time_t are supposed to > > be useful), rather than hardcoding it to be based on the time_t name. > > It's hardly just time_t for which a warning about such implicit truncation > > might be useful. > > I agree it might be better to have a more general facility. As of > the widening conversions to time_t, this is what the PR requested. > I guess it might catch Y2038 issues where truncations are not > visible, but I only have the artifical testcase from the PR.
The warnings for widening conversions seem to have been requested in a comment by someone other than the PR author, a long time after the PR was originally submitted, and then the PR summary edited to match. I tend to think they should be considered as a separate issue from warning for implicit truncation. > Any suggestion for an attribute name? no_implicit_truncation? > full_precision (when widenings should be diagnosed)? no_implicit truncation seems reasonable. > so catching Y2038 problems solely by diagnosing conversions is > incomplete. I was hoping that time_t + 1 gets us a time_t result > and not a 'long', but in the end that's the very same issue as > with an explicit 'long' temporary like above. So maybe the > complexity with handling the cases you outline above can be > waived for an initial attemt (it's definitely over my C/C++ frontend fu) My guess at the preferable language design is that the usual arithmetic conversions should preserve the attribute, meaning truncation of time_t + 1 does get the warning. It's a bit less clear what should be done when the arithmetic produces a result wider than time_t (time_t + __int128, for example). The simple thing is to preserve the attribute so any truncation of that wider expression is warned for (even just truncating back to the width of time_t). There is also an argument for preserving the information about the width of the (widest) type that originally had the attribute and went into the arithmetic, and only warning when truncating to narrower than the original width, but that would be rather more complicated. -- Joseph S. Myers josmy...@redhat.com
