Bug 57350 - source code problems
Summary: source code problems
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pump
Version: 7.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact:
URL:
Whiteboard:
: 80818 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-12-10 18:29 UTC by d.binderman
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-03-11 22:56:01 UTC
Embargoed:


Attachments (Terms of Use)

Description d.binderman 2001-12-10 18:29:20 UTC
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:

Comment 1 Eido Inoue 2002-02-13 21:06:10 UTC
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.

Comment 2 d.binderman 2002-02-17 10:58:15 UTC
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.


Comment 3 Eido Inoue 2003-03-11 22:56:01 UTC
fixed in cvs

Comment 4 Eido Inoue 2003-03-11 23:06:35 UTC
*** Bug 80818 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.