Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #95489 > unrolled thread

scanf used for to get a line

Back to article view | Back to comp.lang.c

Contents

  scanf used for to get a line asetofsymbols@gmail.com - 2016-11-01 01:50 -0700
    scanf used for to get a line asetofsymbols@gmail.com - 2016-11-01 01:55 -0700
    Re: scanf used for to get a line mark.bluemel@gmail.com - 2016-11-01 03:55 -0700
      Re: scanf used for to get a line "Charles Richmond" <numerist@aquaporin4.com> - 2016-11-03 11:23 -0500
        Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 09:38 -0700
          Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-03 10:08 -0700
            Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 11:29 -0700
              Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-03 14:37 -0700
                Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 16:34 -0700
                  Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-04 10:21 -0700
                    Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-04 11:46 -0700
                      Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-04 15:04 -0700
                        Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-04 16:44 -0700
                          Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-04 17:13 -0700
                            Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-04 19:12 -0700
                              Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-05 14:10 -0700
                                Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-05 14:22 -0700
            Re: scanf used for to get a line Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:57 -0800
              Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-15 12:05 -0800
                Re: scanf used for to get a line jameskuyper@verizon.net - 2016-11-15 14:01 -0800
                Re: scanf used for to get a line Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-16 10:54 -0800
                Re: scanf used for to get a line Richard Damon <Richard@Damon-Family.org> - 2016-11-21 18:01 -0500
                  Re: scanf used for to get a line supercat@casperkitty.com - 2016-11-21 15:44 -0800
        Re: scanf used for to get a line asetofsymbols@gmail.com - 2016-11-03 13:35 -0700
          Re: scanf used for to get a line Keith Thompson <kst-u@mib.org> - 2016-11-03 13:50 -0700
        Re: scanf used for to get a line ImperiusDamian <damianblack.wolf@gmail.com> - 2016-11-05 16:10 -0400
    Re: scanf used for to get a line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 11:39 +0000
      Re: scanf used for to get a line asetofsymbols@gmail.com - 2016-11-01 05:47 -0700
        Re: scanf used for to get a line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 15:05 +0000
          Re: scanf used for to get a line asetofsymbols@gmail.com - 2016-11-02 01:42 -0700

Page 2 of 2 — ← Prev page 1 [2]

#96710

supercat@casperkitty.com writes:

> On Tuesday, November 15, 2016 at 12:57:50 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Thursday, November 3, 2016 at 11:38:40 AM UTC-5, Keith Thompson wrote:
>>>> But be careful.  sscanf() has undefined behavior on numeric overflow.
>>>
>>> If one wanted to write the simplest strictly-conforming program that would
>>> e.g. read a line of input from stdin and:
>>>
>>>   1. If the input contains two signed numbers separated by a space, both
>>>      within the range of "long long", and their product is also within the
>>>      range of that type, output their product.
>>>
>>>   2. In all other cases, output any sequence of 0 to 1,000 characters and
>>>      exit.
>>>
>>> How should one make that program most simply?  [...]
>>
>> The problem statement is self-contradictory.  The output depends
>> on implementation-defined behavior, so the program cannot
>> possibly be strictly conforming.
>
> In what way would it depend upon implementation-defined behaviors to a
> greater extent than just about *any* other possibly-useful program?

You didn't ask for a possibly useful program, you asked for a
strictly conforming program.  And if what you want is a possibly
useful program, you should probably pick a different program
than this one.

> It
> would be possible to interpret the requirements for "strictly-conforming"
> programs so strictly that almost nothing could be done by strictly-
> conforming program, [...]

Yes, idiots can interpret things in arbitrarily stupid ways.

Incidentally, regular English usage does not place a hyphen in
phrases like "possibly useful program" or "strictly conforming
program".  The reason for a hyphen in this sort of situation is
to avoid ambiguity, eg, should "a b c" be parsed as "(a b) c" or
"a (b c)".  But "possibly" and "strictly" are adverbs, and hence
can modify only the following adjective, so no disambiguation is
needed.

[toc] | [prev] | [next] | [standalone]

#97223

On 11/15/16 3:05 PM, supercat@casperkitty.com wrote:
> On Tuesday, November 15, 2016 at 12:57:50 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Thursday, November 3, 2016 at 11:38:40 AM UTC-5, Keith Thompson wrote:
>>>> But be careful.  sscanf() has undefined behavior on numeric overflow.
>>>
>>> If one wanted to write the simplest strictly-conforming program that would
>>> e.g. read a line of input from stdin and:
>>>
>>>   1. If the input contains two signed numbers separated by a space, both
>>>      within the range of "long long", and their product is also within the
>>>      range of that type, output their product.
>>>
>>>   2. In all other cases, output any sequence of 0 to 1,000 characters and
>>>      exit.
>>>
>>> How should one make that program most simply?  [...]
>>
>> The problem statement is self-contradictory.  The output depends
>> on implementation-defined behavior, so the program cannot
>> possibly be strictly conforming.
>
> In what way would it depend upon implementation-defined behaviors to a
> greater extent than just about *any* other possibly-useful program?  It
> would be possible to interpret the requirements for "strictly-conforming"
> programs so strictly that almost nothing could be done by strictly-
> conforming program, but under such an interpretation the Standard would be
> pretty much useless.
>

Yes, VERY few program are 'strictly conforming'. Almost every useful 
program depends on some implementation defined behavior. You could 
change your problem statement to be 'within the GUARANTEED range of long 
long' (i.e. 64 bit signed integers).

Of course, because of your limitations you are imposing on overflow, you 
are going to need to check that the multiplication is not going to 
overflow before multiplying them, as an implementation is allowed to 
abort the program on signed overflow (perhaps in a diagnostic checking 
mode).

You point, is that you want to be able to write for the 'xx%' of 
processors that don't do anything funny on signed overflow and call it 
strictly conforming. Since strictly conforming is by definition 100%, 
this can't happen, but there is nothing wrong with designing a program 
and state as a requirement that the implementation needs to have a list 
of properties.

You also like to complain that some popular implementations, by default, 
optimize by assuming the freedom the standard gives for this undefined 
behavior, don't give you the behavior you desire. You tend to fail to 
remember that they provide options to turn off this behavior and give 
you the 'natural' behavior you want, at the cost of some optimizations 
that you don't want.

[toc] | [prev] | [next] | [standalone]

#97225

On Monday, November 21, 2016 at 5:01:55 PM UTC-6, Richard Damon wrote:
> Of course, because of your limitations you are imposing on overflow, you 
> are going to need to check that the multiplication is not going to 
> overflow before multiplying them, as an implementation is allowed to 
> abort the program on signed overflow (perhaps in a diagnostic checking 
> mode).

Implementations are a allowed to do a lot worse than that; given something
like: unsigned mul(unsigned short x, unsigned short y) { return x*y; } a
compiler that knows that y is 65535 might conclude that x cannot possibly
be greater than 32768, and silently omit code which would only be relevant
if x were greater than 32768.

> You point, is that you want to be able to write for the 'xx%' of 
> processors that don't do anything funny on signed overflow and call it 
> strictly conforming. Since strictly conforming is by definition 100%, 
> this can't happen, but there is nothing wrong with designing a program 
> and state as a requirement that the implementation needs to have a list 
> of properties.

I'd like to be able to write code which is focused more on its actual
purpose than on ensuring that behaviors remain at least minimally
constrained on all inputs.

> You also like to complain that some popular implementations, by default, 
> optimize by assuming the freedom the standard gives for this undefined 
> behavior, don't give you the behavior you desire. You tend to fail to 
> remember that they provide options to turn off this behavior and give 
> you the 'natural' behavior you want, at the cost of some optimizations 
> that you don't want.

The decisions regarding which actions should invoke UB were made on the
basis of whether there were any platforms where the cost of behavioral
guarantees would exceed the benefits.  If there are some platforms where
the cost of a behavioral guarantee would exceed the benefits, and others
where it would not, the logical way to handle that situation would be to
have platforms that can offer a guarantee cheaply, do so, and those that
can't, don't.  I don't know why people seem to think the authors of the
Standard were trying to make engineering judgments which should be relevant
for code which won't need to run on platforms that have been obsolete for
over a quarter century.

[toc] | [prev] | [next] | [standalone]

#95693

I use now the C without prototypes
and sys costant as stdin: For example I can do fflush(0) but not
fflush(stdout) 
Yes C is ok even not using prototypes (as int f( int a))
and abuse all the language
I not find errors of this type 
of absence of check...
so I can not use stdin and so not use fgets but scanf().
I use scanf because it is not serious code only for to game...

[toc] | [prev] | [next] | [standalone]

#95695

asetofsymbols@gmail.com writes:
> I use now the C without prototypes

Why on Earth would you do that?

> and sys costant as stdin: For example I can do fflush(0) but not
> fflush(stdout) 

fflush takes a FILE* argument.  fflush(0) passes a null pointer, not
stdin.  (The POSIX fileno for stdin is 0; stdin itself is a non-null
pointer of type FILE*.)  It happens that fflush(NULL) flushes all active
streams for which flushing is defined, so it will probably work by
accident.  (And of course fflush(stdin) has undefined behavior, though
an implementation can choose to define it.)

> Yes C is ok even not using prototypes (as int f( int a))
> and abuse all the language
> I not find errors of this type 
> of absence of check...
> so I can not use stdin and so not use fgets but scanf().
> I use scanf because it is not serious code only for to game...

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#95851

On 2016-11-03 12:23, Charles Richmond wrote:
> <mark.bluemel@gmail.com> wrote in message
> news:236c25a6-8c18-4082-ab3a-86eb55fb2408@googlegroups.com...
>> On Tuesday, 1 November 2016 08:50:54 UTC, asetof...@gmail.com  wrote:
>>> What about:
>>> char a[1024], c;
>>> int w, r;
>>> r=scanf("%1024[^\n]%c",a,&c);
>>> if(r<1)error();
>>> in the case \n is 2 characters?
>>
>> Scanf to read a line is a poor choice, but you need to understand that a
>> text stream, like stdin, will have platform specific line endings mapped
>> to a single character represented as '\n'
>>
>
> You might have fewer problems if you read the line with "fgets()" and
> then use "sscanf()" to parse out the results.
>

You beat me to it. "fgets()" is IMO a much better choice for reading 
single lines one at a time. I've learned that from experience.

-- 
"If you want to make an apple pie from scratch, you must first create
the universe." - Carl Sagan

SweetSpearGirl stories and Gemstone Mod:
http://imperium.elementfx.com/ - Now With Forums

[toc] | [prev] | [next] | [standalone]

#95497

asetofsymbols@gmail.com writes:

> What about:
> char a[1024], c;
> int w, r;
> r=scanf("%1024[^\n]%c",a,&c);

You need to put 1023 there or the result might not be null terminated.

> if(r<1)error();

There are other conditions that might be considered errors -- for
example getting only one result (and no line ending) or reading nothing
at all.  It's usually better to test for what you want rather than
trying to test for all the ways things can go wrong.

> in the case \n is 2 characters?

That's not a problem if the input stream is a text stream (which stdin
is by default).  C takes care of the line endings -- you see a single
'\n' at the end of every line no matter what method the OS uses to
signal the end of text lines.

You might want to try something more complex like this:

  r = scanf("%1023[^\n]%*[^\n]%c%n", a, &c, &n);

This (a) reads non-newline characters but no more than will fit; (b)
reads and discards any remaining non-newline characters; (c) reads
whatever follows (so we can check that it's a newline) and (d) stores
the number of characters consumed so we can check if anything was
discarded.  Full success is that r == 2 && c == '\n' && n <= sizeof a.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#95505

Ben wrote:
>Ros wrote:
#Ros write
> What about: 
> char a[1024], c; 
> int w, r; 
> r=scanf("%1024[^\n]%c",a,&c); 


You need to put 1023 there or the result might not be null terminated. 

> if(r<1)error(); 

There are other conditions that might be considered errors -- for 
example getting only one result (and no line ending)

#If no line end found means: 
#1) found EOF, in this case r==1 and 
#this is ok 
#or
#2) the line is > 1024 so 

#scanf would has to return 0 so r==0
#this is for me an error so ok too

 or reading nothing 
at all.

#r==0 error ok

  It's usually better to test for what you want rather than 
trying to test for all the ways things can go wrong.

#I would get
# one string, than use sscanf
#for to get the numbers from 
#that string

[toc] | [prev] | [next] | [standalone]

#95510

You quoting is all messed up.  People who read >s and attribution lines
should just ignore them is this post.

asetofsymbols@gmail.com writes:

> Ben wrote:
>>Ros wrote:
> #Ros write
>> What about: 
>> char a[1024], c; 
>> int w, r; 
>> r=scanf("%1024[^\n]%c",a,&c); 
>
>
> You need to put 1023 there or the result might not be null terminated. 
>
>> if(r<1)error(); 
>
> There are other conditions that might be considered errors -- for 
> example getting only one result (and no line ending)
>
> #If no line end found means: 
> #1) found EOF, in this case r==1 and 
> #this is ok

Obviously it's up to the application to decide what's an error or not,
but I'd want a general-purpose line-input function to indicate that it
got data, but no terminating newline.  YMMV, of course.

> #or
> #2) the line is > 1024 so 
>
> #scanf would has to return 0 so r==0

No, for a long line, scanf will return 2 (but c won't be '\n').

> #this is for me an error so ok too

Then you need to detect it.

>  or reading nothing 
> at all.
>
> #r==0 error ok
>
>   It's usually better to test for what you want rather than 
> trying to test for all the ways things can go wrong.
>
> #I would get
> # one string, than use sscanf
> #for to get the numbers from 
> #that string

That's a good strategy, but you probably need to check if the line was
truncated.  If the last number was "cut off" you'll get incorrect data
and no indication that it's incorrect.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#95565

Ben wrote:
<That's a good strategy, but you probably need to check if the line was 
truncated.  If the last number was "cut off" you'll get incorrect data 
and no indication that it's incorrect.
------------------
Ok in c=0;r= scanf("%1020[^\n]%c", a, &c)
I consider valid input when r==2 and c=='\n'

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web