Bug 453577 - prlink.h gives warning with -Wstrict-prototypes
prlink.h gives warning with -Wstrict-prototypes
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss (Show other bugs)
5.2
All Linux
high Severity low
: rc
: 5.6
Assigned To: Elio Maldonado Batiz
BaseOS QE Security Team
: ZStream
Depends On:
Blocks: 575157 584100 587546 590145 590728 590734 624751
  Show dependency treegraph
 
Reported: 2008-07-01 09:09 EDT by Dan Horák
Modified: 2012-03-13 18:09 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 584100 (view as bug list)
Environment:
Last Closed: 2011-06-02 13:19:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Build output (46.56 KB, application/octet-stream)
2010-04-22 12:52 EDT, Lon Hohberger
no flags Details
prevents nspr's prink.h from getting indirectly included by nss clients (3.71 KB, patch)
2010-04-26 20:48 EDT, Elio Maldonado Batiz
no flags Details | Diff
Patch V2, secmod doesn't include prlink.h (3.89 KB, patch)
2010-04-27 00:18 EDT, Elio Maldonado Batiz
no flags Details | Diff

  None (edit)
Description Dan Horák 2008-07-01 09:09:27 EDT
Version-Release number of selected component (if applicable):
nspr-devel-4.7.0.99.2-1.el5

for test case and patch see original bug

+++ This bug was initially created as a clone of Bug #451616 +++

Description of problem:
Using nspr header gives a warning in the prlink.h file when -Wstrict-prototypes
is included in the CFLAGS. And when -Werror is used, then it is not possible to
compile at all.

Version-Release number of selected component (if applicable):
nspr-devel-4.6.7-3.fc8
but the header was not changed since Apr/06/2006, so all current Fedora and RHEL
versions are affected.

How reproducible:
100%

Steps to Reproduce:
1. run the script from attachments
  
Actual results:
In file included from /usr/include/nspr4/nspr.h:55,
                 from nspr-test.c:2:
/usr/include/nspr4/prlink.h:52: warning: function declaration isn’t a prototype
/usr/include/nspr4/prlink.h:209: warning: function declaration isn’t a prototype


Expected results:
No warnings

Additional info:
There was a thread in gcc mailing list about the meaning of the warning -
http://gcc.gnu.org/ml/gcc-help/2006-07/msg00033.html

-- Additional comment from dan@danny.cz on 2008-06-16 04:04 EST --
Created an attachment (id=309468)
test case


-- Additional comment from dan@danny.cz on 2008-06-16 04:08 EST --
Created an attachment (id=309471)
patch to remove the warnings
Comment 1 Christine Caulfield 2010-04-08 10:56:55 EDT
This bug is preventing us building cluster packages for RHEL5. I don't see why we should have to change our compiler flags to work around a bug in a library. Especially as it seems to have been recently (re)introduced.
Comment 2 Kai Engert (:kaie) 2010-04-22 11:10:54 EDT
(In reply to comment #1)
> This bug is preventing us building cluster packages for RHEL5.

It's just a warning, do you abort your builds for any warnings?


> I don't see why
> we should have to change our compiler flags to work around a bug in a library.
> Especially as it seems to have been recently (re)introduced.    

The upstream bug has been proposed as WONTFIX.
Upstream is worried this patch may break source compatibility.

Either we ignore this warning or we must carry a patch in the NSPR package.
Comment 3 Lon Hohberger 2010-04-22 12:52:20 EDT
Created attachment 408383 [details]
Build output

This is a typescript output of building cman (specifically fence_xvm part, which uses nss/nspr) with gcc-4.1.2-48.el5 from RHEL 5.5

Build 1:
- older nss/nspr from 5.4 installed (WORKS)

Build 2:
- newer nspr installed from http://rhn.redhat.com/errata/RHSA-2010-0165.html
  (WORKS)

Build 3:
- newer nss installed from http://rhn.redhat.com/errata/RHSA-2010-0165.html
  (FAILS)

I looked at prlink.h - historically, the function pointer has been that way for many years.  I think this is not a new bug in nspr, but it was made visible by a change in nss with the update from nss-3.12.3.99.3-1.el5_3.2 to nss-3.12.6-1.el5_4.x86_64.rpm.

If I had to guess, I would suppose the #includes in nss changed.
Comment 5 Elio Maldonado Batiz 2010-04-26 18:36:29 EDT
In Bug 451616 the following fix has been proposed for the the nspr header wich has function protopyes which aren't strict ansi.

--- prlink.h.orig	2008-06-16 09:33:28.000000000 +0200
+++ prlink.h	2008-06-16 09:33:58.000000000 +0200
@@ -49,7 +49,7 @@
 
 typedef struct PRStaticLinkTable {
     const char *name;
-    void (*fp)();
+    void (*fp)(void);
 } PRStaticLinkTable;
 
 /*
@@ -206,7 +206,7 @@
 **
 ** This function does not modify the reference count of the library.
 */
-typedef void (*PRFuncPtr)();
+typedef void (*PRFuncPtr)(void);
 NSPR_API(PRFuncPtr) PR_FindFunctionSymbol(PRLibrary *lib, const char *name);
 
The problem is that if we were to apply this fix we could potentially break existing code and we want to preserve in fedora and RHEL the compatibility guarantees from upstream nss and nspr from upstream.
Comment 7 Elio Maldonado Batiz 2010-04-26 20:48:46 EDT
Created attachment 409322 [details]
prevents nspr's prink.h from getting indirectly included by nss clients
Comment 8 Elio Maldonado Batiz 2010-04-26 21:20:44 EDT
An nss scratch build is avaiable at
https://brewweb.devel.redhat.com/taskinfo?taskID=2403399
Comment 9 Elio Maldonado Batiz 2010-04-27 00:16:48 EDT
(In reply to comment #8) Ignore this build, it's not good. A corrected patch and build coming next.
Comment 10 Elio Maldonado Batiz 2010-04-27 00:18:41 EDT
Created attachment 409353 [details]
Patch V2, secmod doesn't include prlink.h
Comment 11 Elio Maldonado Batiz 2010-04-27 00:23:52 EDT
(In reply to comment #9) New scratch build 
https://brewweb.devel.redhat.com/taskinfo?taskID=2403527
Comment 12 Christine Caulfield 2010-04-27 03:49:00 EDT
Those RPMs fix the cluster build.

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