declaring functions
ad...@intergrafix.net
If I have a function such as:
char *test(int mode, char str)
{
...
}
would I declare it in the beginning of my C file as:
char *test(int, char);
or
char *test(int mode, char str);
both compile fine with -Wall -pedantic, I just want to know which is ANSI
compliant, if either.
Email, if possible. Thanx,
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
ad...@intergrafix.net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Aaron Crane
ad...@intergrafix.net writes:
> char *test(int, char);
> or
> char *test(int mode, char str);
>
> both compile fine with -Wall -pedantic, I just want to know which is ANSI
> compliant, if either.
Both.
> Email, if possible.
You post here, you read here. Welcome to Usenet.
--
Aaron Crane <aaron...@pobox.com> <URL:http://pobox.com/~aaronc/>
ad...@intergrafix.net
system functions, such as sleep()
in the beginning of my C file i'll have to put
unsigned int sleep();
if i dont, on compile it'll give me a warning at the first call to sleep()
server.c: In function `main':
server.c:1161: warning: implicit declaration of function `sleep'
my program is only 1 C file so i'm not including from other files/modules or
anything. I am including unistd.h
Thanx,
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
ad...@intergrafix.net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
In comp.programming ad...@intergrafix.net wrote:
> Hi,
> If I have a function such as:
> char *test(int mode, char str)
> {
> ...
> }
> would I declare it in the beginning of my C file as:
> char *test(int, char);
> or
> char *test(int mode, char str);
> both compile fine with -Wall -pedantic, I just want to know which is ANSI
> compliant, if either.
> Email, if possible. Thanx,
Paul D. Smith
a> also, if i compile my program -Wall i have to implicitly declare
a> certain system functions, such as sleep()
a> if i dont, on compile it'll give me a warning at the first call to sleep()
a> server.c: In function `main':
a> server.c:1161: warning: implicit declaration of function `sleep'
a> my program is only 1 C file so i'm not including from other
a> files/modules or anything. I am including unistd.h
That means your system unistd.h header isn't defining it, as it should.
Since you don't say what system you're using there's not a lot more to
be said on the subject, but I suspect from your post that it's a SunOS
4.x system; these are well-known to not have POSIX (or even ANSI/ISO C)
standard header files.
If you're compiling with GCC, you can add -D__USE_FIXED_PROTOTYPES__ to
your compile line and get a lot (but not all) of the missing stuff
defined.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
System Administrator
>
> a> my program is only 1 C file so i'm not including from other
> a> files/modules or anything. I am including unistd.h
>
> That means your system unistd.h header isn't defining it, as it should.
> Since you don't say what system you're using there's not a lot more to
> be said on the subject, but I suspect from your post that it's a SunOS
> 4.x system; these are well-known to not have POSIX (or even ANSI/ISO C)
> standard header files.
>
I apologize, it's Linux. unistd.h does define it.
cygnus@clipons:~> more /usr/include/unistd.h | grep ' sleep'
/* Make the process sleep for SECONDS seconds, or until a signal arrives
extern unsigned int sleep __P ((unsigned int __seconds));
!**?#!#$
> ) char *test(int mode, char str);
Either is acceptable. In this case, you can also,
char *test(int mode,char);
char *test(int,char str);
char *test(int modeOfTest,char string);
> ) char *test(int mode, char str)
> ) {
> ) ...
> ) }
In other words, the parameter names in a declaration are optional and not
checked against the definition parameter names.
--
They wait apart in waning day, |meow I don't use no smilies.
the flare of crimson fades to gray. | smj...@my-dejanews.com
They rest their violence, the rest is silence.| www.geocities.com
Their empty years are ash and clay. | /SoHo/Studios/5079/index.html
I was flamed by Mattison and all I got was this stupid .signature.
!**?#!#$
> ) anything. I am including unistd.h
Then it's probably declared elsewhere. The man page should tell you.
man sleep
Also you can
cd /usr/include (or wherever your compiler gets system includes.)
grep sleep *.h */*.h | more
And that should show you any declaration and other references.
Clayton Weaver
What about function pointers? How would you designate that the formal
parameter is a function pointer without a parameter name?
Regards, Clayton Weaver cgw...@eskimo.com (Seattle)
"Would that be 30 gallons of the Summer Paint or 30 gallons of
the Winter Paint?"
--
Regards, Clayton Weaver cgw...@eskimo.com (Seattle)
"Would that be 30 gallons of the Summer Paint or 30 gallons of
Alan Curry
In article <Pine.SUN.3.96.980927...@eskimo.com>,
Clayton Weaver <cgw...@eskimo.com> wrote:
>Re: omitting formal parameter names in function prototype declarations
>
>What about function pointers? How would you designate that the formal
>parameter is a function pointer without a parameter name?
The same way you designate other parameter types, by just giving the
declaration with the name removed (or commented out, if it is of value to
human readers)
int qsort(void *,
size_t,
size_t,
int (*)(const void *, const void *)
);
The key point is that any declaration you can write in C remains unambiguous
after you remove the name. In this declaration:
int (*)(const void *, const void *);
There is only one place the name can go. Here:
int (*name)(const void *, const void *);
You might think this would be legal:
int (*)name(const void *, const void *);
but it's not. The only place you can put "extra" parentheses in a declaration
is around the name. A star in parentheses by itself followed immediately by
another left parenthesis can only mean one thing: function pointer.
--
Alan Curry echo cnp...@pdp.pbz | tr a-z n-za-m
The lbxproxy program has various options, all of which are optional.
-- lbxproxy(1)
Eric Amick
> I haven't seen the rest of this thread, so I'm sorry if this is repetitive.
> In article <Pine.SUN.3.96.980927...@eskimo.com>,
> Clayton Weaver <cgw...@eskimo.com> wrote:
>>Re: omitting formal parameter names in function prototype declarations
>>
>>What about function pointers? How would you designate that the formal
>>parameter is a function pointer without a parameter name?
> The same way you designate other parameter types, by just giving the
> declaration with the name removed (or commented out, if it is of value to
> human readers)
There's no need to comment out the name; parameter names are legal (and
ignored) in function declarations.
--
Eric Amick
Columbia, MD
eam...@clark.net
John Kugelman
>
> Re: omitting formal parameter names in function prototype declarations
>
> What about function pointers? How would you designate that the formal
> parameter is a function pointer without a parameter name?
e.g.,
void qsort (void *, size_t, size_t,
int (*) (const void *, const void *));
If you want to omit the name of a parameter in a function prototype just
omit the name, that simple.
--
John Kugelman. kuge...@mnsinc.com
I believe we can change anything.
I believe in my dream.
- Joe Satriani
John Kugelman
>
> There's no need to comment out the name; parameter names are legal (and
> ignored) in function declarations.
Actually, it's a common practice. The names might unintentionally
conflict with macro names. In fact, compilers must either omit them, or
put them in the reserved namespace (e.g. by adding leading underscores)
since something like
#define base *
#include <stdlib.h>
could alter the meaning of the code erroneously if qsort() were
prototyped as
void qsort (void *base, size_t nelem,
size_t width, int (*fcmp) (const void *, const void *));
(this doesn't apply to all compilers, but it does to most where the
standard headers are true files).
So similarly, some programmers don't include parameter names in
prototypes.
John E. Davis
wrote:
>There's no need to comment out the name; parameter names are legal (and
>ignored) in function declarations.
Here is a simple example of why I never use them (and why I think
library header files that I have to include should not use them either):
bash$ cat t.c
#include <math.h>
extern int draw_box (int x0, int y0, int x1, int y1);
bash$ $CC $CFLAGS -c t.c
t.c:3: warning: declaration of `y0' shadows global declaration
t.c:3: warning: declaration of `y1' shadows global declaration
bash$ echo $CC $CFLAGS
gcc -pipe -g -Wall -W -pedantic -Winline -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wcast-align -Wshadow -Wstrict-prototypes
--John
Dann Corbit
[snip]
>>bash$ $CC $CFLAGS -c t.c
>>t.c:3: warning: declaration of `y0' shadows global declaration
>>t.c:3: warning: declaration of `y1' shadows global declaration
>
called
>'y0' or 'y1'. Perhaps it's some local extension.
Bessel functions. Along with yn(), j0(), j1(), jn(). They are not
standard, but you will find them in a very large number of compilers since
they are so useful for engineering. Actually, I think all of my compilers
support these {which probably means that all of my compilers are broken}.
In this case, I prefer the broken ones.
>In any case, the shadowing of a global declaration itself isn't a problem;
>it's only macros that cause problems. If your <math.h> define macros
called
>y0 and y1, then your program wouldn't even build. Or worse, it could
>somehow build incorrectly without any diagnostic at all.
>
>Whereas <math.h> can't define such macros, some other header file could.
If
>you are writing a header file that may end up widely distributed, you have
to
>be careful. Someone could use your header in a project that also y0 macro
>somewhere, perhaps in one of its own headers. Or y0 could appear in some
>foreign library; libraries other than Standard C libraries don't observe
>the name space restrictions.
I don't see the Bessel functions in C9X. I sure hope that they will be
included.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software? Algorithms? Pubs? http://www.infoseek.com
Douglas A. Gwyn
> Bessel functions. Along with yn(), j0(), j1(), jn().
y0, y1, j0, and j1 are obvious names for variables in graphics apps,
and I've encountered lots of name conflicts between these and old
UNIX <math.h>. It was a real nuisance. They need better names.
> I don't see the Bessel functions in C9X. I sure hope that they will be
> included.
There are a *lot* of so-called "special functions" that could be
supplied. I think the Bessel functions were added in UNIX libm.a
mainly to support certain signal analysis apps. I suspect by the
time every special interest got their special functions, we'd have
added as much extra spec as a volume of Abramowitz & Stegun.
(Why not the Dirichlet eta function?)
John E. Davis
wrote:
>Huh? According to ANSI C, <math.h> isn't permitted to declare anything called
>'y0' or 'y1'. Perhaps it's some local extension.
These are Bessel functions. There are commonly encountered when
solving problems in, e.g., a cylindrical coordinate system. So,
it is nice that many C libraries support them. Unfortunately, they
should have more descriptive names such as bessel_y0, etc. Even y_0
would have been better choice since that is how I would write it in
LaTeX. I guess that we are lucky that the person who implemented y0
and named it y0 did not also attempt to create spherical harmonics,
since he would most likely have named them Y00, Y10, etc...
>In any case, the shadowing of a global declaration itself isn't a problem;
I know. But my point was that such warnings decrease the signal to
noise ratio of the compiler output.
--John
Geoff Clare
>In article <slrn70vfha...@mygir.davis.net>,
>John E. Davis <da...@space.mit.edu> wrote:
>>
>>bash$ cat t.c
>>#include <math.h>
>>extern int draw_box (int x0, int y0, int x1, int y1);
>>
>>bash$ $CC $CFLAGS -c t.c
>>t.c:3: warning: declaration of `y0' shadows global declaration
>>t.c:3: warning: declaration of `y1' shadows global declaration
>Huh? According to ANSI C, <math.h> isn't permitted to declare anything called
>'y0' or 'y1'. Perhaps it's some local extension.
John didn't indicate what $CC and $CFLAGS were, but presumably they
contain something that is selecting a wider namespace than just ANSI C.
E.g. if CFLAGS=-D_XOPEN_SOURCE then this clash with the y0() and y1()
functions would occur on any XPG3, XPG4, UNIX95 or UNIX98 compliant
system.
>In any case, the shadowing of a global declaration itself isn't a problem;
>it's only macros that cause problems. If your <math.h> define macros called
>y0 and y1, then your program wouldn't even build. Or worse, it could
>somehow build incorrectly without any diagnostic at all.
The X/Open specs for <math.h> say that y0() and y1() are required to be
declared as functions, but are allowed to be defined as macros as well
(as are most functions).
--
Geoff Clare <g...@root.co.uk>
UniSoft Limited, London, England.
John E. Davis
wrote:
>John didn't indicate what $CC and $CFLAGS were, but presumably they
echo $CC $CFLAGS ==>
gcc -pipe -g -Wall -W -pedantic -Winline -Wmissing-prototypes \
-Wnested-externs -Wpointer-arith -Wcast-align -Wshadow \
-Wstrict-prototypes
>The X/Open specs for <math.h> say that y0() and y1() are required to be
>declared as functions, but are allowed to be defined as macros as well
>(as are most functions).
Let's hope that nobody defines y0 or y1 as macros. I am sure that
doing so will break a lot of code.
--John