From Bugzilla Helper: User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (Win98; I) Description of problem: In compiling package pump-0.8.11-1 from RedHat 7.1, I got the following messages from the C compiler 1. cc: Info: pump.c, line 551: In this statement, an array is being accessed outside the bounds specified for the array type. (subscrbounds) cmd.u.status.hostname[sizeof(cmd.u.status.hostname)] = '\0'; ------------------------------------------^ It seems that something like cmd.u.status.hostname[ sizeof( cmd.u.status.hostname) - 1] = '\0'; might be nearer the mark. 2. cc: Warning: dhcp.c, line 707: In this statement, the expression "sprintf(...)" modifies the variable "vndptr" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod) sprintf (vendor, "0x%02x 0x%02x 0x%02x 0x%02x", *vndptr++, *vndptr++, *vndptr++, *vndptr++); ----^ cc: Warning: dhcp.c, line 707: In this statement, the expression "sprintf(...)" modifies the variable "vndptr" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod) sprintf (vendor, "0x%02x 0x%02x 0x%02x 0x%02x", *vndptr++, *vndptr++, *vndptr++, *vndptr++); ----^ cc: Warning: dhcp.c, line 707: In this statement, the expression "sprintf(...)" modifies the variable "vndptr" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod) sprintf (vendor, "0x%02x 0x%02x 0x%02x 0x%02x", *vndptr++, *vndptr++, *vndptr++, *vndptr++); ----^ maybe something like sprintf (vendor, "0x%02x 0x%02x 0x%02x 0x%02x", *vndptr[ 0], *vndptr[ 1], *vndptr[ 2], *vndptr[ 3]); vndptr += 4; might be better. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. compiler with Compaq C compiler, and flags -w0 -fast 2. 3. Additional info:
Problem #1 is definitely wrong and needs to be fixed. #2 I'm not so sure about and looks like a overly paranoid warning, although I'm going to have to talk to a C guru to confirm it-- in certain expressions optimizations may require a sequence point to be inserted, but in a parameter list they should be evaluated left to right. Still, your suggestion is functionally equivalent, so I see no reason to enhance it to satisfy the Compaq compiler.
To quote K&R Second Edition, page 202, section A7.3.2, "The order of evaluation of arguments is unspecified. Take note that various compilers differ." I think that pretty much clears it up. Order of evaluation of arguments to functions is neither left to right nor right to left.
fixed in cvs
*** Bug 80818 has been marked as a duplicate of this bug. ***