Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126692 > unrolled thread
| Started by | G B <gb@gb.com> |
|---|---|
| First post | 2018-02-14 11:47 -0400 |
| Last post | 2018-02-25 20:12 +0000 |
| Articles | 20 on this page of 168 — 30 participants |
Back to article view | Back to comp.lang.c
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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-02-21 10:34 -0800 |
| Message-ID | <kfn371uw5ss.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #126869 |
already5chosen@yahoo.com writes:
> On Monday, February 19, 2018 at 10:06:10 PM UTC+2, Tim Rentsch wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> <snip>
>>>
>>>> signed
>>>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
>>>> signed k, d, n;
>>>>
>>>> for( k=0; sscanf( p, "%d %n%*1[,;] %n", &d, &n, &n ) > 0; p+=n, k++ ){
>>>> if( k < K ) data[k] = d;
>>>> }
>>>>
>>>> return *p ? -1 : k;
>>>> }
>>>
>>> As someone who has taken the scanf red pill I think that's nice, but it
>>> does present a bigger target for the naysayers.
>>>
>>> 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.
>>
>> Detecting the out-of-range condition is easy. The question is
>> how to handle it when it occurs. The *scanf() functions aren't
>> like strtol() where only a single value is returned. At a guess,
>> previous implementations made different choices, and rather than
>> trying to reconcile them the original standard just punted and
>> declared it undefined behavior. And the rest, as they say, is
>> history.
>>
>> For this particular problem though we can work around the problem
>> of out-of-range values, since the numbers being input are all
>> small:
>>
>> signed
>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
>> signed k, d;
>> long long signed m, n;
>>
>> for(
>> k = 0;
>> sscanf( p, "%4d%lln %lln%*1[,;] %lln", &d, &m, &n, &n ) > 0 && m < n;
>> k < K ? data[k] = d : 0, p += n, k++
>> ){}
>>
>> return *p ? -1 : k;
>> }
>>
>> This function accepts non-negative values up to four digits,
>> which will never have a problem with the value not being able to
>> be represented in an int. (In principle the %lln conversions can
>> overflow but they never will in our lifetimes.) Values that
>> need more digits can use %ld or %lld, obviously.
>>
>>> That leads to it being less used, and then that leads to anything but the
>>> simple numeric conversions being considered a black art.
>>
>> Yeah. Hopefully the example function above has put some more
>> weight on the good side of the scale.
>
> Personally, with regard to sscanf() I am one of those naysayers
> mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it
> is bad enough. Less The World uses it - the better.
Do you have some reasoning to offer along with that belief?
Or do you think of it as just axiomatic?
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-21 15:35 -0800 |
| Message-ID | <49ec6a1a-d1b2-4352-9e29-61962174a6c4@googlegroups.com> |
| In reply to | #126942 |
On Wednesday, February 21, 2018 at 8:34:39 PM UTC+2, Tim Rentsch wrote:
> already5chosen@yahoo.com writes:
>
> > On Monday, February 19, 2018 at 10:06:10 PM UTC+2, Tim Rentsch wrote:
> >
> >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >>
> >>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>> <snip>
> >>>
> >>>> signed
> >>>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
> >>>> signed k, d, n;
> >>>>
> >>>> for( k=0; sscanf( p, "%d %n%*1[,;] %n", &d, &n, &n ) > 0; p+=n, k++ ){
> >>>> if( k < K ) data[k] = d;
> >>>> }
> >>>>
> >>>> return *p ? -1 : k;
> >>>> }
> >>>
> >>> As someone who has taken the scanf red pill I think that's nice, but it
> >>> does present a bigger target for the naysayers.
> >>>
> >>> 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.
> >>
> >> Detecting the out-of-range condition is easy. The question is
> >> how to handle it when it occurs. The *scanf() functions aren't
> >> like strtol() where only a single value is returned. At a guess,
> >> previous implementations made different choices, and rather than
> >> trying to reconcile them the original standard just punted and
> >> declared it undefined behavior. And the rest, as they say, is
> >> history.
> >>
> >> For this particular problem though we can work around the problem
> >> of out-of-range values, since the numbers being input are all
> >> small:
> >>
> >> signed
> >> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
> >> signed k, d;
> >> long long signed m, n;
> >>
> >> for(
> >> k = 0;
> >> sscanf( p, "%4d%lln %lln%*1[,;] %lln", &d, &m, &n, &n ) > 0 && m < n;
> >> k < K ? data[k] = d : 0, p += n, k++
> >> ){}
> >>
> >> return *p ? -1 : k;
> >> }
> >>
> >> This function accepts non-negative values up to four digits,
> >> which will never have a problem with the value not being able to
> >> be represented in an int. (In principle the %lln conversions can
> >> overflow but they never will in our lifetimes.) Values that
> >> need more digits can use %ld or %lld, obviously.
> >>
> >>> That leads to it being less used, and then that leads to anything but the
> >>> simple numeric conversions being considered a black art.
> >>
> >> Yeah. Hopefully the example function above has put some more
> >> weight on the good side of the scale.
> >
> > Personally, with regard to sscanf() I am one of those naysayers
> > mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it
> > is bad enough. Less The World uses it - the better.
>
> Do you have some reasoning to offer along with that belief?
> Or do you think of it as just axiomatic?
Mostly axiomatic, but I can mention something if you wish.
#1 - scanf family is not type-safe in non-obvious manner. The biggest danger happens not during initial coding, but during later maintenance/modifications.
But there are other defects as well.
Parsing rules are tricky, hard to recollect.
Overall very 70s.
strtoxxx() family has far cleaner interface even if, in rare cases, it could be slightly less convenient.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-22 00:11 +0000 |
| Message-ID | <XUnjC.119763$3X6.69850@fx22.am4> |
| In reply to | #126962 |
On 21/02/2018 23:35, already5chosen@yahoo.com wrote:
> On Wednesday, February 21, 2018 at 8:34:39 PM UTC+2, Tim Rentsch wrote:
>>>>>> for( k=0; sscanf( p, "%d %n%*1[,;] %n", &d, &n, &n ) > 0; p+=n, k++ ){
>>>> sscanf( p, "%4d%lln %lln%*1[,;] %lln", &d, &m, &n, &n ) > 0 && m < n;
>> Do you have some reasoning to offer along with that belief?
>> Or do you think of it as just axiomatic?
>
> Mostly axiomatic, but I can mention something if you wish.
> #1 - scanf family is not type-safe in non-obvious manner. The biggest danger happens not during initial coding, but during later maintenance/modifications.
> But there are other defects as well.
> Parsing rules are tricky, hard to recollect.
> Overall very 70s.
> strtoxxx() family has far cleaner interface even if, in rare cases, it could be slightly less convenient.
Scanf, especially as used above, just presents another cryptic language
to have to learn. One that might be added to the preprocessor macro
language, type declaration syntax which is nearly a language by itself,
make-file syntax, and that of the compiler's set of options. All extra
mini-languages you to use for C, before you even consider any other
actual languages that may be involved.
But strtoxxx are just a function-based API, not a language, and since
you can only really string one function call after another, it's hard to
make it that complicated.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-02-21 18:26 -0600 |
| Message-ID | <ef3s8dtcrls5i26crkdklj3856b7ngpdsq@4ax.com> |
| In reply to | #126942 |
On Wed, 21 Feb 2018 10:34:11 -0800, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>already5chosen@yahoo.com writes:
>
>> On Monday, February 19, 2018 at 10:06:10 PM UTC+2, Tim Rentsch wrote:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> <snip>
>>>>
>>>>> signed
>>>>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
>>>>> signed k, d, n;
>>>>>
>>>>> for( k=0; sscanf( p, "%d %n%*1[,;] %n", &d, &n, &n ) > 0; p+=n, k++ ){
>>>>> if( k < K ) data[k] = d;
>>>>> }
>>>>>
>>>>> return *p ? -1 : k;
>>>>> }
>>>>
>>>> As someone who has taken the scanf red pill I think that's nice, but it
>>>> does present a bigger target for the naysayers.
>>>>
>>>> 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.
>>>
>>> Detecting the out-of-range condition is easy. The question is
>>> how to handle it when it occurs. The *scanf() functions aren't
>>> like strtol() where only a single value is returned. At a guess,
>>> previous implementations made different choices, and rather than
>>> trying to reconcile them the original standard just punted and
>>> declared it undefined behavior. And the rest, as they say, is
>>> history.
>>>
>>> For this particular problem though we can work around the problem
>>> of out-of-range values, since the numbers being input are all
>>> small:
>>>
>>> signed
>>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
>>> signed k, d;
>>> long long signed m, n;
>>>
>>> for(
>>> k = 0;
>>> sscanf( p, "%4d%lln %lln%*1[,;] %lln", &d, &m, &n, &n ) > 0 && m < n;
>>> k < K ? data[k] = d : 0, p += n, k++
>>> ){}
>>>
>>> return *p ? -1 : k;
>>> }
>>>
>>> This function accepts non-negative values up to four digits,
>>> which will never have a problem with the value not being able to
>>> be represented in an int. (In principle the %lln conversions can
>>> overflow but they never will in our lifetimes.) Values that
>>> need more digits can use %ld or %lld, obviously.
>>>
>>>> That leads to it being less used, and then that leads to anything but the
>>>> simple numeric conversions being considered a black art.
>>>
>>> Yeah. Hopefully the example function above has put some more
>>> weight on the good side of the scale.
>>
>> Personally, with regard to sscanf() I am one of those naysayers
>> mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it
>> is bad enough. Less The World uses it - the better.
>
>Do you have some reasoning to offer along with that belief?
>Or do you think of it as just axiomatic?
If one starts with the assumption that input needs to be validated,
then *scanf is useless. IMO.
An exception may exist for toy programs.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-02-21 21:39 -0800 |
| Message-ID | <kfnlgflvazg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #126967 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Wed, 21 Feb 2018 10:34:11 -0800, Tim Rentsch wrote: >> already5chosen@yahoo.com writes: >>[...] >>> >>> Personally, with regard to sscanf() I am one of those naysayers >>> mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it >>> is bad enough. Less The World uses it - the better. >> >> Do you have some reasoning to offer along with that belief? >> Or do you think of it as just axiomatic? > > If one starts with the assumption that input needs to be validated, > then *scanf is useless. IMO. Can you say more about what sort of validations you're talking about? ISTM that some simple validation can be done with the scanf interface as it stands (to simplify the discussion let me restrict it to sscanf(), since the *scanf() functions that also do input have other issues). So I'm wondering what sorts of checks or whatever you had in mind. Also let me add that I respect your opinion. I don't mean to challenge your view here, just understand it better.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-02-23 03:08 -0600 |
| Message-ID | <6flv8d9ii03eh280a1l8sia5a1eul0bsjs@4ax.com> |
| In reply to | #126974 |
On Wed, 21 Feb 2018 21:39:47 -0800, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Wed, 21 Feb 2018 10:34:11 -0800, Tim Rentsch wrote: >>> already5chosen@yahoo.com writes: >>>[...] >>>> >>>> Personally, with regard to sscanf() I am one of those naysayers >>>> mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it >>>> is bad enough. Less The World uses it - the better. >>> >>> Do you have some reasoning to offer along with that belief? >>> Or do you think of it as just axiomatic? >> >> If one starts with the assumption that input needs to be validated, >> then *scanf is useless. IMO. > >Can you say more about what sort of validations you're talking >about? ISTM that some simple validation can be done with the >scanf interface as it stands (to simplify the discussion let >me restrict it to sscanf(), since the *scanf() functions that >also do input have other issues). So I'm wondering what sorts >of checks or whatever you had in mind. One example is inputting an integral value. Behavior on overflow is undefined. So passing 9999999999 to sscanf %i (32 bit ints) might result in 1.4 billion, INT_MAX, or something else. Using %lli doesn't help, it just moves to boundary further out. You can specify a maximum width and use a larger type in some cases.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-23 16:16 -0800 |
| Message-ID | <e8333d92-3eb3-4463-9720-725948c427ae@googlegroups.com> |
| In reply to | #127000 |
On Friday, February 23, 2018 at 3:08:25 AM UTC-6, robert...@yahoo.com wrote: > One example is inputting an integral value. Behavior on overflow is > undefined. So passing 9999999999 to sscanf %i (32 bit ints) might > result in 1.4 billion, INT_MAX, or something else. Using %lli doesn't > help, it just moves to boundary further out. You can specify a > maximum width and use a larger type in some cases. The problem is that there are a number of useful things that scanf could do in case of overflow, and none of them is sufficiently better than the others to justify mandating that all scanf implementations must be changed to do work that way. While the behavior should arguably be Implementation- Defined rather than Undefined, the only difference between Undefined Behavior and Implementation-Defined behavior in 1989 was whether implementations were *required* to formally document the behavior. Unless the Standard were to identify all the ways in which a scanf implementation might behave in case of overflow, UB and IDB would have been the same from a portability standpoint.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-23 16:46 -0800 |
| Message-ID | <lny3jjjjua.fsf@kst-u.example.com> |
| In reply to | #127002 |
supercat@casperkitty.com writes:
> On Friday, February 23, 2018 at 3:08:25 AM UTC-6, robert...@yahoo.com wrote:
>> One example is inputting an integral value. Behavior on overflow is
>> undefined. So passing 9999999999 to sscanf %i (32 bit ints) might
>> result in 1.4 billion, INT_MAX, or something else. Using %lli doesn't
>> help, it just moves to boundary further out. You can specify a
>> maximum width and use a larger type in some cases.
>
> The problem is that there are a number of useful things that scanf could
> do in case of overflow, and none of them is sufficiently better than the
> others to justify mandating that all scanf implementations must be changed
> to do work that way. While the behavior should arguably be Implementation-
> Defined rather than Undefined, the only difference between Undefined
> Behavior and Implementation-Defined behavior in 1989 was whether
> implementations were *required* to formally document the behavior. Unless
> the Standard were to identify all the ways in which a scanf implementation
> might behave in case of overflow, UB and IDB would have been the same from
> a portability standpoint.
Of course the standard would specify all the ways it might behave.
Implementation-defined behavior is by definition
unspecified behavior where each implementation documents how the
choice is made
and unspecified behavior is
use of an unspecified value, or other behavior where this
International Standard **provides two or more possibilities**
and imposes no further requirements on which is chosen in
any instance
(emphasis added).
Reasonable behaviors could include setting the object to an
unspecified or implementation-defined value, or treating overflow as
a matching failure. If the standard were changed to require overflow
to behave in one of those ways, it might not break any existing
implementations, but it would make the *scanf functions much safer.
As it is, `sscanf("999999999999", "%d", &n)` could crash your
program. If overflow were implementation-defined rather than UB,
it couldn't.
--
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]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-24 02:49 -0800 |
| Message-ID | <bf07a3b4-bae1-4e66-bafb-1b370bf05411@googlegroups.com> |
| In reply to | #127004 |
On Saturday, February 24, 2018 at 12:46:19 AM UTC, Keith Thompson wrote:
>
> As it is, `sscanf("999999999999", "%d", &n)` could crash your
> program. If overflow were implementation-defined rather than UB,
> it couldn't.
>
Then you can't distinguish a valid value from an invalid one.
However there is a perfectly adequate behaviour, which is to refuse
to convert the field and return the fact in the return value.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2018-02-24 05:16 -0800 |
| Message-ID | <c77c5c79-e653-44d2-9c84-59dc9645dbbd@googlegroups.com> |
| In reply to | #127008 |
All Your discussion On sscanf can be end if rewrite sscanf as Sscanf in the way it handle overflow and all possible error
[toc] | [prev] | [next] | [standalone]
| From | "F. Russell" <fr@random.info> |
|---|---|
| Date | 2018-02-24 14:35 +0000 |
| Message-ID | <p6rt7601b5q@news4.newsguy.com> |
| In reply to | #127011 |
On Sat, 24 Feb 2018 05:16:37 -0800, asetofsymbols wrote: > All Your discussion On sscanf can be end if rewrite sscanf as Sscanf in > the way it handle overflow and all possible error > If one desires input validation then scanf or any other built-in C function is not the way to go. Input validation is the function of Flex/Bison.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2018-02-24 08:48 -0700 |
| Message-ID | <1bfu5qs81p.fsf@pfeifferfamily.net> |
| In reply to | #127012 |
"F. Russell" <fr@random.info> writes: > On Sat, 24 Feb 2018 05:16:37 -0800, asetofsymbols wrote: > >> All Your discussion On sscanf can be end if rewrite sscanf as Sscanf in >> the way it handle overflow and all possible error >> > > If one desires input validation then scanf or any other built-in > C function is not the way to go. > > Input validation is the function of Flex/Bison. Depends wholly on the complexity of the grammar. If you're simply reading in a bunch of numbers (which is how this whole discussion started) then flex is massive overkill, and bison more so.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-25 15:09 -0800 |
| Message-ID | <9990dccb-4af6-4d66-8a03-8842bd0f92a4@googlegroups.com> |
| In reply to | #127004 |
On Friday, February 23, 2018 at 6:46:19 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > The problem is that there are a number of useful things that scanf could
> > do in case of overflow, and none of them is sufficiently better than the
> > others to justify mandating that all scanf implementations must be changed
> > to do work that way. While the behavior should arguably be Implementation-
> > Defined rather than Undefined, the only difference between Undefined
> > Behavior and Implementation-Defined behavior in 1989 was whether
> > implementations were *required* to formally document the behavior. Unless
> > the Standard were to identify all the ways in which a scanf implementation
> > might behave in case of overflow, UB and IDB would have been the same from
> > a portability standpoint.
>
> Of course the standard would specify all the ways it might behave.
>
> Implementation-defined behavior is by definition
> unspecified behavior where each implementation documents how the
> choice is made
> and unspecified behavior is
> use of an unspecified value, or other behavior where this
> International Standard **provides two or more possibilities**
> and imposes no further requirements on which is chosen in
> any instance
> (emphasis added).
Many C implementations make use of external libraries or platform
features. Documenting all of the factors that might affect the
behavior of an overflow that occurs within a scanf might have been
impractical for some implementations.
> Reasonable behaviors could include setting the object to an
> unspecified or implementation-defined value, or treating overflow as
> a matching failure. If the standard were changed to require overflow
> to behave in one of those ways, it might not break any existing
> implementations, but it would make the *scanf functions much safer.
There very likely existed some code that required each behavior,
and quite possibly code that relied upon *scanf setting errno or
some other kind of implementation-defined flag.
> As it is, `sscanf("999999999999", "%d", &n)` could crash your
> program. If overflow were implementation-defined rather than UB,
> it couldn't.
Quality implementations that can sensibly define the behavior
should do so. An implementation that evalues some *scanf calls
by calling an external library function of that name, but
evaluates others by substituting other functions [similar to the
way gcc may replace printf("Hello\n"); with puts("Hello");] would
have a hard time describing how overflow would be handled if
those external functions might handle it differently.
Note that from the point of view of the Standard, there is almost
never any guarantee that a scanf call won't result in a stack
overflow that could cause arbitrary behavior. Obviously that
won't usually happen in a quality implementation except during very
deeply-nested function calls, but nor should quality implementations
do anything else particularly dangerous with a scanf call.
The notion that UB should encourage quality implementations to
behave in wackier fashion than IDB did not emerge until long after
the Committee had decided which actions to classify as UB versus
IDB.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-25 15:54 -0800 |
| Message-ID | <lnzi3wiq0f.fsf@kst-u.example.com> |
| In reply to | #127050 |
supercat@casperkitty.com writes:
> On Friday, February 23, 2018 at 6:46:19 PM UTC-6, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > The problem is that there are a number of useful things that scanf could
>> > do in case of overflow, and none of them is sufficiently better than the
>> > others to justify mandating that all scanf implementations must be changed
>> > to do work that way. While the behavior should arguably be Implementation-
>> > Defined rather than Undefined, the only difference between Undefined
>> > Behavior and Implementation-Defined behavior in 1989 was whether
>> > implementations were *required* to formally document the behavior. Unless
>> > the Standard were to identify all the ways in which a scanf implementation
>> > might behave in case of overflow, UB and IDB would have been the same from
>> > a portability standpoint.
>>
>> Of course the standard would specify all the ways it might behave.
>>
>> Implementation-defined behavior is by definition
>> unspecified behavior where each implementation documents how the
>> choice is made
>> and unspecified behavior is
>> use of an unspecified value, or other behavior where this
>> International Standard **provides two or more possibilities**
>> and imposes no further requirements on which is chosen in
>> any instance
>> (emphasis added).
>
> Many C implementations make use of external libraries or platform
> features. Documenting all of the factors that might affect the
> behavior of an overflow that occurs within a scanf might have been
> impractical for some implementations.
That's not an issue. The external library is part of the
C implementation, so its documentation is part of the C
implementation's documentation.
>> Reasonable behaviors could include setting the object to an
>> unspecified or implementation-defined value, or treating overflow as
>> a matching failure. If the standard were changed to require overflow
>> to behave in one of those ways, it might not break any existing
>> implementations, but it would make the *scanf functions much safer.
>
> There very likely existed some code that required each behavior,
> and quite possibly code that relied upon *scanf setting errno or
> some other kind of implementation-defined flag.
The standard could state that the behavior of scanf("%d", ...) is
implementation-defined and enumerate a finite list of permitted
behaviors, consistent with what current implementations actually do.
It wouldn't even have to mention setting errno, since library
functions are permitted to do anyway.
Or it could enumerate a smaller list of permitted behaviors,
requiring some implementations to change their behavior in order to
conform to C202X. It could even specify the exact required behavior,
which might require *all* implementations to be updated, perhaps by
borrowing code from their own strto*() implementations.
As it is, since the behavior is undefined, an implementation is
permitted to terminate the program on overflow. (I don't believe any
implementations actually do so, but since it's permitted I have to
consider the possibility if I want to write portable code.)
>> As it is, `sscanf("999999999999", "%d", &n)` could crash your
>> program. If overflow were implementation-defined rather than UB,
>> it couldn't.
>
> Quality implementations that can sensibly define the behavior
> should do so. An implementation that evalues some *scanf calls
> by calling an external library function of that name, but
> evaluates others by substituting other functions [similar to the
> way gcc may replace printf("Hello\n"); with puts("Hello");] would
> have a hard time describing how overflow would be handled if
> those external functions might handle it differently.
If the behavior is implementation-defined, then implementations would be
required to document that behavior, regardless of how difficult it might
be. In practice, it wouldn't be particularly difficult.
> Note that from the point of view of the Standard, there is almost
> never any guarantee that a scanf call won't result in a stack
> overflow that could cause arbitrary behavior. Obviously that
> won't usually happen in a quality implementation except during very
> deeply-nested function calls, but nor should quality implementations
> do anything else particularly dangerous with a scanf call.
>
> The notion that UB should encourage quality implementations to
> behave in wackier fashion than IDB did not emerge until long after
> the Committee had decided which actions to classify as UB versus
> IDB.
Nonsense. Nobody is talking about "encouraging" wacky behavior.
The point is that UB *permits* arbitrary behavior, and IDB does not.
That affects what I can safely do in code that's intended to be
portable.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-26 11:04 -0800 |
| Message-ID | <e8a05547-b79f-497d-a6a9-5edb335fe075@googlegroups.com> |
| In reply to | #127058 |
On Sunday, February 25, 2018 at 5:55:12 PM UTC-6, Keith Thompson wrote: > supercat@casperkitty.com writes: > > Many C implementations make use of external libraries or platform > > features. Documenting all of the factors that might affect the > > behavior of an overflow that occurs within a scanf might have been > > impractical for some implementations. > > That's not an issue. The external library is part of the > C implementation, so its documentation is part of the C > implementation's documentation. Many C implementations, including gcc, consist of a compiler and runtime library supplied by separate entities. The author of a runtime library would generally have no way of knowing all the ways that a compiler might replace a scanf call with something else, and the author of an implementation would generally have no way of knowing how a library written by someone else, or future versions thereof, would handle all corner cases. If the Standard were to recognize a category of implementation that relies upon an externally-supplied library, and specified that "call the outside library with the indicated arguments with whatever consequences result" would be considered an adequate behavioral description for such an implementation, then many things which are presently UB (e.g. closing a text file which ends with something other than a newline) could be sensibly treated as IDB. Presently, however, I think IDB is intended to require implementations to be a bit more specific about actual behavior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-26 11:52 -0800 |
| Message-ID | <lnfu5nil5j.fsf@kst-u.example.com> |
| In reply to | #127091 |
supercat@casperkitty.com writes:
> On Sunday, February 25, 2018 at 5:55:12 PM UTC-6, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > Many C implementations make use of external libraries or platform
>> > features. Documenting all of the factors that might affect the
>> > behavior of an overflow that occurs within a scanf might have been
>> > impractical for some implementations.
>>
>> That's not an issue. The external library is part of the
>> C implementation, so its documentation is part of the C
>> implementation's documentation.
>
> Many C implementations, including gcc, consist of a compiler and runtime
> library supplied by separate entities. The author of a runtime library
> would generally have no way of knowing all the ways that a compiler might
> replace a scanf call with something else, and the author of an implementation
> would generally have no way of knowing how a library written by someone
> else, or future versions thereof, would handle all corner cases.
A compiler and a runtime library have to work together to make a
conforming implementation. Or they can fail to do so, and the result is
a non-conforming implementation.
Transforming printf("hello\n") to puts("hello") is perfectly safe as
long as the library is correct. Other transformations that depend on
non-standard library behavior would have to be done in coordination with
the library, and might have to be disabled if a different library is
used.
In practice, implementers don't seem to have much trouble with this
concept. You needn't be outraged on their behalf.
> If the Standard were to recognize a category of implementation that relies
*yawn*
[...]
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-26 14:12 -0800 |
| Message-ID | <f206f5de-f8ad-42f2-9568-807262457ce4@googlegroups.com> |
| In reply to | #127058 |
On Sunday, February 25, 2018 at 5:55:12 PM UTC-6, Keith Thompson wrote: > supercat@casperkitty.com writes: > > The notion that UB should encourage quality implementations to > > behave in wackier fashion than IDB did not emerge until long after > > the Committee had decided which actions to classify as UB versus > > IDB. > > Nonsense. Nobody is talking about "encouraging" wacky behavior. > The point is that UB *permits* arbitrary behavior, and IDB does not. > That affects what I can safely do in code that's intended to be > portable. Perhaps the term "wacky" was unnecessarily pejorative and I should have been more precise: behaviors whose side-effects are undocumented, unbounded, unpredictable, and unrelated to the action being performed or the underlying platform's natural responses to such actions. An expression like "int1 > int2*int3;", where int1, int2, and int3 are all "int" objects without a volatile qualifier, would have two natural effects for any value of those objects: yield the value 0 to an enclosing expression, or yield the value 1 likewise. Some implementations might document that the expression may have other side-effects, and some platforms might document that they perform integer multiplication in ways that can have other side- effects. When neither condition applies, however, I don't think compiler writers would be eager to process such an expression in ways that could have undocumented, unbounded, and unpredictable side-effects if they didn't perceive the Standard as encouraging such treatment.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-26 14:40 -0800 |
| Message-ID | <ln8tbfidcx.fsf@kst-u.example.com> |
| In reply to | #127103 |
supercat@casperkitty.com writes:
> On Sunday, February 25, 2018 at 5:55:12 PM UTC-6, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > The notion that UB should encourage quality implementations to
>> > behave in wackier fashion than IDB did not emerge until long after
>> > the Committee had decided which actions to classify as UB versus
>> > IDB.
>>
>> Nonsense. Nobody is talking about "encouraging" wacky behavior.
>> The point is that UB *permits* arbitrary behavior, and IDB does not.
>> That affects what I can safely do in code that's intended to be
>> portable.
>
> Perhaps the term "wacky" was unnecessarily pejorative and I should have been
> more precise: behaviors whose side-effects are undocumented, unbounded,
> unpredictable, and unrelated to the action being performed or the underlying
> platform's natural responses to such actions.
My objection was to the word "encouraging". Undefined behavior
means that the standard "imposes no requirements". That doesn't
encourage (or discourage) anything.
> An expression like "int1 > int2*int3;", where int1, int2, and int3 are all
> "int" objects without a volatile qualifier, would have two natural effects
> for any value of those objects: yield the value 0 to an enclosing expression,
> or yield the value 1 likewise. Some implementations might document that
> the expression may have other side-effects, and some platforms might document
> that they perform integer multiplication in ways that can have other side-
> effects. When neither condition applies, however, I don't think compiler
> writers would be eager to process such an expression in ways that could
> have undocumented, unbounded, and unpredictable side-effects if they didn't
> perceive the Standard as encouraging such treatment.
As you know, the behavior of overflow on signed integer multiplication
is undefined. Compilers take advantage of that for optimization. I
hardly think they need any encouragement from the standard to want to
generate faster code.
Compilers are also perfectly free to define the behavior of overflow on
signed integer multiplication. Nothing in the standard discourages them
from doing so.
--
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]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-22 04:58 -0800 |
| Message-ID | <03b274e8-1ca0-4ac0-bc11-538c53d5f285@googlegroups.com> |
| In reply to | #126967 |
On Thursday, February 22, 2018 at 2:26:57 AM UTC+2, robert...@yahoo.com wrote:
> On Wed, 21 Feb 2018 10:34:11 -0800, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
> >already5chosen@yahoo.com writes:
> >
> >> On Monday, February 19, 2018 at 10:06:10 PM UTC+2, Tim Rentsch wrote:
> >>
> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >>>
> >>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>>> <snip>
> >>>>
> >>>>> signed
> >>>>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
> >>>>> signed k, d, n;
> >>>>>
> >>>>> for( k=0; sscanf( p, "%d %n%*1[,;] %n", &d, &n, &n ) > 0; p+=n, k++ ){
> >>>>> if( k < K ) data[k] = d;
> >>>>> }
> >>>>>
> >>>>> return *p ? -1 : k;
> >>>>> }
> >>>>
> >>>> As someone who has taken the scanf red pill I think that's nice, but it
> >>>> does present a bigger target for the naysayers.
> >>>>
> >>>> 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.
> >>>
> >>> Detecting the out-of-range condition is easy. The question is
> >>> how to handle it when it occurs. The *scanf() functions aren't
> >>> like strtol() where only a single value is returned. At a guess,
> >>> previous implementations made different choices, and rather than
> >>> trying to reconcile them the original standard just punted and
> >>> declared it undefined behavior. And the rest, as they say, is
> >>> history.
> >>>
> >>> For this particular problem though we can work around the problem
> >>> of out-of-range values, since the numbers being input are all
> >>> small:
> >>>
> >>> signed
> >>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
> >>> signed k, d;
> >>> long long signed m, n;
> >>>
> >>> for(
> >>> k = 0;
> >>> sscanf( p, "%4d%lln %lln%*1[,;] %lln", &d, &m, &n, &n ) > 0 && m < n;
> >>> k < K ? data[k] = d : 0, p += n, k++
> >>> ){}
> >>>
> >>> return *p ? -1 : k;
> >>> }
> >>>
> >>> This function accepts non-negative values up to four digits,
> >>> which will never have a problem with the value not being able to
> >>> be represented in an int. (In principle the %lln conversions can
> >>> overflow but they never will in our lifetimes.) Values that
> >>> need more digits can use %ld or %lld, obviously.
> >>>
> >>>> That leads to it being less used, and then that leads to anything but the
> >>>> simple numeric conversions being considered a black art.
> >>>
> >>> Yeah. Hopefully the example function above has put some more
> >>> weight on the good side of the scale.
> >>
> >> Personally, with regard to sscanf() I am one of those naysayers
> >> mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it
> >> is bad enough. Less The World uses it - the better.
> >
> >Do you have some reasoning to offer along with that belief?
> >Or do you think of it as just axiomatic?
>
>
> If one starts with the assumption that input needs to be validated,
> then *scanf is useless. IMO.
>
> An exception may exist for toy programs.
For non-toy usage, an absence of equivalent of endptr parameter of strtoxxx() is IMHO the most lethal of fatal flows of sscanf().
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-22 05:33 -0800 |
| Message-ID | <8357438f-639e-49b8-b1dd-1afd1a5ab9a9@googlegroups.com> |
| In reply to | #126986 |
On Thursday, February 22, 2018 at 12:58:43 PM UTC, already...@yahoo.com wrote:
> On Thursday, February 22, 2018 at 2:26:57 AM UTC+2, robert...@yahoo.com wrote:
> > On Wed, 21 Feb 2018 10:34:11 -0800, Tim Rentsch
> > <txr@alumni.caltech.edu> wrote:
> >
> > >already5chosen@yahoo.com writes:
> > >
> > >> On Monday, February 19, 2018 at 10:06:10 PM UTC+2, Tim Rentsch wrote:
> > >>
> > >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > >>>
> > >>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > >>>> <snip>
> > >>>>
> > >>>>> signed
> > >>>>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
> > >>>>> signed k, d, n;
> > >>>>>
> > >>>>> for( k=0; sscanf( p, "%d %n%*1[,;] %n", &d, &n, &n ) > 0; p+=n, k++ ){
> > >>>>> if( k < K ) data[k] = d;
> > >>>>> }
> > >>>>>
> > >>>>> return *p ? -1 : k;
> > >>>>> }
> > >>>>
> > >>>> As someone who has taken the scanf red pill I think that's nice, but it
> > >>>> does present a bigger target for the naysayers.
> > >>>>
> > >>>> 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.
> > >>>
> > >>> Detecting the out-of-range condition is easy. The question is
> > >>> how to handle it when it occurs. The *scanf() functions aren't
> > >>> like strtol() where only a single value is returned. At a guess,
> > >>> previous implementations made different choices, and rather than
> > >>> trying to reconcile them the original standard just punted and
> > >>> declared it undefined behavior. And the rest, as they say, is
> > >>> history.
> > >>>
> > >>> For this particular problem though we can work around the problem
> > >>> of out-of-range values, since the numbers being input are all
> > >>> small:
> > >>>
> > >>> signed
> > >>> parse_one_line( const char *p, signed const K, signed data[ const K ] ){
> > >>> signed k, d;
> > >>> long long signed m, n;
> > >>>
> > >>> for(
> > >>> k = 0;
> > >>> sscanf( p, "%4d%lln %lln%*1[,;] %lln", &d, &m, &n, &n ) > 0 && m < n;
> > >>> k < K ? data[k] = d : 0, p += n, k++
> > >>> ){}
> > >>>
> > >>> return *p ? -1 : k;
> > >>> }
> > >>>
> > >>> This function accepts non-negative values up to four digits,
> > >>> which will never have a problem with the value not being able to
> > >>> be represented in an int. (In principle the %lln conversions can
> > >>> overflow but they never will in our lifetimes.) Values that
> > >>> need more digits can use %ld or %lld, obviously.
> > >>>
> > >>>> That leads to it being less used, and then that leads to anything but the
> > >>>> simple numeric conversions being considered a black art.
> > >>>
> > >>> Yeah. Hopefully the example function above has put some more
> > >>> weight on the good side of the scale.
> > >>
> > >> Personally, with regard to sscanf() I am one of those naysayers
> > >> mentioned above. Yes, sscanf is less evil than scanf/fscanf, but it
> > >> is bad enough. Less The World uses it - the better.
> > >
> > >Do you have some reasoning to offer along with that belief?
> > >Or do you think of it as just axiomatic?
> >
> >
> > If one starts with the assumption that input needs to be validated,
> > then *scanf is useless. IMO.
> >
> > An exception may exist for toy programs.
>
> For non-toy usage, an absence of equivalent of endptr parameter of strtoxxx() is IMHO the most lethal of fatal flows of sscanf().
>
> 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.
>
sscanf() parses a whole line at a time. It also tell you if it doesn't
convert all the fields. So it's reasonable for programs which don't have to
handle malicious input, and don't have catastrophic consequences if
malformed but good faith input is entered.
That's not just "toy" programs, it's also a lot of programs which are run
in an environment where a programmer user prepares the input.
[toc] | [prev] | [next] | [standalone]
Page 6 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