faq 19.1

[Uno]

No, it isn't. getch() isn't a standard C function.

Ok.

int tty_getchar()
{
return getchar();
}

No (if you ignore the implicit int).

.... and ignore the screenshot:

http://i50.tinypic.com/28bxm43.png

 

[Ben Bacarisse]

You snipped out all the C and wondered where the C was.

No, I snipped the C because I was not commenting on it. I did not
complain about any lack of C, I just claimed that your questions would
be better answered in a Unix group. They are, largely, questions about
curses and man pages.

<snip more C>

 

[Ian Collins]

Ok.

int tty_getchar()
{
return getchar();

As Geoff pointed out, getchar() doesn't do what the code is demonstrating.

}




.... and ignore the screenshot:

http://i50.tinypic.com/28bxm43.png

So? you have a misbehaving terminal emulator or curses library. Nothing
undefined there.

 

[Ian Collins]

I don't think it is misbehaving. The terminal is in cbreak mode so
it's going to echo the character returned by getch() but it's not
going to translate '\n' in the same way it does in cooked mode, thus
the screen walk. I suspect the writer of this FAQ item didn't test his
code. I have tested this on Fedora, OS X and Windows and it does the
screen walk in all systems. You have to output the carriage return
explicitly.

That may be true, but the point sticks: No undefined behaviour.

 

[Nobody]

Just because it's written in C doesn't mean that comp.lang.c is a
good place to ask about it.

To be fair to the OP, he is asking about the comp.lang.c FAQ.

Perhaps everything from:

However, since these questions are frequently asked here, here are brief
answers for some common situations.

onwards should be removed?

 

[Uno]

No, I snipped the C because I was not commenting on it. I did not
complain about any lack of C, I just claimed that your questions would
be better answered in a Unix group. They are, largely, questions about
curses and man pages.

<snip more C>

But I'm asking you to ignore the extension and help me wrap my head
around a proper main control. This was my latest guess, but it doesn't
test well:

#define _XOPEN_SOURCE 500
//#define _XOPEN_SOURCE_EXTENDED 1
#include <stdio.h>
#include <curses.h>

int
tty_getchar ()
{
return getchar ();
}

int
tty_break ()
{
initscr ();
cbreak ();
return 0;
}

int
main (void)
{
int m, n;

while ((n = tty_break ()) != 0)
{
m = tty_getchar ();
printf (" = %d\n", m);
}
return 0;
}

// gcc -Wall -Wextra -lcurses p4.c -o out

 

[Uno]

To be fair to the OP, he is asking about the comp.lang.c FAQ.

Perhaps everything from:


onwards should be removed?

No. No faq can ever "should be." Nor is it a valid statement from a
person unless in the form "I should be ...."

I ascribe to a big-tent notion for the C programming that is more than
standard-thumping, useful though standards are.

Let's just fix it and move on.

 

[Alan Curry]

for(i = 0; i < 10; i++)
printf(" = %d\n", tty_getchar());

This should be done with the curses output function printw() instead of
printf(). Between initscr() and endwin(), all terminal output should be
done through the curses library. Talking directly to stdin, stdout, or stderr
(unless you know they've been redirected away from the terminal) is asking
for trouble.

Cleaned up version:

for(i = 0; i < 10; i++) {
printw(" = %d\n", tty_getchar());
refresh();
}

 

[Nick Keighley]

it isn't written in standard C


grep what?

You snipped out all the C and wondered where the C was.

I never saw hiom "wonder" where the C was. He snipped it because it
was unimportant to his reply. You are rather keen on quoting big lumps
of sourec code.

 Why is main
junk in this standard C program:

I've no idea what that means. It isn't a standard C program

int tty_break()
{
     initscr();

at this point it ceases to eb a standard C program

 

[Nick Keighley]

"tailored to a purpose"? Don't you mean "tailored to *the* purpose"?

*Yes.*  There's gonna be a whole lot of stuff I don't understand in
there.  So, I'd like to re-write these functions in a *much* simpler
form.

but you can't write the fuinction with th desired sdemantics in
standard C. They don't put in all that stuff you don't understand just
for fun.

 No, these functions I'm fixing to write won't have all the
functionality of what you would get by the header inclusion, but I do so
only to create scaffolding, and, yes, stay topical.

I can't see the point. You'll end up with something that doesn't
address the original FAQ.

 

[Nick Keighley]

Ian Collins wrote:

the supposedly broken main()

int main(void)
{
int i;
if(tty_break() != 0)
return 1;
for(i = 0; i < 10; i++)
printf(" = %d\n", tty_getchar());
tty_fix();
return 0;



}

The advertising says much more than this

like what?

and minimally needs a re-write.
why?


Invoking undefined behavior.

where? I see no undefined behaviour.

Part of this problem is best cast as standard C.  The rest of it, I'll
discuss there.

you seem to have difficulties telling them apart.

Does anyone have any better notion of what to do with a main control in
such a program than using a retarded 'for' loop?

why is the loop retarded. Is reatrded really a word to use like this?
Perhaps it's really a thlid for loop? [SARCASM]

 

[Seebs]

Wrong.

There's gonna be a whole lot of stuff I don't understand in
there. So, I'd like to re-write these functions in a *much* simpler
form.

No, you're not. You've been at this for years, and all you've managed so
far is to change the name under which you post nonsense every couple of
months for reasons of your own.

No, these functions I'm fixing to write won't have all the
functionality of what you would get by the header inclusion, but I do so
only to create scaffolding, and, yes, stay topical.

This makes no sense.

int tty_getchar()
{
return getch();
}

This part is standard C,

If it relies on a non-standard function, it's not. If you write your own
incompatible versions of such functions, the exercise is pointless. The
only reason to use those functions is to get their special functionality;
a version which doesn't actually do that is useless, and learning to use
it instead of the normal version is pointless.

This is about as useful as "I want to learn to cook, but I'm allergic to
peanuts and dairy. So, I'm working on a peanut cookie recipe, but
I'm substituting cucumbers for the peanuts and mushrooms for the butter,
because this will give me insights into how to cook using peanuts and
dairy."

No, it won't. It's not similar enough to do you any good.

Does main on faq 19.1 invoke undefined behavior?

It's system-specific.

-s

 

[Vincenzo Mercuri]

Taking the question in its widest context, yes. That is, I can think of
one reason why one might not want to include headers in a C program.
Whether it's a *good* reason is another matter - I've heard opinions
both ways.

The context in which this reason is relevant is that of a C tutorial.

To the beginner, C has certain similarities to line noise. I still
remember trying to get a handle on C from a (ghastly) little yellow
paperback by Noel Kantaris, and the two things I struggled most with at
first were #include and #define. The rest seemed to make some kind of
sense, but those two just looked like gibberish.

A case can therefore be made for omitting headers from the early stages
of a tutorial work. One would begin by explaining main():

int main(void)
{
return 0;
}

which, of course, needs no headers anyway. One would then move on
immediately to explaining functions:

int foo(void)
{
return 6;
}

int main(void)
{
foo();
return 0;
}

(Obviously one would explain that, *for now*, we are not bothering to
use the return value of foo. Etc, etc, etc. I'm handwaving over a lot of
stuff here, because the only alternative would be to write the tutorial
right here!)

The author would no doubt stress that the control flow still starts at
main(), and that foo() is called at the appropriate time.

We're going to want to use a standard library function real soon now,
but first one would point out that the order of foo() and main() can be
changed around, *provided* that the compiler is granted a quick peek at
the nature of foo(), like this:

int foo(void);

int main(void)
etc etc.

A quick chat about prototypes would follow, and then the author would
mention standard library functions. Before long, example programs would
begin to look something like this:

int getchar(int);
int putchar(int);

int main(void)
{
int ch;
while((ch = getchar()) > 0) /* yeah, I know... */
{
putchar(ch);
}
return 0;
}

and would get progressively more complicated. At some point, one would
then say (on behalf of the reader): "but wait a minute - all this
'furniture' at the top of our programs is pretty much the same every
time; isn't there some way to say to the compiler 'just take it as read
that I've got all this standard stuff in the program'?"

And at that point, it becomes natural to introduce #include.

Kochan follows a very similar approach in 'Programming in C',
I do think it is the most natural way to introduce the reader to
the handling of progressively larger programs. Maybe he exceeds
declaring function prototypes inside other functions even when
unnecessary, but it's a very effective path.

 

[Ben Bacarisse]

But I'm asking you to ignore the extension and help me wrap my head
around a proper main control.

And all I was doing was asking you to post in a suitable group. You
even have a thread in comp.unix.programmer. That's where you'll get the
best answers about curses. Moving curses code into main does not make
it topical here. I have not seen you ask a question about C in this
thread.

<snip more curses code>

 

[Ben Bacarisse]

On 28 June, 00:17, Uno <[email protected]> wrote:

the supposedly broken main()

[as re-posted by Nick:]

| int main(void)
| {
| int i;
| if(tty_break() != 0)
| return 1;
| for(i = 0; i < 10; i++)
| printf(" = %d\n", tty_getchar());
| tty_fix();
| return 0;
|
|
|
| }

why?

I agree that it could benefit form a re-write and at least one of the
changes I'd make is C-related and thus topical here. I think people
would be less often surprised if the loop were:

for(i = 0; i < 10; i++) {
printf(" = %d\r\n", tty_getchar());
fflush(stdout);
}

<snip>

 

[Seebs]

There is a part of this problem that directly bears on c.l.c., namely
that one of the faqs needs to be fixed up to be useful.

No, it doesn't.

is freaking retarded, and judging by my machine's reaction, invoking
undefined behavior.

If we viewed "Uno can't understand it" as a crippling flaw in a document,
there would be no documents. All I ask is that you pick an alias/email
address and stick with it so you stay killfiled. (I would have asked that
you pay more attention and think before posting, but I am willing to limit
myself to the possible.)

-s

 

[Seebs]

Ahem. See my reply elsethread. If you still think it's wrong, please
explain why.

The means by which the conclusion were reached, and the reason provided,
were clearly nonsense. His "Yes" was a conclusion reached from false
premises by bad reasoning. That a legitimate reason could exist for
not including the appropriate header in some program somewhere does not
make his claim, that there was a reason in this context, true.

That said, arguably the answer is true. Stopped clock twice a day, and
all that*.

-s
[*] And if you haven't, you must find Lewis Carrol's elegant argument that
a stopped clock is more useful than one which is a minute slow every day.

 

[Uno]

No, it doesn't.


If we viewed "Uno can't understand it" as a crippling flaw in a document,
there would be no documents. All I ask is that you pick an alias/email
address and stick with it so you stay killfiled. (I would have asked that
you pay more attention and think before posting, but I am willing to limit
myself to the possible.)

Seebs, you insufferable sod, get off my thread.

Remember this? http://i45.tinypic.com/rauano.jpg

You're the poster child for The Topic being as small as your outlook.

 

[Nick Keighley]

There aren't too many things I find more boring than soccer

you've never watched cricket then?

 

[Uno]

Taking the question in its widest context, yes. That is, I can think of
one reason why one might not want to include headers in a C program.
Whether it's a *good* reason is another matter - I've heard opinions
both ways.

The context in which this reason is relevant is that of a C tutorial.

To the beginner, C has certain similarities to line noise. I still
remember trying to get a handle on C from a (ghastly) little yellow
paperback by Noel Kantaris, and the two things I struggled most with at
first were #include and #define. The rest seemed to make some kind of
sense, but those two just looked like gibberish.

A case can therefore be made for omitting headers from the early stages
of a tutorial work. One would begin by explaining main():

int main(void)
{
return 0;
}

which, of course, needs no headers anyway. One would then move on
immediately to explaining functions:

int foo(void)
{
return 6;
}

int main(void)
{
foo();
return 0;
}

(Obviously one would explain that, *for now*, we are not bothering to
use the return value of foo. Etc, etc, etc. I'm handwaving over a lot of
stuff here, because the only alternative would be to write the tutorial
right here!)

The author would no doubt stress that the control flow still starts at
main(), and that foo() is called at the appropriate time.

We're going to want to use a standard library function real soon now,
but first one would point out that the order of foo() and main() can be
changed around, *provided* that the compiler is granted a quick peek at
the nature of foo(), like this:

int foo(void);

int main(void)
etc etc.

A quick chat about prototypes would follow, and then the author would
mention standard library functions. Before long, example programs would
begin to look something like this:

int getchar(int);
int putchar(int);

int main(void)
{
int ch;
while((ch = getchar()) > 0) /* yeah, I know... */
{
putchar(ch);
}
return 0;
}

and would get progressively more complicated. At some point, one would
then say (on behalf of the reader): "but wait a minute - all this
'furniture' at the top of our programs is pretty much the same every
time; isn't there some way to say to the compiler 'just take it as read
that I've got all this standard stuff in the program'?"

And at that point, it becomes natural to introduce #include.

Getting somewhere now. Why the seg fault?


$ gcc -Wall -Wextra p5.c -o out
p5.c: In function ‘main’:
p5.c:12: warning: suggest parentheses around assignment used as truth value
p5.c: In function ‘put_char’:
p5.c:20: warning: passing argument 1 of ‘fputc’ makes integer from
pointer without a cast
p5.c:20: warning: passing argument 2 of ‘fputc’ makes pointer from
integer without a cast
$ ./out
g
Segmentation fault
$ cat p5.c
#include <stdio.h>

char get_char(void);
void put_char(char);

int main(void)
{
char ch;
while((ch = get_char()) > 0) /* yeah, I know... */
{
put_char(ch);
if (ch = 'p')
break;
}
return 0;
}

void put_char(char b)
{
fputc(stdin, b);
}

char get_char(void)
{
char c;
c = fgetc(stdin);
return c;
}


// gcc -Wall -Wextra -lcurses p5.c -o out
$