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

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

Text Files

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

Contents

  Text Files G B <gb@gb.com> - 2018-02-14 11:47 -0400
    Re: Text Files Ed Prochak <edprochak@gmail.com> - 2018-02-14 08:45 -0800
    Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-14 08:47 -0800
      Re: Text Files already5chosen@yahoo.com - 2018-02-15 01:17 -0800
    Re: Text Files gordonb.ea2mq@burditt.org (Gordon Burditt) - 2018-02-14 11:10 -0600
    Re: Text Files "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-14 12:28 -0500
    Re: Text Files jt@toerring.de (Jens Thoms Toerring) - 2018-02-14 21:07 +0000
    Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-14 15:31 -0700
      Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-15 06:59 +0000
        Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 10:20 +0000
    Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-14 22:51 +0000
      Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 11:04 +0100
        Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-15 06:16 -0800
          Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:22 +0800
          Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 15:58 +0100
            Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 16:31 +0000
              Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:31 +0100
                Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:21 +0000
                  Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:17 +0000
                    Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:36 +0000
                      Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:48 +0000
                  Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:09 +0100
                    Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:57 +0000
                      Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 15:50 +0100
                        Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 15:50 +0000
                          Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:07 +0100
                            Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:44 +0000
                              Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:22 +1300
                          Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 17:48 +0000
                        Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-16 17:06 +0100
                      Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:10 +1300
                      Re: Text Files supercat@casperkitty.com - 2018-02-16 14:48 -0800
                        Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-16 15:14 -0800
                          Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 23:25 +0000
                          Re: Text Files supercat@casperkitty.com - 2018-02-16 15:50 -0800
            Re: Text Files already5chosen@yahoo.com - 2018-02-16 07:19 -0800
              Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:13 +0100
                Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-19 17:55 +0000
                  Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-19 19:14 +0100
                  Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-19 11:48 -0800
              Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 08:14 -0800
                Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-17 18:32 -0600
      Re: Text Files jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-15 22:57 +0100
        Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:58 +0000
          Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 00:19 +0000
            Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 02:26 +0000
              Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 02:57 +0000
                Re: Text Files asetofsymbols@gmail.com - 2018-02-16 00:21 -0800
                  Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:30 +0000
            Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:36 +0100
              Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:36 +0000
                Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 13:10 +0100
                  Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:25 +0000
                    Re: Text Files Ike Naar <ike@iceland.freeshell.org> - 2018-03-06 19:33 +0000
                      Re: Text Files bartc <bc@freeuk.com> - 2018-03-06 20:55 +0000
                  Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:42 -0800
                    Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 16:58 +0100
                      Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:02 +0000
                        Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 21:43 +0100
                      Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:01 -0800
                        Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 13:10 +0000
                          Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 05:27 -0800
                            Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 14:20 +0000
                    Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-16 09:04 -0700
                  Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 14:31 +0000
                    Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 06:42 -0800
                      Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 14:58 +0000
                        Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 07:23 -0800
                      Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 15:24 +0000
                Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:13 -0800
                  Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-16 04:29 -0800
                    Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 16:41 +0000
                      Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-20 09:39 -0800
                        Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 19:16 +0000
    Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 12:46 +0000
      Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 14:52 +0100
      Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 17:07 +0300
        Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 14:23 +0000
          Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 18:52 +0300
      Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 14:39 +0000
        Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 15:43 +0000
          Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 20:32 +0000
            Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 22:06 +0000
              Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 23:12 +0100
              Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 15:12 -0800
                Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:43 +0000
                  Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:54 +0000
              Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:35 +0000
            Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-16 17:07 -0800
              Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 02:38 +0000
                Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 17:26 +1300
                  Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 11:22 +0000
                  Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 12:07 +0000
                    Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:17 -0800
                      Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-17 16:25 +0300
                        Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 07:35 -0800
                      Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-17 15:24 +0100
                    Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-18 11:10 +1300
                Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:05 -0800
                  Re: Text Files already5chosen@yahoo.com - 2018-02-19 15:32 -0800
                    Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 10:34 -0800
                      Re: Text Files already5chosen@yahoo.com - 2018-02-21 15:35 -0800
                        Re: Text Files bartc <bc@freeuk.com> - 2018-02-22 00:11 +0000
                      Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:26 -0600
                        Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:39 -0800
                          Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-23 03:08 -0600
                            Re: Text Files supercat@casperkitty.com - 2018-02-23 16:16 -0800
                              Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-23 16:46 -0800
                                Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-24 02:49 -0800
                                  Re: Text Files asetofsymbols@gmail.com - 2018-02-24 05:16 -0800
                                    Re: Text Files "F. Russell" <fr@random.info> - 2018-02-24 14:35 +0000
                                      Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-24 08:48 -0700
                                Re: Text Files supercat@casperkitty.com - 2018-02-25 15:09 -0800
                                  Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:54 -0800
                                    Re: Text Files supercat@casperkitty.com - 2018-02-26 11:04 -0800
                                      Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 11:52 -0800
                                    Re: Text Files supercat@casperkitty.com - 2018-02-26 14:12 -0800
                                      Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 14:40 -0800
                        Re: Text Files already5chosen@yahoo.com - 2018-02-22 04:58 -0800
                          Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 05:33 -0800
                          Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-22 13:59 +0000
                            Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 07:24 -0800
                Re: Text Files supercat@casperkitty.com - 2018-02-20 12:14 -0800
          Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:37 +0100
            Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:34 +0000
              Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 14:15 -0800
              Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:47 +0100
    Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:20 +0800
    Re: Text Files "F. Russell" <fr@random.info> - 2018-02-15 15:24 +0000
      Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 16:05 +0000
      Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-16 00:22 +0800
      Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-15 13:35 -0700
    Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 00:13 +0300
      Re: Text Files bartc <bc@freeuk.com> - 2018-02-24 21:24 +0000
        Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 14:55 +0300
          Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 13:00 +0000
      Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:35 -0400
      Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 21:36 +0000
        Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:45 -0400
        Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-24 22:51 +0000
          Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 23:56 +0000
            Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:14 +0000
              Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:22 +0000
              Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:16 +0300
                Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:20 -0800
                  Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-25 20:27 -0700
                  Re: Text Files gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 06:19 +0000
                  Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 15:35 +0300
                    Re: Text Files Reinhardt Behm <rbehm@hushmail.com> - 2018-02-26 20:53 +0800
                      Grammar Patrol (Was: Text Files) gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 17:54 +0000
                    Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-26 15:27 +0000
                      Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 18:50 +0300
                        Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:26 -0800
                          Re: Text Files scott@slp53.sl.home (Scott Lurndal) - 2018-02-26 19:46 +0000
                          Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 09:04 +0100
                            Re: Text Files already5chosen@yahoo.com - 2018-02-27 00:56 -0800
                              Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-27 22:07 +1300
                                Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 14:37 +0100
                                  Re: Text Files already5chosen@yahoo.com - 2018-02-27 07:38 -0800
                                    Re: Text Files supercat@casperkitty.com - 2018-02-27 09:18 -0800
                              Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 10:15 +0100
                              Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-27 08:53 -0800
                        Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 23:14 -0800
                    Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-26 08:32 -0700
                    Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:17 -0800
                    Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:55 -0800
        Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:02 +0300
          Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:12 +0000

Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

#126989

already5chosen@yahoo.com writes:
<snip>
> For non-toy usage, an absence of equivalent of endptr parameter of
> strtoxxx() is IMHO the most lethal of fatal flows of sscanf().

There is %n as used in the all the examples in this sub-thread.

I think f?scanf (not sscanf) would have had a better reception had there
been a way to prevent the automatic space-skipping from consuming a
newline since that seems to requested in the kind of begginers' programs
that scanf is certainly well suited to.

> The biggest flow of sscanf() in toy programs is consumption of
> programmer's memory cells. They (cells) could be put to better use
> than remembering its quirks.

There aren't /that/ many quirks, and much of the syntax is closely
related to printf formats which don't get anything like the same
opprobrium heaped upon them.

-- 
Ben.

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

#126990

On Thursday, February 22, 2018 at 2:00:09 PM UTC, Ben Bacarisse wrote:
> already5chosen@yahoo.com writes:
> 
> > The biggest flow of sscanf() in toy programs is consumption of
> > programmer's memory cells. They (cells) could be put to better use
> > than remembering its quirks.
> 
> There aren't /that/ many quirks, and much of the syntax is closely
> related to printf formats which don't get anything like the same
> opprobrium heaped upon them.
> 
That's because you can play with the printf formats, observing the
effect on the output, until you achieve what you desire. It's harder
to set up an input for scanf that triggers the behaviour of a poorly
understood format specifier.

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

#126908

On Friday, February 16, 2018 at 8:38:49 PM UTC-6, Ben Bacarisse wrote:
> It's a real shame that scanf's number conversions were not defined on
> overflow.  I say that never having had to implement it that way, so
> there may be a reason why it is onerous to require it.  As things stand,
> the naysayers have the trump card with the behaviour on overflow.

The problem is that by the time the Standard was written, different
implementations were doing different incompatible things that at least
some applications found useful.  Mandating any particular behavior would
have meant breaking some applications, and no particular behavior was
sufficiently "better" than any other to justify it as the one and only
"correct" behavior.  IMHO the authors of the Standard should have had the
courage to suggest how implementations should behave when practical, but
the authors of the Standard instead avoided saying anything that might be
seen as branding some implementations as "unusual".

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

#126752

On 15/02/18 16:43, bartc wrote:

> 
> I thought at last, I can run one of Ben's examples with my compiler. But 
> it says, 'Can't do VLAs'! I needed to change numbers_per_line to an enum.
> 
> Note that on error, your program says 'Bad input on line zu'.
> 
> And you have a go at me for using 'int64_t'!
> 

Perhaps since you used C99 features in your code, Ben was fooled into 
thinking you had joined this century and learned how to compile C99 
code.  Apparently not.

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

#126757

On 15/02/2018 20:37, David Brown wrote:
> On 15/02/18 16:43, bartc wrote:
> 
>>
>> I thought at last, I can run one of Ben's examples with my compiler. 
>> But it says, 'Can't do VLAs'! I needed to change numbers_per_line to 
>> an enum.
>>
>> Note that on error, your program says 'Bad input on line zu'.
>>
>> And you have a go at me for using 'int64_t'!
>>
> 
> Perhaps since you used C99 features in your code, Ben was fooled into 
> thinking you had joined this century and learned how to compile C99 
> code.  Apparently not.

I get the same 'Bad input on line zu' message using gcc 5.1.0.

I don't like those features I've listed from C99/C11 that I don't 
implement because I think they are out of keeping with the rest of the 
language. But also they've rarely come up in open source code I've tried 
to compile.

(I do like Generic, but only because it looks interesting to implement, 
not that I will ever use it.)

-- 
bartc

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

#126761

bartc <bc@freeuk.com> writes:
> On 15/02/2018 20:37, David Brown wrote:
[...]
>> Perhaps since you used C99 features in your code, Ben was fooled into 
>> thinking you had joined this century and learned how to compile C99 
>> code. Apparently not.
>
> I get the same 'Bad input on line zu' message using gcc 5.1.0.

Support for "%zu" is determined by the runtime library, not by the
compiler.

[...]

-- 
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]

#126779

On 15/02/18 22:34, bartc wrote:
> On 15/02/2018 20:37, David Brown wrote:
>> On 15/02/18 16:43, bartc wrote:
>>
>>>
>>> I thought at last, I can run one of Ben's examples with my compiler.
>>> But it says, 'Can't do VLAs'! I needed to change numbers_per_line to
>>> an enum.
>>>
>>> Note that on error, your program says 'Bad input on line zu'.
>>>
>>> And you have a go at me for using 'int64_t'!
>>>
>>
>> Perhaps since you used C99 features in your code, Ben was fooled into
>> thinking you had joined this century and learned how to compile C99
>> code.  Apparently not.
> 
> I get the same 'Bad input on line zu' message using gcc 5.1.0.
> 

You will get that if you are using a C90 library - the "%z" conversion
specifier is from C99.  This is typically the result of linking to MS's
limited C90 C library, rather than a C99 one - that is one reason why
you should use mingw-w64 rather than older mingw (or tdm) versions.
(Plus mingw-w64 is faster since it uses a statically linked C library
instead of a DLL.)  You may have a C99 compiler, but it is not a C99
implementation unless matched by the library.

> I don't like those features I've listed from C99/C11 that I don't
> implement because I think they are out of keeping with the rest of the
> language. But also they've rarely come up in open source code I've tried
> to compile.

So your list was things you don't like, not things that Ben "generally
makes use of" as you said?  It seems an odd list, but okay - you decide
on your own likes and dislikes, and how conforming or not your compiler is.

> 
> (I do like Generic, but only because it looks interesting to implement,
> not that I will ever use it.)
> 

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

#126725

On 14/2/2018 23:47, G B wrote:
 > ....
> 06    09    40    43    46    48
>
> I want to read numbers: a, b, c, d, e, f and do some tests on it and
> then go to the next line and do the same.
>
> In some languages, it was possible to do something like this:

Do it in Visual Foxpro! Piece of cake! ;)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#126732

On Wed, 14 Feb 2018 11:47:00 -0400, G B wrote:

> what is the best way to read numbers 
> line by line and do some tests on numbers for that line before moving to 
> the next line?  for example the text file might be:
> 
> 07    23    36    52    53    57
> 

The best way is NOT to read the file line by line.  The I/O
overhead is a problem.

Read the entire file into memory and then process.

Here is just a program fragment:

char *buffer;
long file_size;

FILE *fd = fopen(argv[1], "rb");
fseek(fd, 0, SEEK_END);
file_size = ftell(fd);
rewind(fd);
buffer=malloc(file_size *(sizeof(char)));
fread(buffer, sizeof(char), file_size, fd);
fclose(fd);

Now you can step through the buffer and process
the numbers.

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

#126736

"F. Russell" <fr@random.info> writes:

> On Wed, 14 Feb 2018 11:47:00 -0400, G B wrote:
>
>> what is the best way to read numbers 
>> line by line and do some tests on numbers for that line before moving to 
>> the next line?  for example the text file might be:
>> 
>> 07    23    36    52    53    57
>
> The best way is NOT to read the file line by line.  The I/O
> overhead is a problem.

How do you know that?

> Read the entire file into memory and then process.

As you have sketched it, this method has it's own problems.  The one I'd
be most concerned about is that you can't pipe data to it.  I often find
I want to write program to generate or filter or otherwise pre-process
the data and going through a file every time is a pain.

If you are doing the sort of investigative data analysis that I often
find myself doing, you want a flexible, pluggable set of tools.

> Here is just a program fragment:
>
> char *buffer;
> long file_size;
>
> FILE *fd = fopen(argv[1], "rb");
> fseek(fd, 0, SEEK_END);
> file_size = ftell(fd);
> rewind(fd);
> buffer=malloc(file_size *(sizeof(char)));

sizeof (char) is guaranteed to be 1.  It's not wrong to use it, of
course, but I always wonder about why the author put it there and that
slows me down a bit.

I'd add one to the size and then null-terminate the array so as to have
the file contents as a string.  You've got the probable size, so you
don't need to, but it makes the processing loop easier if it's a string.

> fread(buffer, sizeof(char), file_size, fd);
> fclose(fd);
>
> Now you can step through the buffer and process
> the numbers.

Since the file was read as binary data, you will have to manage the
line endings yourself if the program is intended to be portable.  It's
likely this one isn't, and also likely that differences in line endings
can be ignored, so this is not a big problem.

-- 
Ben.

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

#126737

On 15/2/2018 23:24, F. Russell wrote:
>
> The best way is NOT to read the file line by line.  The I/O
> overhead is a problem.
>
> Read the entire file into memory and then process.
>

Don't worry! The OS should make use of disk caches auto-magically, 
unless your program explicitly use un-buffered I/O....

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#126751

"F. Russell" <fr@random.info> writes:

> On Wed, 14 Feb 2018 11:47:00 -0400, G B wrote:
>
>> what is the best way to read numbers 
>> line by line and do some tests on numbers for that line before moving to 
>> the next line?  for example the text file might be:
>> 
>> 07    23    36    52    53    57
>> 
>
> The best way is NOT to read the file line by line.  The I/O
> overhead is a problem.
>
> Read the entire file into memory and then process.

If people were suggesting he call read() I'd agree with you.  All the
suggestions I've seen so far are from stdio; we can assume plenty of
buffering in the library without needing to worry about it ourselves.

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

#127015

G B:

> If  you  have  a text file of numbers, what is the
> best way to read numbers line by line and do  some
> tests  on  numbers  for that line before moving to
> the next line?  for example the  text  file  might
> be:
>
> 07    23    36    52    53    57
> 02    04    09    15    25    51
> 02    03    11    14    18    21
> 22    22    23    28    33    54
> 16    19    26    48    58    58
> 04    28    42    48    56    57
> 05    13    18    21    45    46
> 05    22    23    29    31    58
> 01    03    07    14    16    55
> 06    09    40    43    46    48
>
> I  want  to  read numbers: a, b, c, d, e, f and do
> some tests on it and then go to the next line  and
> do the same.
>
> In some languages, it was possible to do something
> like this:
>
> While Not EOF (Infile) Do
> Begin
>      ReadLn (InFile, a, b, c, d, e, f);
>      // Write test code here
> End;
>
> I want something similar in C or C++.

It is too quite here.

#include <stdio.h>

typedef struct reader_t
{  int            n;
   int            sp;
   FILE*          file;
   char*          sbuf;
   unsigned char* nbuf;
   int            size;
} reader_t;

const int DIGIT_N = 2;

void initreader( reader_t * readerP, int n, int sp, char* path )
{  readerP->n    = n;
   readerP->sp   = sp;
   readerP->file = fopen( path, "r" );
   readerP->size = n * DIGIT_N + (n - 1) * sp + 2;
   readerP->sbuf = (          char* )malloc( readerP->size );
   readerP->nbuf = ( unsigned char* )malloc( readerP->n );
}

int readrow( reader_t * readerP )
{  int res, i;
   char* pos;
   if( fgets( readerP->sbuf, readerP->size, readerP->file ) == NULL )
   {  res = 0;  }
   else
   {  pos = readerP->sbuf;
      for( i = 0; i < readerP->n; i++ )
      {  readerP->nbuf[i] = atoi( pos );
         pos = pos + readerP->sp + DIGIT_N;
      }
      res = 1;
   }
   return res;
}

void deinitreader( reader_t * readerP )
{  free  ( readerP->sbuf );
   free  ( readerP->nbuf );
   fclose( readerP->file );
}

int main( int argc, char** argv )
{  const int NUMCOUNT = 6;
   int i;
   reader_t r;

   initreader( &r, NUMCOUNT, 4, "test.txt" );
   while( readrow( &r ) )
   {  for( i = 0; i < NUMCOUNT; i++ )
      {  printf("%3i ", r.nbuf[i] );  }
      printf("\n");
   }
   deinitreader( &r );

   return 0;
}

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#127017

On 24/02/2018 21:13, Anton Shepelev wrote:
> G B:
> 
>> If  you  have  a text file of numbers, what is the
>> best way to read numbers line by line and do  some
>> tests  on  numbers  for that line before moving to
>> the next line?  for example the  text  file  might
>> be:
>>
>> 07    23    36    52    53    57
>> 02    04    09    15    25    51
>> 02    03    11    14    18    21
>> 22    22    23    28    33    54
>> 16    19    26    48    58    58
>> 04    28    42    48    56    57
>> 05    13    18    21    45    46
>> 05    22    23    29    31    58
>> 01    03    07    14    16    55
>> 06    09    40    43    46    48
>>
>> I  want  to  read numbers: a, b, c, d, e, f and do
>> some tests on it and then go to the next line  and
>> do the same.
>>
>> In some languages, it was possible to do something
>> like this:
>>
>> While Not EOF (Infile) Do
>> Begin
>>       ReadLn (InFile, a, b, c, d, e, f);
>>       // Write test code here
>> End;
>>
>> I want something similar in C or C++.
> 
> It is too quite here.
> 
> #include <stdio.h>

>     readerP->sbuf = (          char* )malloc( readerP->size );
>     readerP->nbuf = ( unsigned char* )malloc( readerP->n );

Needs stdlib.h.

2 compilers out of 7 reported an error, and 4 a warning.

Otherwise it seemed to work on the test data.

-- 
bartc

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

#127031

bartc to Anton Shepelev:

> > #include <stdio.h>
> >
> > readerP->sbuf = (          char* )malloc( readerP->size );
> > readerP->nbuf = ( unsigned char* )malloc( readerP->n );
>
> Needs  stdlib.h.  2 compilers out of 7 reported an
> error, and 4 a warning.

Indeed.  Why  does  not  TCC  require  stdlib.h  for
malloc() and free()?

> Otherwise it seemed to work on the test data.

That was my purpose.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#127036

On 25/02/2018 11:55, Anton Shepelev wrote:
> bartc to Anton Shepelev:
> 
>>> #include <stdio.h>
>>>
>>> readerP->sbuf = (          char* )malloc( readerP->size );
>>> readerP->nbuf = ( unsigned char* )malloc( readerP->n );
>>
>> Needs  stdlib.h.  2 compilers out of 7 reported an
>> error, and 4 a warning.
> 
> Indeed.  Why  does  not  TCC  require  stdlib.h  for
> malloc() and free()?

It reads them as implicitly defined functions, without bothering to 
report that. It will eventually link the program and it will work.

The problem is that without a correct definition, somebody could write:

   p = malloc(malloc,malloc,malloc);

and it would compile and link. But is unlikely to work.

Yet it's astonishing that not all compilers make this an error by default.

(gcc 5.1.0 will warn, but also show an error because it recognises this 
as a standard function that only takes argument. But for other implicit 
functions, or 'malloc(malloc)', it will pass it. That is, the compiler 
returns a '0' success code.

Expecting the usual flak because apparently you are not supposed to run 
compilers without the exact options needed for sensible behaviour. I say 
poppycock.)

-- 
bartc

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

#127019

If the OP wants a c# code then this works.  I just tried it on my machine:

> using(StreamReaderinFile =newStreamReader(@"File01.txt"))
> {
> stringline =inFile.ReadLine();
> inta, b, c, d, e, f;
> while(line!=null)
> {
> string[] Numbers2 =line.Split(' ');
> a=Int32.Parse(Numbers2[0]);
> b=Int32.Parse(Numbers2[1]);
> c=Int32.Parse(Numbers2[2]);
> d=Int32.Parse(Numbers2[3]);
> e=Int32.Parse(Numbers2[4]);
> f=Int32.Parse(Numbers2[5]);
> Console.WriteLine("\t{0:D2} {1:D2} {2:D2} {3:D2} {4:D2} {5:D2}", a, b, 
> c, d, e, f);
> line=inFile.ReadLine();
> }
> }

Put the numbers in a file and save it as: file01.txt

On 24/02/2018 21:13, Anton Shepelev wrote:
> G B:
>
>> If  you  have  a text file of numbers, what is the
>> best way to read numbers line by line and do  some
>> tests  on  numbers  for that line before moving to
>> the next line?  for example the  text  file  might
>> be:
>>
>> 07    23    36    52    53    57
>> 02    04    09    15    25    51
>> 02    03    11    14    18    21
>> 22    22    23    28    33    54
>> 16    19    26    48    58    58
>> 04    28    42    48    56    57
>> 05    13    18    21    45    46
>> 05    22    23    29    31    58
>> 01    03    07    14    16    55
>> 06    09    40    43    46    48
>>
>> I  want  to  read numbers: a, b, c, d, e, f and do
>> some tests on it and then go to the next line  and
>> do the same.
>>
>> In some languages, it was possible to do something
>> like this:
>>
>> While Not EOF (Infile) Do
>> Begin
>>       ReadLn (InFile, a, b, c, d, e, f);
>>       // Write test code here
>> End;
>>
>> I want something similar in C or C++.
> It is too quite here.
>
> #include <stdio.h>
>
> typedef struct reader_t
> {  int            n;
>     int            sp;
>     FILE*          file;
>     char*          sbuf;
>     unsigned char* nbuf;
>     int            size;
> } reader_t;
>
> const int DIGIT_N = 2;
>
> void initreader( reader_t * readerP, int n, int sp, char* path )
> {  readerP->n    = n;
>     readerP->sp   = sp;
>     readerP->file = fopen( path, "r" );
>     readerP->size = n * DIGIT_N + (n - 1) * sp + 2;
>     readerP->sbuf = (          char* )malloc( readerP->size );
>     readerP->nbuf = ( unsigned char* )malloc( readerP->n );
> }
>
> int readrow( reader_t * readerP )
> {  int res, i;
>     char* pos;
>     if( fgets( readerP->sbuf, readerP->size, readerP->file ) == NULL )
>     {  res = 0;  }
>     else
>     {  pos = readerP->sbuf;
>        for( i = 0; i < readerP->n; i++ )
>        {  readerP->nbuf[i] = atoi( pos );
>           pos = pos + readerP->sp + DIGIT_N;
>        }
>        res = 1;
>     }
>     return res;
> }
>
> void deinitreader( reader_t * readerP )
> {  free  ( readerP->sbuf );
>     free  ( readerP->nbuf );
>     fclose( readerP->file );
> }
>
> int main( int argc, char** argv )
> {  const int NUMCOUNT = 6;
>     int i;
>     reader_t r;
>
>     initreader( &r, NUMCOUNT, 4, "test.txt" );
>     while( readrow( &r ) )
>     {  for( i = 0; i < NUMCOUNT; i++ )
>        {  printf("%3i ", r.nbuf[i] );  }
>        printf("\n");
>     }
>     deinitreader( &r );
>
>     return 0;
> }
>

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

#127020

Anton Shepelev <anton.txt@gmail.com> writes:

> G B:
>
>> If  you  have  a text file of numbers, what is the
>> best way to read numbers line by line and do  some
>> tests  on  numbers  for that line before moving to
>> the next line?  for example the  text  file  might
>> be:
>>
>> 07    23    36    52    53    57
>> 02    04    09    15    25    51
>> 02    03    11    14    18    21
>> 22    22    23    28    33    54
>> 16    19    26    48    58    58
>> 04    28    42    48    56    57
>> 05    13    18    21    45    46
>> 05    22    23    29    31    58
>> 01    03    07    14    16    55
>> 06    09    40    43    46    48
>>
>> I  want  to  read numbers: a, b, c, d, e, f and do
>> some tests on it and then go to the next line  and
>> do the same.
>>
>> In some languages, it was possible to do something
>> like this:
>>
>> While Not EOF (Infile) Do
>> Begin
>>      ReadLn (InFile, a, b, c, d, e, f);
>>      // Write test code here
>> End;
>>
>> I want something similar in C or C++.
>
> It is too quite here.
>
> #include <stdio.h>
>
> typedef struct reader_t
> {  int            n;
>    int            sp;
>    FILE*          file;
>    char*          sbuf;
>    unsigned char* nbuf;
>    int            size;
> } reader_t;
>
> const int DIGIT_N = 2;
>
> void initreader( reader_t * readerP, int n, int sp, char* path )
> {  readerP->n    = n;
>    readerP->sp   = sp;
>    readerP->file = fopen( path, "r" );
>    readerP->size = n * DIGIT_N + (n - 1) * sp + 2;
>    readerP->sbuf = (          char* )malloc( readerP->size );
>    readerP->nbuf = ( unsigned char* )malloc( readerP->n );
> }
>
> int readrow( reader_t * readerP )
> {  int res, i;
>    char* pos;
>    if( fgets( readerP->sbuf, readerP->size, readerP->file ) == NULL )
>    {  res = 0;  }
>    else
>    {  pos = readerP->sbuf;
>       for( i = 0; i < readerP->n; i++ )
>       {  readerP->nbuf[i] = atoi( pos );
>          pos = pos + readerP->sp + DIGIT_N;
>       }
>       res = 1;
>    }
>    return res;
> }
>
> void deinitreader( reader_t * readerP )
> {  free  ( readerP->sbuf );
>    free  ( readerP->nbuf );
>    fclose( readerP->file );
> }
>
> int main( int argc, char** argv )
> {  const int NUMCOUNT = 6;
>    int i;
>    reader_t r;
>
>    initreader( &r, NUMCOUNT, 4, "test.txt" );
>    while( readrow( &r ) )
>    {  for( i = 0; i < NUMCOUNT; i++ )
>       {  printf("%3i ", r.nbuf[i] );  }
>       printf("\n");
>    }
>    deinitreader( &r );
>
>    return 0;
> }

I've left the whole thing because I don't know what you cut.  Are you
assuming that the OP is posting coursework and you are deliberately not
helping?

-- 
Ben.

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

#127022

On 24/02/2018 21:36, Ben Bacarisse wrote:
>
> I've left the whole thing because I don't know what you cut.  Are you
> assuming that the OP is posting coursework and you are deliberately not
> helping?
>

If you can't be bothered to help students or not please stay away and 
don't discourage people who would like to try something new.

Anyway, for completeness, this is the full program in C#

using System;
using System.IO;

class randoms
{
     static void Main()
     {
         int[] Numbers = new int[6];
         Random rnd = new Random();

         using (StreamWriter OutFile = new StreamWriter(@"File01.txt"))
         {
             for (int i = 1; i < 30; i++)
             {
                 for (int index = 0; index < Numbers.Length; index++)
                 {
                     Numbers[index] = (rnd.Next(1, 100));
                 }

                 // Array.Sort (Numbers);
                 Array.Sort(Numbers);

                 foreach (var val in Numbers)
                 {
                     OutFile.Write("{0:D2}" + " ", val);
                 }
                 OutFile.WriteLine();
             }
         }

         using (StreamReader inFile = new StreamReader(@"File01.txt"))
         {
             string line = inFile.ReadLine();
             int a, b, c, d, e, f;

             while (line != null)
             {
                 string[] Numbers2 = line.Split(' ');


                 a = Int32.Parse(Numbers2[0]);
                 b = Int32.Parse(Numbers2[1]);
                 c = Int32.Parse(Numbers2[2]);
                 d = Int32.Parse(Numbers2[3]);
                 e = Int32.Parse(Numbers2[4]);
                 f = Int32.Parse(Numbers2[5]);

                 Console.WriteLine("\t {0:D2}  {1:D2}  {2:D2} {3:D2}  
{4:D2}  {5:D2}", a, b, c, d, e, f);

                 line = inFile.ReadLine();
             }
         }

         Console.Write("\n\n\tPress any key to exit ... ");
         Console.ReadKey();
     }
}

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

#127024

On Sat, 2018-02-24, Ben Bacarisse wrote:
> Anton Shepelev <anton.txt@gmail.com> writes:
>
>> G B:
>>
>>> If  you  have  a text file of numbers, what is the
>>> best way to read numbers line by line and do  some
>>> tests  on  numbers  for that line before moving to
>>> the next line?  for example the  text  file  might
>>> be:
>>>
>>> 07    23    36    52    53    57
>>> 02    04    09    15    25    51
>>> 02    03    11    14    18    21
>>> 22    22    23    28    33    54
>>> 16    19    26    48    58    58
>>> 04    28    42    48    56    57
>>> 05    13    18    21    45    46
>>> 05    22    23    29    31    58
>>> 01    03    07    14    16    55
>>> 06    09    40    43    46    48
>>>
>>> I  want  to  read numbers: a, b, c, d, e, f and do
>>> some tests on it and then go to the next line  and
>>> do the same.
>>>
>>> In some languages, it was possible to do something
>>> like this:
>>>
>>> While Not EOF (Infile) Do
>>> Begin
>>>      ReadLn (InFile, a, b, c, d, e, f);
>>>      // Write test code here
>>> End;
>>>
>>> I want something similar in C or C++.
>>
>> It is too quite here.
>>
>> #include <stdio.h>
>>
>> typedef struct reader_t
>> {  int            n;
>>    int            sp;
>>    FILE*          file;
>>    char*          sbuf;
>>    unsigned char* nbuf;
>>    int            size;
>> } reader_t;
>>
>> const int DIGIT_N = 2;
>>
>> void initreader( reader_t * readerP, int n, int sp, char* path )
>> {  readerP->n    = n;
>>    readerP->sp   = sp;
>>    readerP->file = fopen( path, "r" );
>>    readerP->size = n * DIGIT_N + (n - 1) * sp + 2;
>>    readerP->sbuf = (          char* )malloc( readerP->size );
>>    readerP->nbuf = ( unsigned char* )malloc( readerP->n );
>> }
>>
>> int readrow( reader_t * readerP )
>> {  int res, i;
>>    char* pos;
>>    if( fgets( readerP->sbuf, readerP->size, readerP->file ) == NULL )
>>    {  res = 0;  }
>>    else
>>    {  pos = readerP->sbuf;
>>       for( i = 0; i < readerP->n; i++ )
>>       {  readerP->nbuf[i] = atoi( pos );
>>          pos = pos + readerP->sp + DIGIT_N;
>>       }
>>       res = 1;
>>    }
>>    return res;
>> }
>>
>> void deinitreader( reader_t * readerP )
>> {  free  ( readerP->sbuf );
>>    free  ( readerP->nbuf );
>>    fclose( readerP->file );
>> }
>>
>> int main( int argc, char** argv )
>> {  const int NUMCOUNT = 6;
>>    int i;
>>    reader_t r;
>>
>>    initreader( &r, NUMCOUNT, 4, "test.txt" );
>>    while( readrow( &r ) )
>>    {  for( i = 0; i < NUMCOUNT; i++ )
>>       {  printf("%3i ", r.nbuf[i] );  }
>>       printf("\n");
>>    }
>>    deinitreader( &r );
>>
>>    return 0;
>> }
>
> I've left the whole thing because I don't know what you cut.  Are you
> assuming that the OP is posting coursework and you are deliberately not
> helping?

Are you responding to the posting you think?  He didn't cut anything,
as far as I can tell: he just responded to the original query, with an
implementation which looks plausible.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

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

csiph-web