f



error and warning

I am not sure if this is directly related to C or the compiler (Xcode)
I am using...but I will ask and see.
I have started creating unique C files ( .c and .h) so that I can
reuse some of the functions when doing the exercises in K&R.
The code below is created in , for example, foo.c. Main.c contains the
directive #included <stdio.h> yet unless I include the same directive
in foo.h, the error and warning will not go away.  My understanding,
( or rather misunderstanding ) was that once declared in main, one
need not "redeclare" in foo.h.  If this is unique to Xcode, I will ask
there.
Thank you.


/*foo.h*/
/*   #include <stdio.h>  */  <<<uncommenting this removes the error
and warning.
char *alloc (int );
void afree(char *p1);



/*foo.c*/
#include "foo.h"
#define BUFFSIZE 120

static char allocbuff[BUFFSIZE];
static char *p = allocbuff; /*assigns ptr to buffer*/
char static *pend = allocbuff + BUFFSIZE;


char *alloc ( int n) {


if ((p + n) < pend){

	p +=n;

	return p - n;}

else

	return NULL; /* error: 'NULL' undeclared (first use in this
function)   *****ERROR HERE



}



void afree(char *p1){

if ( p1 >= allocbuff && p1 < pend)

p=p1;

else

printf( "Error: Space requested is not available") ;  /* "warning:
incompatible implicit declaration of built-in function 'printf' */
***WARNING HERE

}
0
mdeh (570)
4/24/2008 12:55:01 PM
comp.lang.c 30657 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

18 Replies
619 Views

Similar Articles

[PageSpeed] 17

mdh <mdeh@comcast.net> writes:

> I have started creating unique C files ( .c and .h) so that I can
> reuse some of the functions when doing the exercises in K&R.
> The code below is created in , for example, foo.c. Main.c contains the
> directive #included <stdio.h> yet unless I include the same directive
> in foo.h, the error and warning will not go away.  My understanding,
> ( or rather misunderstanding ) was that once declared in main, one
> need not "redeclare" in foo.h.  If this is unique to Xcode, I will ask
> there.

No, it is common to all conforming C compilers.  Every translation
unit much have declarations for the things it uses.  You choose to
include <stdio.h> in "foo.h", but this is not the usual way to do it.
It is foo.c the needs some things from stdio.h and it is in foo.c that I
would put the #include <stdio.h>.

<snip>
> char *alloc ( int n) {
>
>
> if ((p + n) < pend){
>
> 	p +=n;
>
> 	return p - n;}
>
> else
>
> 	return NULL; /* error: 'NULL' undeclared (first use in this
> function)   *****ERROR HERE
>
>
>
> }

Is your code really formatted out like this?  If so, you will annoy
most people who have to read it!

-- 
Ben.
0
ben.usenet (6790)
4/24/2008 2:12:50 PM
mdh said:

> I am not sure if this is directly related to C or the compiler (Xcode)
> I am using...but I will ask and see.
> I have started creating unique C files ( .c and .h) so that I can
> reuse some of the functions when doing the exercises in K&R.
> The code below is created in , for example, foo.c. Main.c contains the
> directive #included <stdio.h> yet unless I include the same directive
> in foo.h, the error and warning will not go away.

It's not entirely clear what you're doing, but I *guess* that you are 
(rightly) compiling foo.c and Main.c (or possibly main.c) separately and 
linking them at the end - which is fine.

But remember that they *are* compiled separately. The compiler can't (or at 
least, is not required to) see what you've done in main.c when it's 
compiling foo.c, and vice versa. So if you need to call printf (or 
whatever) in both, you need <stdio.h> to be included in both.

<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
0
rjh (10791)
4/24/2008 2:29:54 PM
mdh wrote:

> I am not sure if this is directly related to C or the compiler (Xcode)
> I am using...but I will ask and see.
> I have started creating unique C files ( .c and .h) so that I can
> reuse some of the functions when doing the exercises in K&R.
> The code below is created in , for example, foo.c. Main.c contains the
> directive #included <stdio.h> yet unless I include the same directive
> in foo.h, the error and warning will not go away.  My understanding,
> ( or rather misunderstanding ) was that once declared in main, one
> need not "redeclare" in foo.h.  If this is unique to Xcode, I will ask
> there.

Actually every translation unit (or "source file") must include the
appropriate headers to compile. Hence if foo.c uses functions from
stdio.h, then you must place a include directive for that header at the
top of foo.c or in a private header that foo.c includes. You could also
place the include directive in foo.h, but that is not really a good
design, since foo.h is mainly meant for code that calls services in
foo.c.

<snip>

0
santosh.k83 (3969)
4/24/2008 2:34:43 PM
>
> Is your code really formatted out like this? =A0If so, you will annoy
> most people who have to read it!
>
> --
> Ben.

The **last** thing I would try and do is annoy people in this
group!!!  :-)
So, being  a relative novice to C, I am open to suggestions.

As to the question, thanks for the  answer.
0
mdeh (570)
4/24/2008 3:15:40 PM
On Apr 24, 7:29=A0am, Richard Heathfield

> But remember that they *are* compiled separately. The compiler can't (or a=
t
> least, is not required to) see what you've done in main.c when it's
> compiling foo.c, and vice versa. So if you need to call printf (or
> whatever) in both, you need <stdio.h> to be included in both.
>
> <snip>
>


Ok... thank you Richard and Santosh for your answers.
0
mdeh (570)
4/24/2008 3:17:55 PM
mdh <mdeh@comcast.net> writes:

>>
>> Is your code really formatted out like this?  If so, you will annoy
>> most people who have to read it!
>>
>> --
>> Ben.
>
> The **last** thing I would try and do is annoy people in this
> group!!!  :-)

Then best not to quote sigs, too. :-)

> So, being  a relative novice to C, I am open to suggestions.

I learned C from K&R and this is, pretty much, how I lay out my code,
but there are lots of other perfectly dreadfu^H^H^H^H^H^H^Hacceptable
ways to do it.

The two keys points are to be (a) consistent and (b) reasonably
generous with space.  I hate this form:

  if( x < 42 )
    {
       y += x;
       return( y * y );
    }
  else
    {
       return( -x );
    }

but I would not comment on it since it is reasonably clear and
consistent.  I *would* comment on:

  if(x<43){
    y+=x; return y*y;}
  else {
    return (-x);
    }

because it seems to be neither.  I'd write:

  if (x < 42) {
      y += x;
      return y * y;
  }
  else
      return -x;

-- 
Ben.
0
ben.usenet (6790)
4/24/2008 3:44:53 PM
Ben Bacarisse wrote:
> 
.... snip ...
> 
> but I would not comment on it since it is reasonably clear and
> consistent.  I *would* comment on:
> 
>   if(x<43){
>     y+=x; return y*y;}
>   else {
>     return (-x);
>     }
> 
> because it seems to be neither.  I'd write:
> 
>   if (x < 42) {
>       y += x;
>       return y * y;
>   }
>   else
>       return -x;

I'll go along so far, but I would write :-)

   if (x >= 42) return -x;
   else {
      y += x;
      return y * y;
   }

and I _might_ use '42 <= x' in the conditional.  If y is automatic
and local scope I would also seriously consider:

   if (42 <= x) return -x;
   else {
      y += x;   return y * y;
   }

Note the implementation of 'long term last'.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **
0
cbfalconer (19194)
4/24/2008 6:04:02 PM
=2E =A0I'd write:
>
> =A0 if (x < 42) {
> =A0 =A0 =A0 y +=3D x;
> =A0 =A0 =A0 return y * y;
> =A0 }
> =A0 else
> =A0 =A0 =A0 return -x;
>
> --
> Ben.

 Points taken...or should I say "pointers" taken.  :-)

thank you Ben.
0
mdeh (570)
4/24/2008 6:34:10 PM
mdh said:

> 
>>
>> Is your code really formatted out like this?  If so, you will annoy
>> most people who have to read it!
>>
>> --
>> Ben.
> 
> The **last** thing I would try and do is annoy people in this
> group!!!  :-)
> So, being  a relative novice to C, I am open to suggestions.

Everything should be either useful or ornamental. If it's both, that's a 
bonus. Code layout is *useful* for indicating structure.

Here are two versions of the same code (which is based pretty solidly on a 
K&R code sample), with everything replaced by whitespace except the 
structure words and the braces. The first uses K&R bracing style, and the 
second Allman style. Pick the style you think indicates structure more 
clearly, and consider using it from now on.

K&R style:

main()
{
  while() {
    while() {
      if() {
      } else if() {
      } else if() {
      } else {
      }
    }
  }
}

Allman style:

main()
{
  while()
  {
    while()
    {
      if()
      {
      }
      else if()
      {
      }
      else if()
      {
      }
      else
      {
      }
    }
  }
}


-- 
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
0
rjh (10791)
4/25/2008 12:54:36 AM
On Apr 24, 5:54=A0pm, Richard Heathfield
> Everything should be either useful or ornamental. If it's both, that's a
> bonus. Code layout is *useful* for indicating structure.
>
> Here are two versions of the same code (which is based pretty solidly on a=

> K&R code sample), with everything replaced by whitespace except the
> structure words and the braces. The first uses K&R bracing style, and the
> second Allman style. Pick the style you think indicates structure more
> clearly, and consider using it from now on.


Thank you Richard.
0
mdeh (570)
4/25/2008 2:54:00 AM
Richard Heathfield wrote, On 25/04/08 01:54:

<snip>

> second Allman style. Pick the style you think indicates structure more 
> clearly, and consider using it from now on.
> 
> K&R style:
> 
> main()

<snip>

To the OP, it is better not to rely on implicit int but rather to be 
specific about the return type. It is also better to be specific if a 
function does not take parameters. So

int main(void)

rather than
main()

One reason for this is that the latest standard (not commonly fully 
implemented) no longer has implicit int, so the "main ()" form does not 
work in it.

Richard, would it not be better to give a good example when showing a 
newbie styles and telling them to pick one?
-- 
Flash Gordon
0
spam331 (4048)
4/25/2008 6:32:45 AM
Flash Gordon wrote:

> Richard Heathfield wrote, On 25/04/08 01:54:
> 
> <snip>
> 
>> second Allman style. Pick the style you think indicates structure
>> more clearly, and consider using it from now on.
>> 
>> K&R style:
>> 
>> main()
> 
> <snip>
> 
> To the OP, it is better not to rely on implicit int but rather to be
> specific about the return type. It is also better to be specific if a
> function does not take parameters. So
> 
> int main(void)
> 
> rather than
> main()
> 
> One reason for this is that the latest standard (not commonly fully
> implemented) no longer has implicit int, so the "main ()" form does
> not work in it.
> 
> Richard, would it not be better to give a good example when showing a
> newbie styles and telling them to pick one?

I believe 'mdh' has been following this group long enough to have read
about both implicit int and the recommended form for main more times
than he could enumerate. :-)

0
santosh.k83 (3969)
4/25/2008 7:31:00 AM
Flash Gordon said:

<snip>
 
> int main(void)
> 
> rather than
> main()
> 
> One reason for this is that the latest standard (not commonly fully
> implemented) no longer has implicit int, so the "main ()" form does not
> work in it.

You forgot to complain about the missing definitions, contents of while() 
and if(), lack of return code, etc etc.

> Richard, would it not be better to give a good example when showing a
> newbie styles and telling them to pick one?

I showed him K&R (1TBS) and Allman, with huge swathes of stuff chopped out 
so that the brace placement stood out in sharp relief.

If you don't think that K&R and Allman are good examples of indenting 
style, perhaps you'd show us something that you think /is/ a good example.

-- 
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
0
rjh (10791)
4/25/2008 8:15:07 AM
Richard Heathfield wrote, On 25/04/08 09:15:
> Flash Gordon said:
> 
> <snip>
>  
>> int main(void)
>>
>> rather than
>> main()
>>
>> One reason for this is that the latest standard (not commonly fully
>> implemented) no longer has implicit int, so the "main ()" form does not
>> work in it.
> 
> You forgot to complain about the missing definitions, contents of while() 
> and if(), lack of return code, etc etc.

The missing contents for while()/if() are far more obvious since the 
compiler will produce a diagnostic (almost certainly an error) for them. 
Remember that some people would use "main()" and not have the compiler 
produce any warning about it (by default the version of gcc *you* have 
install won't warn about it, and I said gcc not your alias for it which 
adds loads of options). If I had thought more I probably would have 
complained about you not returning a value from main as well if you 
didn't indicate that.

>> Richard, would it not be better to give a good example when showing a
>> newbie styles and telling them to pick one?
> 
> I showed him K&R (1TBS) and Allman, with huge swathes of stuff chopped out 
> so that the brace placement stood out in sharp relief.
> 
> If you don't think that K&R and Allman are good examples of indenting 
> style, perhaps you'd show us something that you think /is/ a good example.

I was not complaining about the style of indenting. I was complaining 
about you posting something that could be construed as encouraging using 
"main()" and I stand by that complaint. I would say that those styles 
without the modification of specifying the return type of main are 
definitely sub-standard.

If you want what I would consider a good example of style just take your 
K&R example (or probably Allman, although I can't remember what that 
looked like) and make the return type explicit, use a prototype 
definition of main at the start then return an appropriate value at the 
end of main.
-- 
Flash Gordon
0
spam331 (4048)
4/25/2008 7:04:59 PM
Flash Gordon said:

<snip>
 
> I was not complaining about the style of indenting. I was complaining
> about you posting something that could be construed as encouraging using
> "main()" and I stand by that complaint.

In the same vein, I would just like to point out that the above could be 
construed as an explanation that you were complaining about my using a 
string literal as the entry point for a C program. But thus to construe it 
would be daft, right?

-- 
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
0
rjh (10791)
4/26/2008 2:47:32 AM
Richard Heathfield wrote, On 26/04/08 03:47:
> Flash Gordon said:
> 
> <snip>
>  
>> I was not complaining about the style of indenting. I was complaining
>> about you posting something that could be construed as encouraging using
>> "main()" and I stand by that complaint.
> 
> In the same vein, I would just like to point out that the above could be 
> construed as an explanation that you were complaining about my using a 
> string literal as the entry point for a C program. But thus to construe it 
> would be daft, right?

It could not be so construed in context. Your post in context could 
easily be construed as I described.
-- 
Flash Gordon
0
spam331 (4048)
4/26/2008 10:23:01 AM
Flash Gordon said:

> Richard Heathfield wrote, On 26/04/08 03:47:
>> Flash Gordon said:
>> 
>> <snip>
>>  
>>> I was not complaining about the style of indenting. I was complaining
>>> about you posting something that could be construed as encouraging
>>> using "main()" and I stand by that complaint.
>> 
>> In the same vein, I would just like to point out that the above could be
>> construed as an explanation that you were complaining about my using a
>> string literal as the entry point for a C program. But thus to construe
>> it would be daft, right?
> 
> It could not be so construed in context. Your post in context could
> easily be construed as I described.

Sorry, but I disagree. It would be daft to do that, and I don't accept that 
either you or the OP is daft.


-- 
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
0
rjh (10791)
4/26/2008 11:28:29 AM
Richard Heathfield wrote, On 26/04/08 12:28:
> Flash Gordon said:
> 
>> Richard Heathfield wrote, On 26/04/08 03:47:
>>> Flash Gordon said:
>>>
>>> <snip>
>>>  
>>>> I was not complaining about the style of indenting. I was complaining
>>>> about you posting something that could be construed as encouraging
>>>> using "main()" and I stand by that complaint.
>>> In the same vein, I would just like to point out that the above could be
>>> construed as an explanation that you were complaining about my using a
>>> string literal as the entry point for a C program. But thus to construe
>>> it would be daft, right?
>> It could not be so construed in context. Your post in context could
>> easily be construed as I described.
> 
> Sorry, but I disagree. It would be daft to do that, and I don't accept that 
> either you or the OP is daft.

I know that you do not recommend that form. However since we get people 
coming he here using it some people would not realise that, and the 
audience is not only me and the OP. However, as we are not going to 
agree we might as well drop it.
-- 
Flash Gordon
0
spam331 (4048)
4/26/2008 12:06:41 PM
Reply: