Bug 115962 - five source code problems
Summary: five source code problems
Alias: None
Product: Fedora
Classification: Fedora
Component: php   
(Show other bugs)
Version: 1
Hardware: All Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-17 12:15 UTC by d.binderman
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: 4.3.8-2.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-09 09:33:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description d.binderman 2004-02-17 12:15:25 UTC
Description of problem:

I just tried to compile package php-4.3.3-6 from Fedora.

The compiler said


/usr/src/redhat/BUILD/php-4.3.3/ext/sysvsem/sysvsem.c(227): remark
#592: variable "un" is used before its value is set

The source code is

    count = semctl(semid, SYSVSEM_USAGE, GETVAL, un);

I'm not sure what the fix is for this.


/usr/src/redhat/BUILD/php-4.3.3/main/reentrancy.c(71): warning #140:
too many arguments in function call

The source code is

    if (ctime_r(clock, buf, 26) == buf)

Drop superflous 26.


/usr/src/redhat/BUILD/php-4.3.3/main/reentrancy.c(78): warning #140:
too many arguments in function call



#1011: missing return statement at end of non-void function
#1011: missing return statement at end of non-void function

Two missing return statements.


warning #1011: missing return statement at end of non-void function

Looks like a missing default in the switch statement.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Joe Orton 2004-02-17 12:21:08 UTC
Please re-test using the current update version, php-4.3.4-1.1.

Comment 2 d.binderman 2004-02-17 12:34:48 UTC
>Please re-test using the current update version, php-4.3.4-1.1.

Sorry, no. I haven't got the resources to check some
random later version.

You might have those resources ;->

I suggest you visually check the source code lines I have identified 
in the latest version.

Then the bug report might be "fixed in latest version".

Comment 3 Leonard den Ottolander 2004-08-08 14:56:03 UTC
1) Code is reached conditionally (#if HAVE_SEMUN), and I don't see a
warning when building 4.3.8 on FC1, however, un still seems to be used
before it's set in case HAVE_SEMUN is set.

2) & 3) The two superfluous 26s are still there, but I see no warning
in my build log. Strange. Afaict ctime_r only needs two arguments.

4) Both fixed in 4.3.8

5) Fixed. There's a 'return "unknown"' after the switches.

Regarding the missing warnings in my build log, any idea what causes this?

Comment 4 Leonard den Ottolander 2004-08-08 15:08:13 UTC
2 & 3) According to
http://www.scit.wlv.ac.uk/cgi-bin/mansec?3C+ctime_r ctime_r actually
needs 3 arguments. Last one is buffer length. Sadly the man (3) page
tells me differently.

But PHPAPI char *php_ctime_r (about line 141 in reentrancy.c) still
calls ctime_r with only 2 arguments.

Which is it, two or three arguments?

Comment 5 Leonard den Ottolander 2004-08-08 15:13:30 UTC
Quote from the above URL:
     Solaris 2.4 and earlier releases provided definitions of the
     ctime_r(),  localtime_r(), gmtime_r(), and asctime_r() func-
     tions as specified in POSIX.1c Draft 6. The  final  POSIX.1c
     standard   changed   the   interface   for   ctime_r()   and
     asctime_r(). Support for the Draft 6 interface  is  provided
     for  compatibility  only  and may not be supported in future
     releases. New applications  and  libraries  should  use  the
     POSIX standard interface.

I presume php_ctime_r needs fixing.

Comment 6 Leonard den Ottolander 2004-08-08 15:35:24 UTC
Sorry for all this spam. The different PHPAPI calls are defined
conditionally. Thus nothing needs to be fixed there.

This only leaves 1). Not sure if there is anything wrong with calling
count = semctl(semid, SYSVSEM_USAGE, GETVAL, un);
with an unset un. Does this call also set count in un.val?

If 1) is ok this report can be closed ERRATA.

Comment 7 Joe Orton 2004-08-09 09:33:29 UTC
Thanks for the analysis, Leonard.  I concur with all your conclusions. 

Passing a fourth argument to semctl/GETVAL I expect is completely
harmless, so I don't see why it's worth changing it.  There's a small
risk it's not portable to omit the argument so may not get accepted
upstream anyway.

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