Hi Jeremy,
Hi Ian,
On 2023-09-28 18:03, Jeremy Harris wrote:
> On 28/09/2023 18:37, Ian Z via Exim-users wrote:
> > I checked with `nm` and on this platform, at least, the
> > lmtp code seems not to make it into the final executable. So the
> > linker does its job, and all is explained. The redundant compile is
> > still a bit suboptimal but I understand that we don't want to mess
> > with the build setup.
>
> I started spraying #ifdef everywhere... and then found that lookups
> are handled (for this purpose) by script-hacking on the sub-makefile.
> So (eventually) I might get around to doing similar for
> all of routers, transports, authenticators.
>
>
> > I would probably do the %Y thing differently ... but I'll cope.
>
> One might argue that labelling these functions printf-like is not
> valid, when they do different things. But GCC is running into the
> identical issue what handling extensible-printf functions...
I'm maintaining the Exim package for the OpenWrt distribution -- admittedly
not the most mainstream use-case for Exim, but anyway ;)
Preparing the (long overdue) update to version 4.97.1 (coming from 4.96.2)
I've noticed that the %Y format warning issue discussed here has not
really been resolved and I was wondering what is the recommended way to
go about it.
Disabling all format security warnings doesn't really seem to be the
best idea, especially also as they are deliberately enabled in other
places in the build, even with -Werror.
Also, doing so augments the only meaningful format security warning,
which is probably the reason it has not been dealt with up to now:
smtp.c: In function 'invalidate_ehlo_cache_entry':
smtp.c:941:42: warning: format '%d' expects argument of type 'int', but argument 2 has type 'time_t' {aka 'long int'} [-Wformat=]
941 | debug_printf("ehlo-resp record is %d seconds old\n", time(NULL) - er->time_stamp);
| ~^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| int time_t {aka long int}
| %ld
A good solution would be to use difftime(3) with %.0f format instead
and I'm about to send a patch doing that.
Given all the excessive fallout of commit 00392be0e ("Support gring as
a first-class conversion specifier in internal string-formatting") I'm
tempted to work on reverting that for our builds. However, that by now
has become non-trivial so in case Ian could maybe share his patch
mentioned earlier in this thread, that would be great.
Cheers
Daniel
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
