error and warning

[mdh]

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

}

 

[Ben Bacarisse]

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>.

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!

 

[santosh]

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>

 

[mdh]

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

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.

 

[mdh]

On Apr 24, 7:29 am, Richard Heathfield

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>

Ok... thank you Richard and Santosh for your answers.

 

[Ben Bacarisse]

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;

 

[mdh]

.  I'd write:

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

Points taken...or should I say "pointers" taken.

thank you Ben.

 

[mdh]

On Apr 24, 5:54 pm, 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.

 

[Flash Gordon]

Richard Heathfield wrote, On 25/04/08 01:54:

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?

 

[santosh]

Richard Heathfield wrote, On 25/04/08 01:54:



<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.

 

[Flash Gordon]

Richard Heathfield wrote, On 25/04/08 09:15:

Flash Gordon said:



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.

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]

Richard Heathfield wrote, On 26/04/08 03:47:

Flash Gordon said:



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]

Richard Heathfield wrote, On 26/04/08 12:28:

Flash Gordon said:


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.