lgamma function: ANSI C or not?

[Bart Vandewoestyne]

I'm having a .c source file which at the top contains the line

#include <math.h>

In that source file, i declare a function dt which in its body uses
the lgamma function. `man lgamma' on my linux system tells me
that i have to include math.h so it seems like I'm doing the
right thing in order to be able to use the lgamma function.

When I compile the .c file with

$ gcc -ansi -c rand.c

or

$ gcc -Wall -c rand.c

then I get no errors or warnings. When I compile it with

$ gcc -Wall -ansi -c rand.c

I get the warning:

rand.c: In function `dt':
rand.c:544: warning: implicit declaration of function `lgamma'

which seems strange to me. Why am I getting this warning and how do I
resolve this warning? I assume it has something to do with ANSI C or not,
but I'm confused...

Thanks,
Bart

PS: the version of gcc I'm using is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13).
Upgrading to a newer version is no option because I do not have admin rights
to install or upgrade packages on my system.

 

[Vladimir Oka]

I'm having a .c source file which at the top contains the line

#include <math.h>

In that source file, i declare a function dt which in its body uses
the lgamma function. `man lgamma' on my linux system tells me
that i have to include math.h so it seems like I'm doing the
right thing in order to be able to use the lgamma function.

When I compile the .c file with

$ gcc -ansi -c rand.c

or

$ gcc -Wall -c rand.c

then I get no errors or warnings. When I compile it with

$ gcc -Wall -ansi -c rand.c

I get the warning:

rand.c: In function `dt':
rand.c:544: warning: implicit declaration of function `lgamma'

which seems strange to me. Why am I getting this warning and how do I
resolve this warning? I assume it has something to do with ANSI C or not,
but I'm confused...

Thanks,
Bart

PS: the version of gcc I'm using is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13).
Upgrading to a newer version is no option because I do not have admin rights
to install or upgrade packages on my system.

Function `lgamma()` is only available in C99. GCC `-ansi` assumes C89
(same as `-std=c89`). Therein lies your problem. Have you tried
`-std=c99` instead?

 

[P.J. Plauger]

I'm having a .c source file which at the top contains the line

#include <math.h>

In that source file, i declare a function dt which in its body uses
the lgamma function. `man lgamma' on my linux system tells me
that i have to include math.h so it seems like I'm doing the
right thing in order to be able to use the lgamma function.

When I compile the .c file with

$ gcc -ansi -c rand.c

or

$ gcc -Wall -c rand.c

then I get no errors or warnings. When I compile it with

$ gcc -Wall -ansi -c rand.c

I get the warning:

rand.c: In function `dt':
rand.c:544: warning: implicit declaration of function `lgamma'

which seems strange to me. Why am I getting this warning and how do I
resolve this warning? I assume it has something to do with ANSI C or not,
but I'm confused...

lgamma is required by C99 and the Single Unix Specification
(effectively Posix). It is found in some older math libraries,
but not all.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Bart Vandewoestyne]

Function `lgamma()` is only available in C99. GCC `-ansi` assumes C89
(same as `-std=c89`). Therein lies your problem. Have you tried
`-std=c99` instead?

Indeed: this doesn't generate warnings:

$ gcc -Wall -std=c99 -c rand.c

This does:

$ gcc -Wall -std=c89 -c rand.c
rand.c: In function `dt':
rand.c:545: warning: implicit declaration of function `lgamma'


So my options are:

* implement lgamma myself if i want to be c89 compatible
* don't try to be c89 compatible and compile with -std=c99

Thanks!
Bart

 

[Flash Gordon]

I'm having a .c source file which at the top contains the line

#include <math.h>

In that source file, i declare a function dt which in its body uses
the lgamma function. `man lgamma' on my linux system tells me
that i have to include math.h so it seems like I'm doing the
right thing in order to be able to use the lgamma function.

Yes you are.

When I compile the .c file with

$ gcc -ansi -c rand.c

or

$ gcc -Wall -c rand.c

then I get no errors or warnings. When I compile it with

$ gcc -Wall -ansi -c rand.c

I get the warning:

rand.c: In function `dt':
rand.c:544: warning: implicit declaration of function `lgamma'

which seems strange to me. Why am I getting this warning and how do I
resolve this warning? I assume it has something to do with ANSI C or not,
but I'm confused...

Yes and no. It was not part of the original ANSI standard but it is part
of the latest C standard known colloquially as C99. See
http://clc-wiki.net/wiki/c_standard for more about the various versions
of the C standard.

<OT>
With gcc you could try using -std=c99 instead of -ansi, however you
should be aware that gcc does not fully implement C99.

My man page for lgamma included
| CONFORMING TO
| C99, SVID 3, BSD 4.3

which tells you that it is C99 and which other standard provided it as
an extension to C.
</OT>

If you need further help on getting gcc to recognise the lgamma function
gnu.gcc.help could be useful.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Tim Prince]

Indeed: this doesn't generate warnings:

$ gcc -Wall -std=c99 -c rand.c

This does:

$ gcc -Wall -std=c89 -c rand.c
rand.c: In function `dt':
rand.c:545: warning: implicit declaration of function `lgamma'


So my options are:

* implement lgamma myself if i want to be c89 compatible
* don't try to be c89 compatible and compile with -std=c99

or, you could edit <math.h> and remove the c99 guard on math functions
you consider eligible for c89 compatibility.

 

[Flash Gordon]

Indeed: this doesn't generate warnings:

$ gcc -Wall -std=c99 -c rand.c

This does:

$ gcc -Wall -std=c89 -c rand.c
rand.c: In function `dt':
rand.c:545: warning: implicit declaration of function `lgamma'


So my options are:

* implement lgamma myself if i want to be c89 compatible
* don't try to be c89 compatible and compile with -std=c99

If you chose to implement it yourself then I would strongly suggest
using a different name. That way you avoid confusion.

 

[Ico]

I'm having a .c source file which at the top contains the line

#include <math.h>

In that source file, i declare a function dt which in its body uses
the lgamma function. `man lgamma' on my linux system tells me
that i have to include math.h so it seems like I'm doing the
right thing in order to be able to use the lgamma function.

When I compile the .c file with

$ gcc -ansi -c rand.c

or

$ gcc -Wall -c rand.c

then I get no errors or warnings. When I compile it with

$ gcc -Wall -ansi -c rand.c

I get the warning:

rand.c: In function `dt':
rand.c:544: warning: implicit declaration of function `lgamma'

which seems strange to me. Why am I getting this warning and how do I
resolve this warning? I assume it has something to do with ANSI C or not,
but I'm confused...

The manpages also have information on conformaing standards: look a bit
further down in the same manpage :

CONFORMING TO
C99, SVID 3, 4.3BSD

As you can see, ANSI is not in the list

 

[Flash Gordon]

or, you could edit <math.h> and remove the c99 guard on math functions
you consider eligible for c89 compatibility.

This is probably a bad idea for several reasons. It could break valid
C89 code (e.g. code that defines an lgamma function with a different
prototype) which you might not hit until months or years later, the C99
stuff may depend on compiler support which is only enabled when C99
support is enabled, it may depend on things in other headers that are
only enabled when C99 is enabled etc. Also the OP does not have admin
writes so probably can't do this anyway.

 

[P.J. Plauger]

This is probably a bad idea for several reasons. It could break valid C89
code (e.g. code that defines an lgamma function with a different
prototype) which you might not hit until months or years later, the C99
stuff may depend on compiler support which is only enabled when C99
support is enabled, it may depend on things in other headers that are only
enabled when C99 is enabled etc. Also the OP does not have admin writes so
probably can't do this anyway.

Most of those reasons are pretty esoteric, and not likely to matter
in real life. Nevertheless, I agree that it's a bad idea to edit
system headers. Besides, chances are all you have to do is put:

double (lgamma)(double);

at the top of the source file that calls the function. (The parens are
to protect the declaration against a macro override that may one day
come along.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Flash Gordon]

The manpages also have information on conformaing standards: look a bit
further down in the same manpage :

CONFORMING TO
C99, SVID 3, 4.3BSD

As you can see, ANSI is not in the list

ANSI adopted C99 just as earlier ISO adopted C89. So it is on the list.
It's just that gcc does not support C99 when the -ansi switch is used.

 

[Stephen Sprunk]

Most of those reasons are pretty esoteric, and not likely to matter
in real life. Nevertheless, I agree that it's a bad idea to edit
system headers. Besides, chances are all you have to do is put:

double (lgamma)(double);

at the top of the source file that calls the function. (The parens are
to protect the declaration against a macro override that may one day
come along.)

That will most likely work, yes, but one can envision a system that uses
different libraries depending on whether C89 or C99 mode is chosen.
Unlikely, sure, but comp.lang.c must maintain its reputation for pedantry.

Two "correct" solutions are to either require C99 or to create a macro that
calls his own implementation in non-C99 environments but calls the provided
(lgamma)() on a C99 system.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin


*** ***

 

[Ian Collins]

Most of those reasons are pretty esoteric, and not likely to matter
in real life. Nevertheless, I agree that it's a bad idea to edit
system headers. Besides, chances are all you have to do is put:

double (lgamma)(double);

at the top of the source file that calls the function. (The parens are
to protect the declaration against a macro override that may one day
come along.)

Isn't that rather a dangerous thing to recommend?

I can see two potential problems, the function isn't in the library, so
the application fails to link, or worse, the function exists with a
different prototype resulting in bizarre run time errors.

I'd have thought the OP should compile with the correct options to bring
the function in, there may be other types or definitions required in
that mode.

 

[P.J. Plauger]

That will most likely work, yes, but one can envision a system that uses
different libraries depending on whether C89 or C99 mode is chosen.
Unlikely, sure, but comp.lang.c must maintain its reputation for pedantry.

Two "correct" solutions are to either require C99 or to create a macro
that calls his own implementation in non-C99 environments but calls the
provided (lgamma)() on a C99 system.

Okay, if you're going to be pedantic, how can C99 dictate what happens in
non-C99 environments?

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

Isn't that rather a dangerous thing to recommend?

Not in real life.

I can see two potential problems, the function isn't in the library, so
the application fails to link, or worse, the function exists with a
different prototype resulting in bizarre run time errors.

I said "chances are". And chances are that lgamma is out there in the
binary library and does just what it's supposed to do.

I'd have thought the OP should compile with the correct options to bring
the function in,

Now that I'm aware that the lgamma declaration is suppressed in C89 mode,
I agree that the best solution is simply to switch to C99 mode and get
the proper declaration (and runtime library, and semantics for the
function).

there may be other types or definitions required in
that mode.

What part of "double lgamma(double)" do you think will cause trouble?
I guess pedantry is its own reward.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Ian Collins]

What part of "double lgamma(double)" do you think will cause trouble?
I guess pedantry is its own reward.

In this specific case, none. But if the function used some form of
defined type as a parameter, that type might be different with different
compiler options.

I never have been and hope I never become a pedant. I simply though the
advice carried risks.