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.