Closed Bug 297708 Opened 20 years ago Closed 18 years ago

nss should be built with ANSI C mode flags on unix platforms

Categories

(NSS :: Build, defect, P3)

3.10
All
Other
defect

Tracking

(Not tracked)

RESOLVED WONTFIX
3.11.1

People

(Reporter: alvolkov.bgs, Assigned: alvolkov.bgs)

Details

Julien wrote: Wrt the C++ variable declaration, I believe all compilers have flags to compile in ANSI C mode. The NSS build system must be using the wrong flags, which allow C++ declarations. That's the case apparently on Linux/gcc, since Alexei wrote the code there. It may be the case on other platforms too. We should file a bug against coreconf to use the right flags . There are at least two platform effected: linux(gcc compiler), solaris(SUNWspro compiler). Currently we do not know what are these flags. I'll work on this bug to get more info and will modify build cripts.
Priority: -- → P3
Target Milestone: --- → 3.10
From https://bugzilla.mozilla.org/show_bug.cgi?id=297015#c22 by Nelson Bolyard Usually the -ansi cc command line option instructs the compiler to use header files that define ONLY the functions defined in ANSI's libc, and do NOT instruct the compiler to exclude c++ syntax. In my experience, selecting the -ansi flag always necessitates adding additional command line options that tell the compiler "also include these non-ANSI extensions to the definition of libc's API". For example, when you use -ansi with gcc on Solaris, it is typically necessary to also add -D__EXTENSIONS__ to get anything to compile. A c compiler's default behavior should be to compile the c language. The ability to permit language extensions should be enabled with a flag.
Nelson is right. Using the -ansi flag may mean only the Standard C library functions are allowed, and you need to add several macro definitions to use common functions such as Unix/POSIX system calls and pthread functions. An example is mozilla/security/coreconf/Linux.mk. C++ variable declaration is allowed in the 1999 revision of the C Standard (commonly referred to as C99), so the compiler flag you want is not "ANSI C mode" but "C89 mode". See http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Mixed-Declarations.html#index-declarations_002c-mixed-with-code-1685.
Target Milestone: 3.10 → 3.11
Spent some time investigating. It turns out the current version (99 ISO) of C is not strict about variable declarations in the middle of a block (declaration of variable following a statement). However it was enforced in 1990 ISO. So in order to use 1990 ISO standard we should specify "-xc99=none" flag in our build. The compiler will issues a warning, but will not stop the build. I've built nss couple times with the flag and compared it with original build. It looks like our code conforms 1990 ISO standard as I didn't find any additional errors or warnings during the build. I'll check gcc next.
I think this bug is not worth fixing. It is straightforward to fix a build failure caused by C99 variable declarations.
Assignee: wtchang → alexei.volkov.bugs
I'd like to add another reason to support my opinion that this bug isn't worth fixing. Only the latest versions of the compilers support C99 features, so any compiler flags that turn off C99 features will only be supported by the latest versions of the compilers. For example, Sun Forte 6 Update 2 C compiler doesn't recognize the -xc99=none flag: cyclone[svrbld]:/u/svrbld/wtchang> cc -V cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15 usage: cc [ options] files. Use 'cc -flags' for details cyclone[svrbld]:/u/svrbld/wtchang> cc -xc99=none foo.c cc: Warning: illegal option -xc99=none Since NSS doesn't use autoconf, it is hard to for NSS to use compiler flags that only work with certain versions of the compiler. So I reiterate my suggestion that this bug be resolved WONTFIX.
QA Contact: wtchang → build
Target Milestone: 3.11 → 3.11.1
Closing as WONTFIX. It looks like it will take relatively large effort to fix this bug with a little payoff.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.