for loop problem

[Keith Thompson]

If yo want the code to be interactive, then write it so that it
process both the character of interest and the '\n' that will follow
when the user presses Enter. If you are really ambitions, you could
also deal with the case where the user types more than one character
before pressing Enter. If you look at the archives, this has been
discussed repeatedly.

Yes, that's one approach, and it's necessary if you insist on 100%
portability to (hosted) systems. But plenty of applications
(including the text editor I'm using to type this) need to read single
key inputs without waiting for the user to press enter. For that, you
need to use system-specific solutions -- which means you need to ask
in a system-specific newsgroup.

 

[Guest]

CBFalconer wrote:

Doesn't matter, Chucky. Your buddy Keighley thinks getchar() isn't
a standard function, regardless:

---------------------------------------------------------------------------
From: Nick Keighley <[email protected]>
Newsgroups: comp.lang.c
Subject: Re: File Limit of 1021
Date: Fri, 21 Nov 2008 02:17:24 -0800 (PST)

        printf("Error: Not enough memory\n");
        getchar();
        /*** njk  non-standard function ***/

---------------------------------------------------------------------------

fair cop. Not only did I make the typo, but I've made it before.
I *even* remembered I'd done it before and vowed to be very careful
not to repeeat it!

<snip>

 

[BartC]

Don't do that. getch() is not standard, may not do what his
version did, etc. The normal input sequence is quite simple:

The input system receives chars and stores them until a newline
('\n') is received. This is normally the result of pressing
'enter' or <carriage return> on your terminal.

It's not going to be much fun having to press Enter after every cursor key
press.

Is it really not possible in the 21st century to press a button and have a
(C) program respond to that immediately?

I seem to remember solving this very problem in 1976 for an asr33, although
that wasn't in C.

 

[Chris Dollin]

Is it really not possible in the 21st century to press a button and have a
(C) program respond to that immediately?

Not /portably/, as in, not if you restrict yourself to the facilities
defined by the standard.

You need libraries not defined by the standard, with enough coverage that
you can run the code on Systems Of Your Choice.

Similarly, you can't write networking or GUI code in C, if you insist on
using only defined-by-the-standard features. This hasn't stopped people
from writing C programs that do networking or GUIs; they just have to
trade away some amount of portability.

 

[Kenny McCormack]

Nope. Not according to the CLC regs - the ones who rule the roost
around here. You simply cannot do things like that in C, because "C" is
"isomorphic" to "ANSI C" - and "ANSI C" does not do things like that.

Not /portably/, as in, not if you restrict yourself to the facilities
defined by the standard.

You need libraries not defined by the standard, with enough coverage that
you can run the code on Systems Of Your Choice.

Similarly, you can't write networking or GUI code in C, if you insist on
using only defined-by-the-standard features. This hasn't stopped people
from writing C programs that do networking or GUIs; they just have to
trade away some amount of portability.

Chris, what you say makes perfect sense. Unfortunately, it is out of
sync with the rulers here. See above.

IOW, "perfect" (and/or "common") sense is OT here. Sorry to be the
bearer of bad news.

 

[Stefan Ram]

Not /portably/, as in, not if you restrict yourself to the facilities
defined by the standard.
You need libraries not defined by the standard, with enough coverage that
you can run the code on Systems Of Your Choice.

In ISO/IEC 9899:1999 (E) there already are signal handlers
that might be used to implement such a feature.

Some implementations of C can detect a »break key«
(like »[Ctrl]-[C]«) to invoke a signal handler in
accordance with ISO/IEC 9899:1999 (E):

#include <stdio.h> /* printf */
#include <signal.h> /* signal, SIGINT, SIG_DFL, sig_atomic_t */

static volatile sig_atomic_t looping = 1;
static void h( int const sig ){ looping = 0; }

int main( void )
{ signal( SIGINT, h ); printf( "looping ...\n" );
while ( looping ); printf( "terminated.\n" );
signal( SIGINT, SIG_DFL ); }

stdout

looping ... terminated.

This might allow for some simple key-press games: For example,
the loop might emit random numbers, and the user has to press
the interrupt key as soon as he sees a certain number - then
his reaction time is determined.

ISO/IEC 9899:1999 (E) gives explicit permission to an
implementation to add custom signals:

»Additional signals and pointers to undeclarable
functions, with macro definitions beginning, respectively,
with the letters SIG and an uppercase letter or with SIG_
and an uppercase letter, may also be specified by the
implementation.«

Thus, a conforming implementation might add specific signals
for several keys, and these signals (due to their naming
scheme »SIG_...«) still will have partial standard semantics.
In this way, more elaborate games can be played using several
distinct »interactive attention« keys. (The standard semantics
of SIGINT is »receipt of an interactive attention signal«.)

But, admittedly, code using such additional signals might not
work in the intended way on every C implementation.

 

[CBFalconer]

.... snip ...


It's not going to be much fun having to press Enter after every
cursor key press.

Is it really not possible in the 21st century to press a button
and have a (C) program respond to that immediately?

I seem to remember solving this very problem in 1976 for an
asr33, although that wasn't in C.

Not with the facilities of standard C, unless the button is the
end-of-line key, usually Enter or Carriage Return. Any other
ability is non-standard and unique to that system.

 

[Willem]

CBFalconer wrote:
) Not with the facilities of standard C, unless the button is the
) end-of-line key, usually Enter or Carriage Return. Any other
) ability is non-standard

Yes.

) and unique to that system.

No.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Stefan Ram]

CBFalconer wrote:
)Not with the facilities of standard C, unless the button is the
)end-of-line key, usually Enter or Carriage Return. Any other
)ability is non-standard
Yes.

No (regarding the first sentence). ISO/IEC 9899:1999 (E) only says:

»At program startup, three text streams are predefined and
need not be opened explicitly -- standard input (for
reading conventional input)«

That is all. No mentioning of »end-of-line keys«. Even a
hosted implementation of C does not seem to require a terminal
or a keyboard, unless I have missed something.

 

[CBFalconer]

No.

Unique in the sense that, while the extended ability may be copied,
its specification will not be, and thus the ability MAY perform
differently. For example, I often use and recommend:

int flushln(FILE *f) {
int ch;

while ((EOF != (ch = getc(f))) && ('\n' !- ch)) continue;
return ch;
}

which may be effectively duplicated in various ways. The most
likely difference is going to be that I return ch, so I can detect
i/o errors or end-of-file. Or someone can use the same code and
name it "lineflush", etc.

 

[CBFalconer]

No (regarding the first sentence). ISO/IEC 9899:1999 (E) only says:

»At program startup, three text streams are predefined and
need not be opened explicitly -- standard input (for
reading conventional input)«

That is all. No mentioning of »end-of-line keys«. Even a
hosted implementation of C does not seem to require a terminal
or a keyboard, unless I have missed something.

Conceded.

 

[Willem]

CBFalconer wrote:
) Unique in the sense that, while the extended ability may be copied,
) its specification will not be, and thus the ability MAY perform
) differently.

The specification of non-std-C functions need not be unique either.
That's what the other standards are for. POSIX for example.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Guest]

CBFalconer said:

[note: minor typo in code fixed]

[...] it has a poor name, as I will now attempt to demonstrate.

The C Standard does not provide a formal definition of the word
"flush", but it does provide a parenthetical definition, which it
never contradicts and which only one paragraph very slightly
undermines. I will take as my text the original ISO/IEC 9899:1999
cut that was ratified by ANSI in May 2000, but I would be very
surprised if either prior or later versions contradicted what I'm
about to demonstrate.

the problem with your "demonstartion" is that the standard isn't the
only source of inspiration for identifier names. As soon as we move to
areas not covered by the standard (GUIs, sockets, message switches) we
have to look elsewhere for names. Personally I find flushing input
a perfectly fine metaphor. Whilst working in Another Language I
defined
flush-stdin as a homage to clc (I also defined a ++ function).

The evidence is overwhelmingly in favour of flushing being an
operation performed not on input but only on output.

So flushln is a misnomer. Furthermore, the ln abbrev is pointless.
Why not say what we mean?

because we're C programmers and we *like* pointlessly abbreviated
identifier
names!

Here is a better name, in a whole range
of delicious flavours to suit every palate:

LineDiscard
Line_Discard
line_discard
lineDiscard
DiscardLine
Discard_Line
discard_line
discardLine

replace {Dd}iscard with any near-synonym you like - "ignore",
"reject", whatever.

I prefer

discard-characters-from-stream-until-end-of-line-indicator-reached

Personally I prefer to return ch != EOF, but that's merely a matter
of taste.


Or they could choose a good name that reflects the purpose of the
function.

--
Nick Keighley

"A clear statement is a statement to which the opposite is either true
or false. A deep statement is a statement to which the opposite is
another
deep statement." ­ Niels Bohr

 

[James Kuyper]

Unique in the sense that, while the extended ability may be copied,
its specification will not be,

That's the sense in which the "No" is appropriate. The ability may have
a specification which applies to a great many different systems.
Specifications are not uniquely the domain of the C standard; other
sources provide specifications that apply to more than one unique
system, without necessarily being applicable to all C implementations.

 

[CBFalconer]

CBFalconer said:
.... snip ...


gcc chokes big-time on this until I add #include <stdio.h>, which is
fair enough. But then it *still* chokes. Presumably you intended to
write != rather than !- but of course the compiler doesn't know
that.

Yes, that is a valid correction. You have saved many users.
.... snip about 150 lines of spouting ...

Or they could choose a good name that reflects the purpose of
the function.

I don't recall requesting that 150 odd lines of spouting about your
language choice peculiarities. Snipping it will probably reduce
the excess traffic on this newsgroup.

 

[CBFalconer]

That's the sense in which the "No" is appropriate. The ability may
have a specification which applies to a great many different systems.
Specifications are not uniquely the domain of the C standard; other
sources provide specifications that apply to more than one unique
system, without necessarily being applicable to all C implementations.

See underlining.

 

[Keith Thompson]

See underlining.

Yes, what about it? The underlined part is what Willem agreed with.
He disputed your claim that the ability is "unique to that system".
For example, such an ability might be common to all POSIX-compliant
systems.

 

[CBFalconer]

Yes, what about it? The underlined part is what Willem agreed with.
He disputed your claim that the ability is "unique to that system".
For example, such an ability might be common to all POSIX-compliant
systems.

I don't believe this. Are you now claiming that POSIX is part of
standard C? I don't find that word in any copy I have of the C
standard.

 

[luserXtrog]

Please TEST your code before posting. You would then save a lot of
people yourself. Having the unnecessary continue also deflects from
noticing the error of course and why I in over 20 years of programming I
have never known anyone use it for that use in C.

while ((EOF != (ch = getc(f))) && ('\n' != ch));

is better but still horrible. You have a habit or tendency to convolute
your code. This is C. C can and should be concise.

Platitudes and truisms.

while (((ch=getc(f))!=EOF)&&(ch!='\n'));

Is even clearer and reads properly left to right. I find it particularly
amusing that your pathetic defence of the " CONST == var" style is to
defend against "accidentally" using "=" instead of "==" and yet you
still fucked it up. Nice one. A real achievement.

We recently had quite a lengthy skirmish about this very issue.
The trend was unanimously against the zero-length statement
(nothing between the ')' and the ';') because of the statement's
syntactic significance.

My own preference tends toward a brief (possibly empty) comment,
perhaps:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) /*eat till \n*/;

or even:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) 0x2E0L;

;{>

As for the inverted const != var; in this case it draws the
comparison closer to the while keyword whose interest it serves.

<snipped bitchiness>

 

[Keith Thompson]

I don't believe this. Are you now claiming that POSIX is part of
standard C? I don't find that word in any copy I have of the C
standard.

What? No, of course I'm not claiming that POSIX is part of standard C.

Now pay attention.

You said that the ability to read a single input character without
waiting for an end-of-line is (a) non-standard (which is quite
correct, at least with regard to the C standard, and nobody has
disputed that point), and (b) "unique to that system" (which is quite
incorrect).

Why is the claim that such an ability is "unique to that system"
incorrect? Because there can be, and in fact are, multiple systems
that have the same ability in the same way. For example, Solaris,
AIX, and Ubuntu are all distinct systems, they're all POSIX-based, and
they all support that ability in the same way.

The ability is not standard, but it is *not unique*.

I could have avoided going off-topic by not mentioning POSIX, but a
concrete example illustrates the point more clearly.

You claimed that the ability is not standard and that it is unique.
You were correct about the former, but incorrect about the latter.

Yes, we are discussing something that is outside the scope of standard
C. Yes, it's off-topic. But please note that your incorrect claim
that the ability is "unique to that system" is a claim that *is not
supported by the C standard*.

(If you've read my entire followup, please quote this line.)