Wietse Venema:
> lst_ho...@kwsoft.de:
> > Zitat von Wietse Venema <wie...@porcupine.org>:
> >
> > > Victor Duchovni:
> > >> On Mon, Jan 17, 2011 at 02:56:57PM -0500, Wietse Venema wrote:
> > >>
> > >> > Well this is the code:
> > >> >
> > >> > psc_lowat_check_queue_length = .7 * var_psc_pre_queue_limit;
> > >> > psc_hiwat_check_queue_length = .9 * var_psc_pre_queue_limit;
> > >>
> > >> Is the compiler first converting 0.7 to an integer and *then* doing
> > >> the multiplication?
> > >>
> > >> That would violate the C arithmetic type promotion rules.
> > >
> > > Let's find out if var_psc_pre_queue_limit is non-zero.
> > >
> > > Andreas, I am very interested in your logging for var_psc_pre_queue_limit.
> >
> > Now its getting real strange:
> >
> > Jan 17 22:25:46 hpux2 postfix/postscreen[9558]: var_psc_pre_queue_limit =
> > 100
> > Jan 17 22:25:46 hpux2 postfix/postscreen[9558]: psc_lowat = 0
> > Jan 17 22:25:46 hpux2 postfix/postscreen[9558]: psc_hiwat = 0
> > Jan 17 22:25:46 hpux2 postfix/postscreen[9558]:
> > postscreen_command_time_limit: stress=10 normal=300 lowat=0 hiwat=0
> >
> > I have added msg_info to print out psc_lowat and psc_hiwat after the
> > calculation...
> > I really wonder what else this HP compiler does if no one notices.
> > Should i maybe try without the ANSI flag "-Ae"?
>
> Looks like
>
> 0.7 * 100 = 0
> 0.9 * 100 = 0
>
> If you have time, can you try:
>
> stuff = 0.7 * ((double) var_psc_pre_queue_limit);
> stuff = 0.9 * ((double) var_psc_pre_queue_limit);
>
> Thanks,
In case that does not help, declaring the hiwat and lowat variables
as double instead of int (in postscreen.c and postscreen.h) could
make a difference.
Perhaps the bug is triggered when the target of assignment is int.
Either way it would be a compiler bug.
Wietse
