Description of problem: I just tried to compile package php-4.3.3-6 from Fedora. The compiler said 1. /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. 2. /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. 3. /usr/src/redhat/BUILD/php-4.3.3/main/reentrancy.c(78): warning #140: too many arguments in function call Duplicate. 4. /usr/src/redhat/BUILD/php-4.3.3/ext/xmlrpc/libxmlrpc/xml_element.c(477): remark #1011: missing return statement at end of non-void function "file_out_fptr" /usr/src/redhat/BUILD/php-4.3.3/ext/xmlrpc/libxmlrpc/xml_element.c(486): remark #1011: missing return statement at end of non-void function "simplestring_out_fptr" Two missing return statements. 5. /usr/src/redhat/BUILD/php-4.3.3/ext/xmlrpc/libxmlrpc/xmlrpc.c(2450): warning #1011: missing return statement at end of non-void function "type_to_str" Looks like a missing default in the switch statement. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please re-test using the current update version, php-4.3.4-1.1.
>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".
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?
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?
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.
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.
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.