Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

[milter-greylist] ignoring message beyond maxpeek

[milter-greylist] ignoring message beyond maxpeek

2016-11-30 by Bruncsak, Attila

Hello,

I received the message "ignoring message beyond maxpeek" once a day
and could not associate with any message,
due to missing queueid in the log.

After some debugging I figured out where was this coming from.
On the mean time I fixed the type of priv->priv_maxpeek,
which should be size_t and not int.
Some other, related  cosmetics are in the attached patches.

Best,
Attila

Attachments

Re: [milter-greylist] ignoring message beyond maxpeek [2 Attachments]

2016-12-01 by manu@...

'Bruncsak, Attila' attila.bruncsak@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> After some debugging I figured out where was this coming from.
> On the mean time I fixed the type of priv->priv_maxpeek,
> which should be size_t and not int.

The printf should use %zu now, but that is C99 syntax. How compatible is
it with various systems that build milter-greylist?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

RE: [milter-greylist] ignoring message beyond maxpeek

2016-12-01 by Bruncsak, Attila

> > After some debugging I figured out where was this coming from.
> > On the mean time I fixed the type of priv->priv_maxpeek,
> > which should be size_t and not int.
> 
> The printf should use %zu now, but that is C99 syntax. How compatible is
> it with various systems that build milter-greylist?
> 

This change wasn't from the printf(),
rather from assignments to that variable
which already has the type size_t:

priv->priv_maxpeek = conf.c_maxpeek;
in milter-greylist.c
where:
 size_t c_maxpeek;
in conf.h

The other option would be to change
c_maxpeek to have type int.

Re: [milter-greylist] ignoring message beyond maxpeek

2016-12-01 by Greg Troxel

"manu@... [milter-greylist]" <milter-greylist@yahoogroups.com>
writes:

> 'Bruncsak, Attila' attila.bruncsak@... [milter-greylist]
> <milter-greylist@yahoogroups.com> wrote:
>
>> After some debugging I figured out where was this coming from.
>> On the mean time I fixed the type of priv->priv_maxpeek,
>> which should be size_t and not int.
>
> The printf should use %zu now, but that is C99 syntax. How compatible is
> it with various systems that build milter-greylist?

Does anybody still use systems that don't have a reasonable way to use
C99?   I would be in favor of just declaring C99 a requirement.


As a data point, I worked on a project that was trying to be very
portable.  We picked C99 as the base standard.  It was pretty much ok,
with a minor exception of a compiler that objected to mixed
declarations/code (vs. the C89 requirement to have all decls first).
This compiler was from MS, and it was acknowledged to be old.

So, in the free software world, I don't see any reason to avoid assuming
C99.

Re: [milter-greylist] ignoring message beyond maxpeek

2016-12-01 by Bob Friesenhahn

On Thu, 1 Dec 2016, Greg Troxel gdt@... [milter-greylist] wrote:
>>
>> The printf should use %zu now, but that is C99 syntax. How compatible is
>> it with various systems that build milter-greylist?
>
> Does anybody still use systems that don't have a reasonable way to use
> C99?   I would be in favor of just declaring C99 a requirement.

I can't speak to users, but an issue with C99 is that part of the 
functionality comes from the compiler and part from the system 
libraries.  The compiler is often easily updated but the system 
libraries may be set in stone and not support C99 features.  The %zu 
syntax would be coming from system libraries.

Milter-greylist likely does not care about Microsoft compilers but %zu 
syntax has been a problem there until almost recent compilers.  With 
Microsoft, newer compilers produce output which do not run on older 
systems that many people are still using.

If C99 is a requirement, then the milter-greylist code should be 
substantially updated to take advantage of beneficial features.

Bob
-- 
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.