Dear C Experts,
While prepating a content for a C course,I made section on function
prototypes.
Could you kindly provide me your comments on its correctness. Thank you !
Q12: What is the difference between a function prototype and a function
declaration?
If you get this right, you must have done fair amount of research on C
programming beginning with "K&R" C. It turns out that function declarations
and function prototypes are the same thing in standard C. In K&R C a
function declaration did not need to have the types of its arguments to be
specified.
Thus a declaration like:
int Spi_Tx();
was perfectly acceptable, even though its definition was infact:
int Spi_Tx(uint8 TragetId,uint8 byteArray[],uint16 count)
{
}
It was easy for programmers to call the function with incorrect
parameters which needless to say had disastrous runtime consequences. Thus
ANSI C mandates function prototypes as the method for function declaration.
Regards,
Ravishankar
29  7939 
Ravishankar S said:
<snip>
It turns out that function
declarations and function prototypes are the same thing in standard C.
No, it doesn't.
It is true that all function prototypes are function declarations, but it
is not true that all function declarations are function prototypes.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:eN******************************@bt.com...
Ravishankar S said:
<snip>
It turns out that function
declarations and function prototypes are the same thing in standard C.
No, it doesn't.
It is true that all function prototypes are function declarations, but it
is not true that all function declarations are function prototypes.
<snip>
an example would help here.
Ravishankar S wrote:
>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:eN******************************@bt.com...
>Ravishankar S said:
<snip>
It turns out that function
declarations and function prototypes are the same thing in standard
C.
No, it doesn't.
It is true that all function prototypes are function declarations,
but it is not true that all function declarations are function
prototypes.
<snip>
an example would help here.
int fx();
This is a function declaration, but not a prototype. In fact, argument
checking is turned of for functions declared like this. This is for
backwards compatibility and not recommended for new code. Use:
int fx(void);
or specify the parameters explicitly, as a prototype.
Ravishankar S said:
an example would help here.
Look up "prototype" in the index of any good C book.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"santosh" <sa*********@gmail.comwrote in message
news:fk**********@registered.motzarella.org...
Ravishankar S wrote:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:eN******************************@bt.com...
Ravishankar S said:
<snip>
It turns out that function
declarations and function prototypes are the same thing in standard
C.
No, it doesn't.
It is true that all function prototypes are function declarations,
but it is not true that all function declarations are function
prototypes.
<snip>
an example would help here.
int fx();
This is a function declaration, but not a prototype. In fact, argument
checking is turned of for functions declared like this. This is for
backwards compatibility and not recommended for new code. Use:
int fx(void);
or specify the parameters explicitly, as a prototype.
Thanks.
My amended article would be:
It turns out that there is no difference between function declarations and
function prototypes as far as modern use of C is concerned. When a function
is declared, the number and types of its arguments are also naturally
specified. Such a declaration is also a function prototype.
But it is also allowed to declare a function without specifying its
arguments. In this case the compiler turns off argument checking at the
point of its call. This is meant for backward compatibility (K&R C) should
not be used in normal code. For example:
int fx(); /* declaration , but not a function prototype */
int testFx(void)
{
/* Compiler will not check for argument type match */
if (fx(5) == 10)
{
return 11;
}
return 15;
}
/* Will not get the required arguments ! */
int fx(double a,double b,double c)
{
if((a + b) c)
return 10;
else
return 11;
}
Thus it is easy for programmers to call the function with incorrect
parameters which needless to say has disastrous runtime consequences. ANSI C
mandates function prototypes as the method for function declaration.
Ravishankar S wrote:
"santosh" <sa*********@gmail.comwrote in message
news:fk**********@registered.motzarella.org...
>Ravishankar S wrote:
>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:eN******************************@bt.com...
Ravishankar S said:
<snip>
It turns out that function
declarations and function prototypes are the same thing in
standard C.
No, it doesn't.
It is true that all function prototypes are function declarations,
but it is not true that all function declarations are function
prototypes.
<snip>
an example would help here.
int fx();
This is a function declaration, but not a prototype. In fact,
argument checking is turned of for functions declared like this. This
is for backwards compatibility and not recommended for new code. Use:
int fx(void);
or specify the parameters explicitly, as a prototype.
Thanks.
My amended article would be:
It turns out that there is no difference between function declarations
and function prototypes as far as modern use of C is concerned.
No. With well written programs there prototypes may serve as
declarations, but this is by no means guaranteed. Saying "no
difference..." is too simplistic.
<snip>
ANSI C mandates function prototypes as the method for function
declaration.
Recommends, but not mandates.
However it is better to accurately explain the language as it is
formalised rather than as it might be commonly used. Flushing stdin,
voiding main and using gets seem to be distressingly common in real
world usage, but a tutorial that uses them other than to describe their
dangers, would be considered of very low quality.
Point taken. Though this not of the same stature are of writing "void main"
and "fflush(stdin)".
I was thinking that my conclusions are fairly accurate!
But I cannot help but note that what you have mentioned may also be
achieved by using void pointer's.
No. void pointers are quite different from function pointers. Please
read a good textbook before continuing on your tutorial.
Please recommend me a good book, other than K&R which covers these points.
Thank you.
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including
a pointer to a function...
Ravishankar S said:
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including
a pointer to a function...
You are mistaken.
See 3.2.2.3 of C89 - "A pointer to void may be converted to or from a
pointer to any incomplete or object type. A pointer to any incomplete or
object type may be converted to a pointer to void and back again; the
result shall compare equal to the original pointer." - or the C99
equivalent, 6.3.2.3. The absence of a definition of the behaviour on
converting a function pointer to void * or back means that that behaviour
is undefined.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Ravishankar S wrote:
....
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including a pointer to a function...
You are mistaken. And I'd be very surprised if K&R 2 got that wrong. The
relevant clause is 6.3.2.3p1:
"A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or object type
may be converted to a pointer to void and back again; the result shall
compare equal to the original pointer."
A function type is not an incomplete or object type. Therefore, this
clause does not cover pointers to function types; and there is no other
clause which does cover them.
However, p8 says:
"A pointer to a function of one type may be converted to a pointer to a
function of another type and back again; the result shall compare equal
to the original pointer. If a converted pointer is used to call a
function whose type is not compatible with the pointed-to type, the
behavior is undefined."
Therefore, any pointer to function type can be used for the same purpose
with pointers to functions that void* is used for with pointers to
object types. I generally would prefer "void (*)()" for this purpose,
because it's pretty much the most generic type.
Ravishankar S wrote:
>
>However it is better to accurately explain the language as it is
formalised rather than as it might be commonly used. Flushing stdin,
voiding main and using gets seem to be distressingly common in real
world usage, but a tutorial that uses them other than to describe
their dangers, would be considered of very low quality.
Point taken. Though this not of the same stature are of writing "void
main" and "fflush(stdin)".
Perhaps.
I was thinking that my conclusions are fairly accurate!
But I cannot help but note that what you have mentioned may also be
achieved by using void pointer's.
No. void pointers are quite different from function pointers. Please
read a good textbook before continuing on your tutorial.
Please recommend me a good book, other than K&R which covers these
points. Thank you.
C: A Reference Manual by Harbison & Steele
<http://careferencemanual.com/>
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including a pointer to a function...
No. A void pointer can only store pointers to object and incomplete
types. Conversion between function and void pointer types is undefined.
Also there is no "generic" function pointer type.
Ravishankar S wrote:
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including
a pointer to a function...
You are mistaken.
It's a common extension,
but not part of the standard C language.
--
pete
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including
a pointer to a function...
You are mistaken.
See 3.2.2.3 of C89 - "A pointer to void may be converted to or from a
pointer to any incomplete or object type. A pointer to any incomplete or
object type may be converted to a pointer to void and back again; the
result shall compare equal to the original pointer." - or the C99
equivalent, 6.3.2.3. The absence of a definition of the behaviour on
converting a function pointer to void * or back means that that behaviour
is undefined.
Thank you. very interesting and enlightening. Does this as corollary mean
that pointers of the type
<type(*fp)() are legal generic function pointers..??
Finally, any C text book that covers these points explicitly ?
James Kuyper said:
Ravishankar S wrote:
...
>If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including a pointer to a function...
You are mistaken. And I'd be very surprised if K&R 2 got that wrong.
Brace yourself, then, as you read pp93, 103, 120 and 199, none of which
make it clear that function pointers are not included in the void * magic.
The closest approach is in the tiny-type text on page 199, which
incorrectly singles out object pointers (and thus ignores incomplete
pointers).
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
santosh wrote:
>
Ravishankar S wrote:
"santosh" <sa*********@gmail.comwrote in message
news:fk**********@registered.motzarella.org...
Ravishankar S wrote:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:eN******************************@bt.com...
Ravishankar S said:
<snip>
It turns out that function
declarations and function prototypes are the same thing in
standard C.
No, it doesn't.
It is true that all function prototypes are function declarations,
but it is not true that all function declarations are function
prototypes.
<snip>
an example would help here.
int fx();
This is a function declaration, but not a prototype. In fact,
argument checking is turned of for functions declared like this. This
is for backwards compatibility and not recommended for new code. Use:
int fx(void);
or specify the parameters explicitly, as a prototype.
Thanks.
My amended article would be:
It turns out that there is no difference between function declarations
and function prototypes as far as modern use of C is concerned.
No. With well written programs there prototypes may serve as
declarations, but this is by no means guaranteed. Saying "no
difference..." is too simplistic.
<snip>
ANSI C mandates function prototypes as the method for function
declaration.
Recommends, but not mandates.
The C standard explicitly allows the use
of these features in modern C code:
1 The non protoype function declaration
2 What is usually reffered to as "K&R style",
the non protoype function definition.
and also declares them to be obsolescent features.
--
pete
Richard Heathfield wrote:
James Kuyper said:
>Ravishankar S wrote:
...
>>If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including a pointer to a function...
You are mistaken. And I'd be very surprised if K&R 2 got that wrong.
Brace yourself, then, as you read pp93, 103, 120 and 199, none of which
make it clear that function pointers are not included in the void * magic.
The closest approach is in the tiny-type text on page 199, which
incorrectly singles out object pointers (and thus ignores incomplete
pointers).
I learned C from K&R 1st edition (2nd edition was still years in the
future at that time), and it was excellent. I've never actually read
K&R2; I rely on the standard itself whenever I have a question. I'm a
little disappointed to hear that K&R 2 falls short.
Ravishankar S wrote:
If I am not mistaken a void* must be capabale of storing any
pointer (generic pointer) including
a pointer to a function...
You are mistaken.
See 3.2.2.3 of C89 - "A pointer to void may be converted to or from a
pointer to any incomplete or object type. A pointer to any
incomplete or object type may be converted to a pointer to void and
back again; the result shall compare equal to the original pointer."
- or the C99 equivalent, 6.3.2.3. The absence of a definition of the
behaviour on converting a function pointer to void * or back means
that that behaviour is undefined.
Thank you. very interesting and enlightening. Does this as corollary
mean that pointers of the type
<type(*fp)() are legal generic function pointers..??
Any function pointer type can hold losslessly, the value of any other
function pointer type, but when you deference the pointer to actually
invoke a function, the type of that function and the type of the
function pointer used for calling it must match. Otherwise the
behaviour is undefined.
Finally, any C text book that covers these points explicitly ?
Both _K&R2_ and _C: A Reference Manual_ do so. The fifth edition of the
latter is updated to explain the C99 standard while K&R2 knows only
about the C90 standard.
Ravishankar S wrote:
>
>However it is better to accurately explain the language as it is
formalised rather than as it might be commonly used. Flushing stdin,
voiding main and using gets seem to be distressingly common in real
world usage, but a tutorial that uses them other than to describe their
dangers, would be considered of very low quality.
Point taken. Though this not of the same stature are of writing "void main"
and "fflush(stdin)".
I was thinking that my conclusions are fairly accurate!
But I cannot help but note that what you have mentioned may also be
achieved by using void pointer's.
No. void pointers are quite different from function pointers. Please
read a good textbook before continuing on your tutorial.
Please recommend me a good book, other than K&R which covers these points.
Thank you.
If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including
a pointer to a function...
Unfortunately that's not true, and there is a correction for K&R
regarding that. I have a printing of the 2nd edition with that mistake.
"On page 199, beginning of §A6.8, ``Any pointer may be converted to type
void *...'' is changed to ``Any pointer to an object may be converted to
type void *...''." -- http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html
While the C standard is limited in that way, the fact is most popular
systems *do* store function pointers in void *. POSIX is one example,
with regard to the way dlsym works(), and Windows is another.
C isn't very useful without other standards, and some of them conflict.
POSIX for instance makes certain restrictions for pthreads that limit
the optimizations that some compilers may do for C.
George
Richard Heathfield <rj*@see.sig.invalidwrites:
James Kuyper said:
>Ravishankar S wrote:
...
>>If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including a pointer to a function...
You are mistaken. And I'd be very surprised if K&R 2 got that wrong.
Brace yourself, then, as you read pp93, 103, 120 and 199, none of which
make it clear that function pointers are not included in the void * magic.
The closest approach is in the tiny-type text on page 199, which
incorrectly singles out object pointers (and thus ignores incomplete
pointers).
The errata page, at
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:
On page 199, beginning of <section>A6.8, ``Any pointer may be
converted to type void *...'' is changed to ``Any pointer _to an
object_ may be converted to type void *...''.
I don't have my copy of K&R2 handy; it sounds like your copy has that
(incomplete) erratum already incorporated.
--
Keith Thompson (The_Other_Keith) <ks***@mib.orgLooking for software
development work in the San Diego area. "We must do something. This
is something. Therefore, we must do this." -- Antony Jay and
Jonathan Lynn, "Yes Minister"
santosh <sa*********@gmail.comwrites:
Ravishankar S wrote:
[...]
>If I am not mistaken a void* must be capabale of storing any pointer
(generic pointer) including a pointer to a function...
No. A void pointer can only store pointers to object and incomplete
types. Conversion between function and void pointer types is undefined.
Also there is no "generic" function pointer type.
There is no signle "generic" function pointer type. On the other
hand, *any* function pointer type (such as void (*)(void)) may be used
as a generic function pointer type. (It's generic in the sense that
you can losslessly convert any function pointer to and from it; unlike
with void*, such conversions require explicit casts.)
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Ravishankar S" <ra***********@in.bosch.comwrites:
Dear C Experts,
While prepating a content for a C course,I made section on function
prototypes.
Could you kindly provide me your comments on its correctness. Thank you !
Q12: What is the difference between a function prototype and a function
declaration?
[snip]
C99 6.2.1p2:
A _function prototype_ is a declaration of a function that
declares the types of its parameters.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson said:
<snip>
The errata page, at
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:
On page 199, beginning of <section>A6.8, ``Any pointer may be
converted to type void *...'' is changed to ``Any pointer _to an
object_ may be converted to type void *...''.
I don't have my copy of K&R2 handy; it sounds like your copy has that
(incomplete) erratum already incorporated.
Actually, no, it doesn't. In my copy, the paragraph starts with the
unamended text you quote above:
"Any pointer may be converted to type void * without loss of information."
The paragraph continues with a few words about the properties of void *
that are irrelevant to this discussion, before going on to say, in an
indented small-font paragraph:
"This interpretation of void * pointers is new; previously,
char * pointers played the role of generic pointer. The ANSI
standard specifically blesses the meeting of void * pointers
with object pointers in assignments and relationals, while
requiring explicit casts for other pointer mixtures."
....which seems utterly to disregard incomplete types.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield wrote:
>
Keith Thompson said:
<snip>
The errata page, at
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:
On page 199, beginning of <section>A6.8, ``Any pointer may be
converted to type void *...'' is changed to ``Any pointer _to an
object_ may be converted to type void *...''.
I don't have my copy of K&R2 handy;
it sounds like your copy has that
(incomplete) erratum already incorporated.
Actually, no, it doesn't. In my copy, the paragraph starts with the
unamended text you quote above:
"Any pointer may be converted to type void *
without loss of information."
The paragraph continues with a few words about the properties of void *
that are irrelevant to this discussion, before going on to say, in an
indented small-font paragraph:
"This interpretation of void * pointers is new; previously,
char * pointers played the role of generic pointer. The ANSI
standard specifically blesses the meeting of void * pointers
with object pointers in assignments and relationals, while
requiring explicit casts for other pointer mixtures."
...which seems utterly to disregard incomplete types.
That depends on what you think "object pointers" means.
ISO/IEC 9899:1999 (E)
7.18.1.4 Integer types capable of holding object pointers
1 The following type designates a signed integer type
with the property that any valid pointer to void
can be converted to this type,
then converted back to pointer to void,
and the result will compare equal to the original pointer:
intptr_t
The following type designates an unsigned integer type
with the property that any valid pointer to void
can be converted to this type,
then converted back to pointer to void,
and the result will compare equal to the original pointer:
uintptr_t
These types are optional.
7.18.1.5 Greatest-width integer types
--
pete
pete wrote:
>
Richard Heathfield wrote:
Keith Thompson said:
<snip>
The errata page, at
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:
>
On page 199, beginning of <section>A6.8, ``Any pointer may be
converted to type void *...'' is changed to ``Any pointer _to an
object_ may be converted to type void *...''.
>
I don't have my copy of K&R2 handy;
it sounds like your copy has that
(incomplete) erratum already incorporated.
Actually, no, it doesn't. In my copy, the paragraph starts with the
unamended text you quote above:
"Any pointer may be converted to type void *
without loss of information."
The paragraph continues with a few words about the properties of void *
that are irrelevant to this discussion, before going on to say, in an
indented small-font paragraph:
"This interpretation of void * pointers is new; previously,
char * pointers played the role of generic pointer. The ANSI
standard specifically blesses the meeting of void * pointers
with object pointers in assignments and relationals, while
requiring explicit casts for other pointer mixtures."
...which seems utterly to disregard incomplete types.
That depends on what you think "object pointers" means.
Sometime back,
I got it into my head that there are only two kinds of pointers:
1 object pointers
2 function pointers
and that pointers to incomplete types, were object pointers.
I'm not able to supply a definitive reference at this time.
--
pete
pete wrote:
....
None of what you wrote
prevents the definition of the term "object pointers"
from meaning collectively,
pointers to object types and pointers to incompletes types.
Agreed; I didn't argue against that possibility because I didn't see it
as a possible interpretation. Now that you've raised that possibility, I
still don't see it as a possible interpretation.
Hi, i was reading this post and i'd like to know if is wrong doing
this:
/* begin of code */
datatype func_name(arglist) { ... }
.... list of functions implementations ...
int main(int argc, char **argv) { ... }
/* end of code */
suposing datatype is a valid datatype and arglist is a list of
arguments with valid datatypes and names, and func_name is a valid
name and { ... } for each function is a valid block of code.
is this valid? i mean, i do not define the function before
implementing it.
/*begin of code*/
type func_name(arglist);
.... main function implementation here ...
.... func_name implementation here ...
/*end of code */
i do not do this.
is that wrong? not doing this pre-definition of the function before
implementing it. is it wrong?
"phao" <ph******@gmail.comschrieb im Newsbeitrag
news:44**********************************@1g2000hs l.googlegroups.com...
Hi, i was reading this post and i'd like to know if is wrong doing
this:
/* begin of code */
datatype func_name(arglist) { ... }
... list of functions implementations ...
int main(int argc, char **argv) { ... }
/* end of code */
suposing datatype is a valid datatype and arglist is a list of
arguments with valid datatypes and names, and func_name is a valid
name and { ... } for each function is a valid block of code.
is this valid? i mean, i do not define the function before
implementing it.
/*begin of code*/
type func_name(arglist);
... main function implementation here ...
... func_name implementation here ...
/*end of code */
i do not do this.
is that wrong? not doing this pre-definition of the function before
implementing it. is it wrong?
It's not a matter of when you implement it, but when you use it.
You should declare it before first use. If you define/implement it before
the first use like in your first example, everything is fine, as the
definition/implementation contains the declaration. If you define/implement
it after first use, you'd need to declare it first. Well, for varadic
functions you'd have to (to prevent UB), for other you should (to prevent
warning and allow the compiler to do proper type checking).
Bye, Jojo
Ravishankar S wrote:
>
.... snip ...
>
>No. void pointers are quite different from function pointers.
Please read a good textbook before continuing on your tutorial.
Please recommend me a good book, other than K&R which covers
these points. Thank you.
Please do not snip attributions for material your quote.
Attributions are the "joe wrote:" initial lines.
I recommend reading the C standard, which should keep you out of
mischief for a while. You can get a text version of the last draft
of C99 (small, compressed with bzip2) at:
<http://cbfalconer.home.att.net/download/N869_txt.bz2>
or a more recent, and much larger (factor of 15), draft at:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>
There are only small detail differences between the two, of little
importance.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
h03Ein wrote:
On Dec 18, 3:24 pm, Richard Heathfield <r...@see.sig.invalidwrote:
....
>I think you should stop writing tutorials and start reading them. There is
a very important distinction between a declaration and a prototype, and
you do your readers a disservice by not making the distinction clear.
....
Here is a textbook note:
"Subprogram declarations are common in C programs, where they are
called prototypes."
I'm not sure why you cited that; it's true only insofar as it's a
simplification that ignores the fact that in C, some function
declarations are not prototypes. If the author meant that not as a
simplification, but as a definitive statement that there are no
non-prototype function declarations in C, you should identify the
textbook - it should be avoided.
h03Ein wrote, On 23/12/07 06:53:
On Dec 18, 3:24 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>Ravishankar S said:
<snip>
>>My amended article would be:
It turns out that there is no difference between function declarations
and
function prototypes as far as modern use of C is concerned.
I think you should stop writing tutorials and start reading them. There is
a very important distinction between a declaration and a prototype, and
you do your readers a disservice by not making the distinction clear.
<snip>
>--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Please don't quote peoples signatures, the bit typically after the "-- "
unless you are commenting on them.
Here is a textbook note:
"Subprogram declarations are common in C programs, where they are
called prototypes."
textbook : <Concepts of Programming Languages
Robert W. Sebesta
University of Colorado, Colorado Springs
Addison&Wisely5th edition
chapter 9 (Subprograms) 9.2.2 Basic definition.
Text books do not trump the standard, and the standard explicitly allows
functions declarations that are *not* prototypes. Specifically in
section 6.2 paragraph 2 of N1256 it states "A function /prototype/ is a
declaration of a function that declares the types of its parameters."
thus making it clear that prototypes are a subset of functions declarations.
--
Flash Gordon This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Dave Theese |
last post by:
Consider the following declaration *inside of a function*:
int j(int);
My compiler (VC++ 7.1) accepts this. typeid returns a type of int
__cdecl(int).
Local functions are not legal in C++....
|
by: Rob Somers |
last post by:
Hey people,
I read a good thread on here regarding the reason why we use function
prototypes, and it answered most of my questions, but I wanted to
double check on a couple of things, as I am...
|
by: Michael B. |
last post by:
I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:
void * newKlElem...
|
by: Daniel Nichols |
last post by:
I've noticed that in a C module (.c, .h file combination) that if you
create a function's definition before it is used in other functions
than a declaration is not necessary. I believe if the...
|
by: Neo |
last post by:
Why the following code is compilable? The function abc() doesn't take any
arguments, still i can call the function with arbitraty number of arguments.
Even compiler doesn't show any warning. What...
|
by: dndfan |
last post by:
Hello,
In the short time I have spent reading this newsgroup, I have seen this
sort of declaration a few times:
> int
> func (string, number, structure)
> char* string
> int number
>...
|
by: Christian Christmann |
last post by:
Hi,
in a benchmark I've found an uncommon use of a function.
This is the simplified form:
1 int foo( int f )
2 {
3 return f;
4 }
5
|
by: MikeC |
last post by:
Folks,
I've been playing with C programs for 25 years (not professionally -
self-taught), and although I've used function pointers before, I've never
got my head around them enough to be able to...
|
by: vaib |
last post by:
hi all ,
It really seems that C never ceases to amaze . All this time
i've been doing C and i thought i was quite adept at it but i was
wrong . So without wasting any more time , here's the...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: Taofi |
last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same
This are my field names
ID, Budgeted, Actual, Status and Differences
...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
| |
