Input Length

[CBFalconer]

I think that I finally found a solution. It looks a little bit
unconventional, but it finally seems to work. I built an endless
loop around it, to see if the entry is buffered and is written
into the variable after the loop passes the second time.

A short time ago I answered you, saying:

"See my post of 2006-01-31, subject line "checking and verifying
input line in a C program", in this newsgroup (c.l.c). Basically
use the provided streams, without buffers, and base things on
acquiring unsigned values. That code also illustrates prechecking
that a calculation will not overflow, based on limits.h."

Did you ever bother to read that, which included tested code to
handle exactly your problem? Everything you have published seems
to have gaping security and accuracy holes.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

 

[Default User]

I wrote to _my own_ reply, so I didn't say that to another user.

So. What?

We STILL need the damn context. How hard is this concept for you?


Brian

 

[Flash Gordon]

I already got it. I was already pointed to it out, so you don't have to
repeat it over and over again, and I think I already said that I deleted

<snip>

Usenet (a.k.a. news groups) are an asynchronous medium. Brian had
probably not seen the other messages pointing out the need to provide
context when he replied.

 

[Markus Pitha]

Hello,

Did you ever bother to read that, which included tested code to
handle exactly your problem? Everything you have published seems
to have gaping security and accuracy holes.

Sure did I. That's why I came to "getc", but why is my code so much
worse as you say now? And why did you say in your "checking and
verifying"-posting that your code is for "local use only"? Just for the
reason that it violates the principle of leaving the terminating char in
the input stream? Why is that so bad?


Markus.

 

[Markus Pitha]

We STILL need the damn context. How hard is this concept for you?

I already got it. I was already pointed to it out, so you don't have to
repeat it over and over again, and I think I already said that I deleted
this one reply, but if you'd like to see the previous posting, it's this
one:

#include <stdio.h>

int main(void) {
int c;
int i = 0;
char str[11];

while( ((c = getchar()) != '\n') ) {
if (i < 10) {
str = c;
}
i++;
}
str[10] = '\0';

printf("Output: %s\n", str);

return 0;
}


It seems to be safe, or at least I wouldn't know, how to outfox it.

Markus.

 

[CBFalconer]

Sure did I. That's why I came to "getc", but why is my code so
much worse as you say now? And why did you say in your "checking
and verifying"-posting that your code is for "local use only"?
Just for + reason that it violates the principle of leaving the
terminating char in the input stream? Why is that so bad?

I didn't write that for your benefit, but for mine in general use.
By maintaining the principle that the stream always holds the
terminating character I greatly simplify usage. By marking that
routine as static, thus ensuring it is not visible outside the one
file, I avoid disturbing that principle and having to remember or
document exceptions.

The code you published was not compilable, and placed characters in
some sort of undocumented buffer. By definition any such code
cannot handle an indefinite string of leading zeroes. My code
extracts a number from an input stream of characters, detects and
signals overflows, and preserves the terminating char for whatever
use the application wants to make of it. It also detects the
absence of any numeric input. This makes it satisfactory (IMO) for
interactive use. Which, I believe, was the original problem, and
is totally non-evident here for lack of earlier context.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Keith Thompson]

What's the best way, to solve the difficulty of too big entries and
resulting wrong calculations of the program.

I think that I finally found a solution. It looks a little bit
unconventional, but it finally seems to work. I built an endless loop
around it, to see if the entry is buffered and is written into the
variable after the loop passes the second time.

while(1) {
i = 0;
nmbr1[0] = '\0'; // that you don't get the input of the last time,
//if you only press enter after typing nothing.
while ((c = getc(stdin)) != '\n') {
if (i < 10) {
nmbr1 = c;
nmbr1[i+1] = '\0';
}
i++;
}
printf("output: %s\n", nmbr1);
}

You haven't shown us the declarations of i, c, or nmbr1. Presumably c
is of type int (using char rather than int is a common error). nmbr1
is either a pointer or an array. We can't tell how much memory is
allocated to it.

You only need to store the '\0' string terminator once, not every time
through the loop.

Your loop continues executing as long as getc() doesn't return '\n'.
There's no guarantee that it *ever* will. I think someone already
pointed out that if you reach end-of-file on stdin before the end of
the line, you have an infinite loop.

If you showed us a complete program, we could comment more
intelligently on it; there could be any number of problems in the
portions you aren't showing us.

 

[Default User]

I already got it. I was already pointed to it out, so you don't have
to repeat it over and over again,

Except that I read things in thread order, and hadn't gotten to that
point.

and I think I already said that I
deleted this one reply, but if you'd like to see the previous
posting, it's this one:

You need to learn about cancels, they seldom work.


Brian

 

[Dave Thompson]

Yes, that is my reason for using them. It's also why when using malloc I
write:
ptr = malloc(n * sizeof *ptr)
instead of
ptr = malloc(sizeof *ptr * n)

Well, the reason _I_ do that (former) is because it more accurately
reflects the type of the space being allocated: "array N of T". That
it also prevents confusion about precedence is just a bonus.

- David.Thompson1 at worldnet.att.net

 

[Flash Gordon]

Well, the reason _I_ do that (former) is because it more accurately
reflects the type of the space being allocated: "array N of T". That
it also prevents confusion about precedence is just a bonus.

I don't care why you do it my way as long as you do do it my way ;-)

I agree with you that it reads well for your reasons.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc