This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Compilation problem in HP LINUX server


Hi gkarthi29,

> The code sample that i gave is the logic that is available in my application
> which is currently running in an AIX server. Now it needs to be migrated to
> a HP linux server. There are lacs of such c code, so modifying c code is
> almost impossible. Hence this needs to be fixed with the help of some
> compiler and linker options.

You will have to do the almost impossible.

There is no compiler flag that turns undefined behavior code into
well-defined portable code.

There is no compiler flag that turns buggy code into working code.

There is no compiler flag for "do what I want, not what the code says".
Although I wish there were... that'd save me a lot of time and typing.

> Do we have any other compilers or linkers to make it work?

Alas, no.  The code is bad.  Usually the only way to fix bad code is to fix
the code, not by compiler switches.

> Any sugesstion?

I recommend tools like vi (Vim) and gdb.

I recommend turning on compiler warnings, like -Wall and -Wextra.

Note: GCC does not have a flag -Wabsolutely-all to enable all toggle warning
flags.  But that would probably be more noise than you would want at this
time.

I recommend assessing and resolving all warnings, so that your entire code
base compiles warning free.

HISTORY:  in the past (pre-GCC days), the C compiler compiled, and emitted
few-to-no warnings.  Another tool, called LINT, was used to find suspicious
code.  In modern times, GCC (and many other compiler vendors) incorporated
LINT-like functionality into the compiler itself.  So now, the compiler can
do the LINT-like analysis.  That's what those warnings are -- suspicious
code that the compiler has identified as a possible issue that should be
scrutinized.

Although extreme, I recommend CONSIDERING rewriting your server application
in Java EE 5, Python 3.0, or D 2.0 (alpha) -- languages which have less
susceptibility to the kind of bug that you have identified as being rife
through your code.

My project's code base has 73,906 files.  I consider code hygiene to be very
important.  Helps if you are either OCD curious, or a pedant.

Sincerely,
--Eljay


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]