Zitat von Wietse Venema <wie...@porcupine.org>:
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.
Luckily we do not need aCC compiled Postfix on HPUX but i wonder what else this compiler would break. I have to talk to the devs if they are aware of this strange behaviour. Maybe a recommendation should be included to better use gcc on HPUX.
Many Thanks Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
