Input Length

[Chris Dollin]

Re: Input Length

Markus Pitha wrote:
[color=blue]
> Default User wrote:[color=green]
>> What is?[/color]
>
> I wrote to _my own_ reply, so I didn't say that to another user.[/color]

If you were replying to yourself, you didn't need to use the newsgroup.

--
Chris "understand ing is a three-edged sword" Dollin

[Markus Pitha]

Re: Input Length

Hello,

Chris Dollin wrote:[color=blue]
> If you were replying to yourself, you didn't need to use the newsgroup.[/color]

I just replied to my own message that people don't need to think about
the reply before, because my solution was not a real solution as I found
out after I already postet my message.

Markus

[Markus Pitha]

Re: Input Length

Hello,

Keith Thompson schrieb:[color=blue]
> Ok. You need to provide context for *any* followup, even if it's to
> your own message. And because of the way Usenet works, cancelling an
> article often doesn't work. Articles are copied from site to site all
> over the world; a cancellation often can't catch up with all copies of
> the article, even for sites that recognize cancel requests.[/color]

Ok, I'll make it so from now on. I was used to it from different forums.

Markus

[Chris Dollin]

Re: Input Length

Markus Pitha wrote:
[color=blue]
> Hello,
>
> Chris Dollin wrote:[color=green]
>> If you were replying to yourself, you didn't need to use the newsgroup.[/color]
>
> I just replied to my own message that people don't need to think about
> the reply before, because my solution was not a real solution as I found
> out after I already postet my message.[/color]

Then quote enough text to make sense, please - remember that other people
may see messages in a different order than you do, may never see some
messages at all, and may see messages you don't; it's intrinsic to the
medium.

--
Chris "understand ing is a three-edged sword" Dollin

[Markus Pitha]

Re: Input Length

Hello,

I wrote:[color=blue]
> What's the best way, to solve the difficulty of too big entries and
> resulting wrong calculations of the program.[/color]

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[i] = c;
nmbr1[i+1] = '\0';
}
i++;
}
printf("output: %s\n", nmbr1);
}



Markus.

[CBFalconer]

Re: Input Length

Markus Pitha wrote:[color=blue]
> I wrote:
>[color=green]
>> What's the best way, to solve the difficulty of too big entries
>> and resulting wrong calculations of the program.[/color]
>
> 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.[/color]

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]

Re: Input Length

Markus Pitha wrote:
[color=blue]
> Default User wrote:[color=green]
> > What is?[/color]
>
> I wrote to _my own_ reply, so I didn't say that to another user.[/color]


So. What?

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


Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Markus Pitha]

Re: Input Length

Hello,

CBFalconer wrote:[color=blue]
> 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.[/color]

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]

Re: Input Length

Default User wrote:[color=blue]
> We STILL need the damn context. How hard is this concept for you?[/color]

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:
[color=blue]
> #include <stdio.h>
>
> int main(void) {
> int c;
> int i = 0;
> char str[11];
>
> while( ((c = getchar()) != '\n') ) {
> if (i < 10) {
> str[i] = 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.[/color]


Markus.

[Flash Gordon]

Re: Input Length

Markus Pitha wrote:[color=blue]
> Default User wrote:[color=green]
>> We STILL need the damn context. How hard is this concept for you?[/color]
>
> 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[/color]

<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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Keith Thompson]

Re: Input Length

Markus Pitha <markus@pithax. net> writes:[color=blue]
> I wrote:[color=green]
>> What's the best way, to solve the difficulty of too big entries and
>> resulting wrong calculations of the program.[/color]
>
> 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[i] = c;
> nmbr1[i+1] = '\0';
> }
> i++;
> }
> printf("output: %s\n", nmbr1);
> }[/color]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Re: Input Length

Markus Pitha wrote:[color=blue]
> CBFalconer wrote:
>[color=green]
>> 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.[/color]
>
> 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?[/color]

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.c om, 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/googlegroupsrep ly/>

[Default User]

Re: Input Length

Markus Pitha wrote:
[color=blue]
> Default User wrote:[color=green]
> > We STILL need the damn context. How hard is this concept for you?[/color]
>
> I already got it. I was already pointed to it out, so you don't have
> to repeat it over and over again,[/color]

Except that I read things in thread order, and hadn't gotten to that
point.
[color=blue]
> 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:[/color]

You need to learn about cancels, they seldom work.


Brian

[Dave Thompson]

Re: Input Length

On Thu, 02 Feb 2006 23:18:48 +0000, Flash Gordon
<spam@flash-gordon.me.uk> wrote:
[color=blue]
> Richard Heathfield wrote:[color=green]
> > Mark B said:[/color][/color]
(parentheses in (sizeof x)-1)[color=blue][color=green]
> > They save the writer and the reader from having to reach for their
> > precedence tables.[/color]
>
> 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)
>[/color]
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.ne t

[Flash Gordon]

Re: Input Length

Dave Thompson wrote:[color=blue]
> On Thu, 02 Feb 2006 23:18:48 +0000, Flash Gordon
> <spam@flash-gordon.me.uk> wrote:
>[color=green]
>> Richard Heathfield wrote:[color=darkred]
>>> Mark B said:[/color][/color]
> (parentheses in (sizeof x)-1)[color=green][color=darkred]
>>> They save the writer and the reader from having to reach for their
>>> precedence tables.[/color]
>> 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)
>>[/color]
> 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.[/color]

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