«

Dear All,

I am confused with prototypes in C. I saw the following code in a C book:


void init_array_1(int data[])
{
/* some code here */
}


void init_array_2(int *data_ptr)
{
/* some code here*/
}

int main()
{
int array[MAX];

void init_array_1();
void init_array_2();

/*some code ommited*/

return (0);
}

I don't understand why we need the two lines of function declarations
inside main:
void init_array_1();
void init_array_2();

Normally I would put them before main() and put those function
definitions after main. If the two functions block have been put before
main, I would thought no function declarations are needed any more.

Thank you very much.

Xiaoshen Li wrote:
>
> Dear All,
>
> I am confused with prototypes in C. I saw the following code in a C book:
>
> void init_array_1(int data[])
> {
> /* some code here */
> }
>
> void init_array_2(int *data_ptr)
> {
> /* some code here*/
> }
>
> int main()
> {
> int array[MAX];
>
> void init_array_1();
> void init_array_2();
>
> /*some code ommited*/
>
> return (0);
> }
>
> I don't understand why we need the two lines of function declarations
> inside main:
> void init_array_1();
> void init_array_2();

We don't.

> Normally I would put them before main() and put those function
> definitions after main.

So would I.

> If the two functions block have been put before
> main, I would thought no function declarations are needed any more.

You would have thought correctly.

--
pete

"Xiaoshen Li" <> wrote in message
news:docko3$cee$...
> Dear All,
>
> I am confused with prototypes in C. I saw the following code in a C book:
>
>
> void init_array_1(int data[])
> {
> /* some code here */
> }
>
>
> void init_array_2(int *data_ptr)
> {
> /* some code here*/
> }
>
> int main()
> {
> int array[MAX];
>
> void init_array_1();
> void init_array_2();
>
> /*some code ommited*/
>
> return (0);
> }
>
> I don't understand why we need the two lines of function declarations
> inside main:
> void init_array_1();
> void init_array_2();
>
> Normally I would put them before main() and put those function definitions
> after main. If the two functions block have been put before main, I would
> thought no function declarations are needed any more.
>

It'd be interesting to know which book you were using, and what the subject
under discussion was when this code appeared.

What you've posted shows two function *definitions* - ahead of main - and
two differing predecs for those same functions inside of main. However, the
latter predecs change the shape of things - as the *say* that the compiler's
no idea what you're going to pass to these two functions at runtime. So,
they're somewhat in conflict with the external definitions [and the implicit
declarations that these make - when they appeared].

As they're seen later by the compiler, the latter predecs essentially
overrule the earlier definitions seen?

For example ...

:::This says that init_array_1 expects an int[] to be passed to it.

void init_array_1(int data[])
{
}


int main(void)
{

::: this says 'forget what you've heard about this function - you don't know
what it'll be passed!!!'
:::
void init_array_1();

char x;

::: pass a char to init_array_1 - it [the compiler] had better not
complain - as we told it to forget stuff!

init_array_1(x);
}

Lastly, it is more usual to see predecs ahead of main ... possibly because
include files mainly provude these, and are *normally* included ahead of any
code [although there's no real reason to do this - just as long as things
are seen before they're used].

"pete" <> wrote in message
news:...
> Xiaoshen Li wrote:
>>
>> Dear All,
>>
>> I am confused with prototypes in C. I saw the following code in a C book:
>>
>> void init_array_1(int data[])
>> {
>> /* some code here */
>> }
>>
>> void init_array_2(int *data_ptr)
>> {
>> /* some code here*/
>> }
>>
>> int main()
>> {
>> int array[MAX];
>>
>> void init_array_1();
>> void init_array_2();
>>
>> /*some code ommited*/
>>
>> return (0);
>> }
>>
>> I don't understand why we need the two lines of function declarations
>> inside main:
>> void init_array_1();
>> void init_array_2();
>
> We don't.
>
>> Normally I would put them before main() and put those function
>> definitions after main.
>
> So would I.
>
>> If the two functions block have been put before
>> main, I would thought no function declarations are needed any more.
>
> You would have thought correctly.

I would say 'have you nothing better to do!' [at 11.00pm] - but I hate
reality-reflection - so, I won't say it!

Damn it, oops, Ctrl+Z

damn it again!

pemo wrote:
>
> "pete" <> wrote in message
> news:...
> > Xiaoshen Li wrote:
> >>
> >> Dear All,
> >>
> >> I am confused with prototypes in C.
> >> I saw the following code in a C book:
> >>
> >> void init_array_1(int data[])
> >> {
> >> /* some code here */
> >> }
> >>
> >> void init_array_2(int *data_ptr)
> >> {
> >> /* some code here*/
> >> }
> >>
> >> int main()
> >> {
> >> int array[MAX];
> >>
> >> void init_array_1();
> >> void init_array_2();
> >>
> >> /*some code ommited*/
> >>
> >> return (0);
> >> }
> >>
> >> I don't understand why we need
> >> the two lines of function declarations
> >> inside main:
> >> void init_array_1();
> >> void init_array_2();
> >
> > We don't.
> >
> >> Normally I would put them before main() and put those function
> >> definitions after main.
> >
> > So would I.

.... except that I would have written them as protoypes,
instead of merely as declarations.

#define MAX 1

void init_array_1(int *data);
void init_array_2(int *data_ptr);

int main(void)
{
int array[MAX];

return 0;
}

void init_array_1(int *data)
{
/* some code here */
}

void init_array_2(int *data_ptr)
{
/* some code here*/
}

--
pete

The code is from the book "Practical C Programming" 1997, Chapter 13,
which is available in the link:

http://www.oreilly.com/catalog/pcp3/...h13.html#48674

Example 13-6.

I really like this book. Hard to believe that the author could be wrong.

On 2005-12-22, Xiaoshen Li <> wrote:
> The code is from the book "Practical C Programming" 1997, Chapter 13,
> which is available in the link:
>
> http://www.oreilly.com/catalog/pcp3/...h13.html#48674
>
> Example 13-6.
>
> I really like this book. Hard to believe that the author could be wrong.

What exactly are you confused about?

Xiaoshen Li wrote:
> The code is from the book "Practical C Programming" 1997, Chapter 13,
> which is available in the link:
>
> http://www.oreilly.com/catalog/pcp3/...h13.html#48674
>
> Example 13-6.
>
> I really like this book. Hard to believe that the author could be wrong.

I don't. I know of enough bad technical books to find it very easy to
believe an author is wrong. In this case though, I believe it is more a
case fo using a very bad style than something that is completely wrong.

I also note that this author is using the term "procedure" when in C it
is usual to refer even to void functions as functions.

It also says, "Finally, there is a special pointer called NULL. It
points to nothing. (The actual numeric value is 0.) The standard include
file, locale.h, defines the constant NULL. (This file is usually not
directly included, but is usually brought in by the include files
stdio.h or stdlib.h.)" which is wrong or misleading on several points.

It is incorrect in saying that NULL is the name of a pointer, NULL is a
macro that expands to a null pointer.
It is correct that locale.h defines the NULL macro.
It is at least misleading saying that that stdio.h and stdlib.h include
locale.h, since on many systems it may not and even if it does you still
won't get the other things that locale.h defines.

It shows an example that modifies a string literal with a comment that
it is legal. This is wrong, the compiler is not required to complain,
but it is also not required to produce working code since attempting to
modify a string literal is undefined behaviour.

It shows using the %p format specifier without casting the pointer to
void*, %p is only valid for pointers to void.

There are probably other errors that I have not spotted on a quick look.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Xiaoshen Li wrote:
>
> The code is from the book "Practical C Programming" 1997, Chapter 13,
> which is available in the link:
>
> http://www.oreilly.com/catalog/pcp3/...h13.html#48674
>
> Example 13-6.
>
> I really like this book.
> Hard to believe that the author could be wrong.

Many C tutorials are written by people who are wrong.
Placing function declarations inside of function definitions,
is awkward style. (also bad because it's awkward)

The use of nonprototype function declarations,
is bad style.

The
int main()
style definition, is also obsolescent.
int main(void)
is better.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/
N869
6.11.4 Function declarators
[#1] The use of function declarators with empty parentheses
(not prototype-format parameter type declarators) is an
obsolescent feature.

--
pete

Flash Gordon <> writes:
> Xiaoshen Li wrote:
>> The code is from the book "Practical C Programming" 1997, Chapter
>> 13, which is available in the link:
>> http://www.oreilly.com/catalog/pcp3/...h13.html#48674
>> Example 13-6.
>> I really like this book. Hard to believe that the author could be
>> wrong.
>
> I don't. I know of enough bad technical books to find it very easy to
> believe an author is wrong. In this case though, I believe it is more
> a case fo using a very bad style than something that is completely
> wrong.
>
> I also note that this author is using the term "procedure" when in C
> it is usual to refer even to void functions as functions.
>
> It also says, "Finally, there is a special pointer called NULL. It
> points to nothing. (The actual numeric value is 0.) The standard
> include file, locale.h, defines the constant NULL. (This file is
> usually not directly included, but is usually brought in by the
> include files stdio.h or stdlib.h.)" which is wrong or misleading on
> several points.
>
> It is incorrect in saying that NULL is the name of a pointer, NULL is
> a macro that expands to a null pointer.

No, NULL is a macro that expands to a null pointer constant.
[snip]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.