On Thu, 26 Jun 2025, Joseph Myers wrote: > On Thu, 26 Jun 2025, Richard Biener wrote: > > > The following prototypes diagnostics for conversions to/from time_t > > where the source/destination does not have sufficient precision for it. > > I've lumped this into -Wconversion for the moment and didn't bother > > fixing up the testcase for !ilp32 or the -Wconversion diagnostics that > > happen. > > > > Would -Wtime-conversion (or -Wtime_t-conversion?) be an appropriate > > option? I'd enable it with -Wconversion. > > 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. Any suggestion for an attribute name? no_implicit_truncation? full_precision (when widenings should be diagnosed)? > Such an attribute would of course be preserved by e.g. "typedef time_t > my_time_t;". It would need composite type rules defined (probably the > composite type has the attribute if either of the two types does), and > rules for what happens to the attribute in integer promotions / usual > arithmetic conversions (I'm guessing that given "time_t x;", it's desired > to warn about truncation of x+1, for example, so the process of applying > usual arithmetic conversions to determine the type of x+1 should not have > lost the attribute; what's less clear is e.g. x+1LL if time_t is narrower > than long long). Hmm. Yes, I did think about following typedef chains. It's of course unhelpful when people do int64_t tem = <.. some time_t expr ..>; int time = tem; 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) Richard.
