C file

[Bill Cunningham]

#include <stdio.h>

main(){
char *cap;
printf("Enter code-> ");
fflush(stdout);
fgets(cap,100,stdin);
printf(cap);}

Now this seems to work much better. Decalring a pointer to a char seems to
be the default of fgets first parameter. This compile without even a
complaint by the compile for a cast. So if someone entered something that
was 200 chars long. There would be an error but not a buffer overrun?

Bill

 

[Ian Collins]

#include <stdio.h>

main(){
char *cap;
printf("Enter code-> ");
fflush(stdout);
fgets(cap,100,stdin);

Where does cap point?

 

[Bill Cunningham]

Where does cap point?

To a type char in this file.

Bill

 

[Ian Collins]

*Please* don't quote signatures.

To a type char in this file.

No, it is uninitialised.

 

[Bill Cunningham]

No, it is uninitialised. So then it is declared but not assigned. Would assigning it involve the
ampersand?

Bill

 

[Ian Collins]

So then it is declared but not assigned. Would assigning it involve the
ampersand?

That depends what you assign it to. Do you have a C book?

 

[santosh]

#include <stdio.h>

main(){

int main(void) { ...

is better form for the current Standard.

char *cap;
printf("Enter code-> ");
fflush(stdout);
fgets(cap,100,stdin);

Where have you allocated memory for 100 char objects and set 'cap' to
point to their beginning?

This fgets() call invokes undefined behaviour because it deferences an
uninitialised pointer and attempts to write to memory it does not own,
or should not write to.

printf(cap);}

This is horrible code style. What do you gain by placing the closing
brace of main() on the same line as the last of it's statements? Also
include a return statement.

Now this seems to work much better.

If this works, it's purely by chance. It's horribly broken.

Decalring a pointer to a char
seems to be the default of fgets first parameter.

Yes. But in almost all situations a pointer alone is useless without it
pointing to some region of valid storage.

This compile without
even a complaint by the compile for a cast.

C assumes you know what you are doing.

So if someone entered
something that was 200 chars long. There would be an error but not a
buffer overrun?

It wouldn't be a "buffer overrun" because you have used fgets() instead
of the deprecated gets(), but that's irrelevant to the code you have
shown above.

Whether you read one char or a million char, you are still not
allocating any storage for them. You are merely supplying an
indeterminate pointer value to fgets() and invoking undefined
behaviour. Two possible solutions include:

char input[100];
fgets(input, sizeof input, stdin);

or

char *cap;
size_t buffer_size = 100;
cap = malloc(buffer_size);
if (!cap) { /* no memory */ }
fgets(cap, buffer_size, stdin);
/* proceed */

 

[Thad Smith]

int main(void) { ...

is better form for the current Standard.


It wouldn't be a "buffer overrun" because you have used fgets() instead
of the deprecated gets(), but that's irrelevant to the code you have
shown above.

It depends on the definition of buffer overrun:
1. It isn't a buffer overrun because there is no buffer!
2. It is an overrun because characters are placed in memory not
allocated for that purpose.

 

[Philip Potter]

Bill Cunningham wrote:

Get a good C book - Kernighan and Ritchie, The C Programming Language,
2nd Edition, is old but well worth the money.

> #include <stdio.h>

Well done for including this.

>
> main(){

This should be int main(void)

> char *cap;

A 'char *' is a pointer-to-char. It can also point to the first char in
a char array - and so, using sloppier language, point to an
array-of-char. But here it doesn't point to anything.

A 'char *' is a way of accessing chars, but in this program you have no
chars to access.

> printf("Enter code-> ");
> fflush(stdout);
> fgets(cap,100,stdin);

Well done on not using gets().

But now the problem becomes apparent. fgets() does not provide the chars
you need to write to. You provide a 'char *' to fgets() which points to
the chars which /you/ have to provide. Here you haven't provided
anything - so fgets() has no allocated memory to write to.

> printf(cap);}

This should be:
printf(cap);
return 0;
}

Now, a question which you should be asking is: "If fgets() is writing to
chars which don't exist or haven't been allocated, why did my program work?"

The answer is that there exist certain programs which break the rules of
C, and when that happens the C standard places no restriction on the
program behaviour. This is known as "Undefined behaviour". What that
means is your program may work perfectly - or it may output subtly wrong
answers, or crash, or slowly eat up all your memory, or anything it
likes. If you compile the same C program on a different compiler you may
find it doesn't work. It may even crash on a new version of the same
compiler!

This means that learning C by trial-and-error alone is a Bad Idea; just
because a program compiles and runs as expected, doesn't mean that it is
valid C.

This is why the first sentence in this post was "Get a good C book".

 

[Nick Keighley]

#include <stdio.h>

main(){
char *cap;
printf("Enter code-> ");
fflush(stdout);
fgets(cap,100,stdin);
printf(cap);}

Now this seems to work much better.

better than what?

Decalring a pointer to a char seems to
be the default of fgets first parameter.

it's not "the default", it's the only possible answer

char *fgets(char*, int, FILE*);

the only confusion is when a array "decays" to a pointer

char buffer[200];

fgets(buffer, 200, stdin);

a pointer (char*) is passed as the first parameter

<snip>

 

[Bill Cunningham]

Two possible solutions include:

char input[100];
fgets(input, sizeof input, stdin);

This looks good.

or

char *cap;
size_t buffer_size = 100;
cap = malloc(buffer_size);
if (!cap) { /* no memory */ }
fgets(cap, buffer_size, stdin);
/* proceed */

This is totally incomprehensible to me. I recognize all the statements
but I don't know what they are saying because of my limited C knowledge.

Bill

 

[Bill Cunningham]

That depends what you assign it to. Do you have a C book?

I have k&r2 which everyone brags about and I guess I can just sit down
and take it one step at a time and do the excercises. I also have "C
Unleased" a very large book. It might be best to use k&r2.

Bill

 

[Mark Bluemel]

I have k&r2 which everyone brags about

"brags"? "BRAGS"???? We recommend it, because it's good. I haven't
noticed anyone bragging about it.

and I guess I can just sit down
and take it one step at a time and do the excercises.

That may be more productive that to keep guessing and posting to
comp.lang.c - we're willing to help when you get stuck, but a newsgroup
is a poor medium for basic tuition, in my opinion.

 

[Joachim Schmitz]

Two possible solutions include:

char input[100];
fgets(input, sizeof input, stdin);

This looks good.

or

char *cap;
size_t buffer_size = 100;
cap = malloc(buffer_size);

Ask the system to give you buffer_size bytes and assing cap the address of
the first of these
if cap is 0 or actually NULL, malloc() didn't get you the memory you asked
it for, so you better stop processing right here
pass the address of the first byte malloc() allocated for you and the size
of that buffer to fget() for it to store the input it reads from stdin

This is totally incomprehensible to me. I recognize all the statements
but I don't know what they are saying because of my limited C knowledge.

Bye, Jojo

 

[santosh]

I have k&r2 which everyone brags about and I guess I can just sit
down and take it one step at a time and do the excercises.

If K&R2' learning curve seems a bit steep to you (it expects you to have
some rudimentary programming knowledge) try one of the tutorials listed
below. Steve Summit's version is a bit more "gentle" than Tom Torf's.

<http://www.eskimo.com/~scs/cclass/>

I also have "C Unleased" a very large book. It might be best to use
k&r2.

_C Unleashed_ will certainly make a lot more sense _after_ K&R.

 

[Christopher Benson-Manica]

#include <stdio.h>

main(){
char *cap;
printf("Enter code-> ");
fflush(stdout);
fgets(cap,100,stdin);
printf(cap);}

Aside from all the other egregious failures of this code, the line

printf(cap);

can lead to tragedy all by itself. If cap happens to contain a format
specifier such as %s, undefined behavior results. puts() avoids this
potential pitfall, or printf("%s",cap) if you insist on printf().

 

[Mark McIntyre]

That depends what you assign it to. Do you have a C book?

Bill has been posting this kind of garbage code for at least 18 months.
I recall several people pointing out that C programming doesn't seem to
be for him, but he keeps coming back...

 

[Richard Heathfield]

Mark McIntyre said:

Bill has been posting this kind of garbage code for at least 18 months.

At least five years, actually. The first article he posted to this group
that I can find is dated 5 June 2002, in which he was recommending K&R2
(although he wasn't sure if the book was still in print, as he hadn't
spoken to Dennis Ritchie for a while).

 

[Ralph D. Ungermann]

Mark McIntyre said:

At least five years, actually. The first article he posted to this group
that I can find is dated 5 June 2002, in which he was recommending K&R2
(although he wasn't sure if the book was still in print, as he hadn't
spoken to Dennis Ritchie for a while).

A: Why haven't you talked to Dennis for a while?
B: Say, would you talk to a person, that has not
the faintest grasp of C?
A: No, of course not!
B: See, and nor does Dennis.

 

[Bill Cunningham]

Bill has been posting this kind of garbage code for at least 18 months.
I recall several people pointing out that C programming doesn't seem to be
for him, but he keeps coming back...

More than 18 months Mark have I posted. And C seems to be for everyone.
I've looked at other languages too. The only one I can really pound out code
with is Basic older than C. I will try to learn more (about C)but I don't
think I am going to just give up on C.

Bill