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

memscan() function or equivalent

Started by	"Rick C. Hodgin" <rick.c.hodgin@gmail.com>
First post	2017-06-07 06:16 -0700
Last post	2017-06-07 08:53 -0700
Articles	20 on this page of 122 — 18 participants

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

  memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 06:16 -0700
    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 15:47 +0200
      Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 07:15 -0700
        Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 14:34 +0000
          Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 07:42 -0700
            Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 14:45 +0000
              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:07 -0700
                Re: memscan() function or equivalent jameskuyper@verizon.net - 2017-06-07 09:14 -0700
                  Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:33 -0700
        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 16:48 +0200
          Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:31 -0700
            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 17:37 +0200
              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:47 -0700
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:02 +0200
                  Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:09 -0700
                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:34 +0200
                      Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:54 -0700
                        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 19:01 +0200
                          Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 10:17 -0700
                            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 19:53 +0200
                        Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:15 -0700
                          Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:26 -0700
                            Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:56 -0700
                              Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 23:03 -0700
              Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 16:10 +0000
                Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:30 -0700
          Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-07 16:50 +0100
            Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:58 -0700
              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:03 -0700
                Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:07 -0700
                Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 17:30 +0100
                  Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:36 -0700
                    Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 17:48 +0100
                      Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:57 -0700
                      Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 05:54 +0000
                  Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-07 09:48 -0700
                    Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-07 20:55 +0100
                    Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 22:13 +0100
                      Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-07 16:02 -0700
                        Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-08 01:26 +0100
                          Re: memscan() function or equivalent Ian Collins <ian-news@hotmail.com> - 2017-06-08 13:00 +1200
                            Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-08 09:48 +0100
                        Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 08:52 +0200
              Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 10:00 -0700
                Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 10:13 -0700
                  Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 11:19 -0700
                    Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 11:27 -0700
              Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-07 21:18 +0100
            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:18 +0200
              Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-07 21:15 +0200
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:16 +0200
                  Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 09:08 +0200
                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 09:56 +0200
                      Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 17:14 +0200
                        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 17:38 +0200
                          Re: memscan() function or equivalent David Kleinecke <dkleinecke@gmail.com> - 2017-06-10 11:52 -0700
                            Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-10 20:03 +0100
                            Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-10 13:32 -0700
                            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 23:40 +0200
                              Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 00:53 +0300
                                Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 01:11 +0300
                                  Re: memscan() function or equivalent Ian Collins <ian-news@hotmail.com> - 2017-06-11 10:26 +1200
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:32 +0200
                                      Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:05 +0200
                                        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:06 +0200
                                        Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-11 13:19 -0700
                                    Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 02:17 +0300
                                Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-10 15:21 -0700
                                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:19 +0200
                                  Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 02:15 +0300
                                  Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:36 +0200
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:46 +0200
                                Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-10 22:25 -0700
                              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-10 15:13 -0700
                              Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-10 23:21 +0100
                                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:28 +0200
                                  Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 10:56 +0100
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 13:27 +0200
                                      Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 13:19 +0100
                                    Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-11 18:36 +0000
                                      Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 20:22 +0100
                                        Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 06:09 +0000
                                          Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-12 10:38 +0100
                                            Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-12 05:30 -0700
                                            Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 13:51 +0000
                                              Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-12 15:04 +0100
                                        Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 21:26 +0000
                              Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:04 +0200
                                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:13 +0200
                                  Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 13:38 +0200
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 14:18 +0200
                                  Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-11 09:57 -0700
                                    Re: memscan() function or equivalent Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 17:18 +0000
                          Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 09:53 +0200
                            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:00 +0200
                              Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 13:41 +0200
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:24 +0200
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:55 +0200
            Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-07 20:54 +0100
              Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-07 23:00 +0200
                Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 08:16 +0100
                  Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 10:55 +0200
                    Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 11:44 +0100
                      Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 13:11 +0200
                        Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 13:45 +0100
                          Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 14:51 +0200
                  Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-08 08:00 -0700
            Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-09 12:26 -0700
              Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-10 07:24 +0100
                Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-10 13:17 +0100
                  Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-10 17:18 +0100
                    Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-11 18:11 +0000
                Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-11 15:08 -0700
                  Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-12 18:34 +0100
                    Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-14 09:52 -0700
                      Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-14 19:56 +0100
                        Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-14 12:20 -0700
                        Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-17 06:37 -0700
                          Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-17 10:02 -0700
        Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-07 16:51 +0200
          Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 17:00 +0200
            Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 08:53 -0700

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

#111941

From	Anton Shepelev <anton.txt@gmail.com>
Date	2017-06-11 01:11 +0300
Message-ID	<20170611011149.c05607d3d67f977e693f6ccb@gmail.com>
In reply to	#111940

I wrote:

> Since  C  has  'break' and 'continue' and supports
> multiple returns from a function, there is  rarely
> a  need  for  'goto'  outisde  error  handling and
> deinitialization:
>
>   success = 0;
>   a = malloc(...);
>   if( a == NULL )
>   {  goto ErrorA;  }
>   b = malloc(...);
>   if( b == NULL )
>   {  goto ErrorB;  }
>   c = malloc(...);
>   if( c == NULL )
>   {  goto ErrorC;  }
>   ...
>   success = 1;
>   ErrorC: free(b);
>   ErrorB: free(a);
>   ErorrA:
>
>   return success;

I forgot to add 'free(c);' after 'success = 1;'

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

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

#111946

From	Ian Collins <ian-news@hotmail.com>
Date	2017-06-11 10:26 +1200
Message-ID	<eq3a1dFhbrbU1@mid.individual.net>
In reply to	#111941

On 06/11/17 10:11 AM, Anton Shepelev wrote:
> I wrote:
>
>> Since  C  has  'break' and 'continue' and supports
>> multiple returns from a function, there is  rarely
>> a  need  for  'goto'  outisde  error  handling and
>> deinitialization:
>>
>>    success = 0;
>>    a = malloc(...);
>>    if( a == NULL )
>>    {  goto ErrorA;  }
>>    b = malloc(...);
>>    if( b == NULL )
>>    {  goto ErrorB;  }
>>    c = malloc(...);
>>    if( c == NULL )
>>    {  goto ErrorC;  }
>>    ...
>>    success = 1;
>>    ErrorC: free(b);
>>    ErrorB: free(a);
>>    ErorrA:
>>
>>    return success;
>
> I forgot to add 'free(c);' after 'success = 1;'

Another good reason for automatic resource management :)

-- 
Ian

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

#111949

From	GOTHIER Nathan <nathan.gothier@gmail.com>
Date	2017-06-11 00:32 +0200
Message-ID	<20170611003228.cce9478ed15400333382561f@gmail.com>
In reply to	#111946

On Sun, 11 Jun 2017 10:26:53 +1200
Ian Collins <ian-news@hotmail.com> wrote:

> Another good reason for automatic resource management :)

You should try the programming AI instead of wasting your gray matter. :o)

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

#111959

From	"Patrick.Schluter" <Patrick.Schluter@free.fr>
Date	2017-06-11 10:05 +0200
Message-ID	<593cf9bf$0$15324$426a34cc@news.free.fr>
In reply to	#111949

Le 11.06.2017 à 00:32, GOTHIER Nathan a écrit :
> On Sun, 11 Jun 2017 10:26:53 +1200
> Ian Collins <ian-news@hotmail.com> wrote:
> 
>> Another good reason for automatic resource management :)
> 
> You should try the programming AI instead of wasting your gray matter. :o)
> 
Here again an insult.

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

#111960

From	GOTHIER Nathan <nathan.gothier@gmail.com>
Date	2017-06-11 10:06 +0200
Message-ID	<20170611100631.1848c3452f228c03764eed99@gmail.com>
In reply to	#111959

On Sun, 11 Jun 2017 10:05:20 +0200
"Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:

> Here again an insult.

You're pathetic trying to get support from others instead of taking your
responsability in firing people. Only weak kids try to get support from the
stronger ones...

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

#111979

From	Keith Thompson <kst-u@mib.org>
Date	2017-06-11 13:19 -0700
Message-ID	<ln1sqqi8fm.fsf@kst-u.example.com>
In reply to	#111959

"Patrick.Schluter" <Patrick.Schluter@free.fr> writes:
> Le 11.06.2017 à 00:32, GOTHIER Nathan a écrit :
>> On Sun, 11 Jun 2017 10:26:53 +1200
>> Ian Collins <ian-news@hotmail.com> wrote:
>> 
>>> Another good reason for automatic resource management :)
>> 
>> You should try the programming AI instead of wasting your gray matter. :o)
>> 
> Here again an insult.

I really hope you're not going to point out each insult in a separate
post.

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

#111951

From	Anton Shepelev <anton.txt@gmail.com>
Date	2017-06-11 02:17 +0300
Message-ID	<20170611021730.196a87301f3c161173faad05@gmail.com>
In reply to	#111946

Ian Collins to Anton Shepelev:

> > I forgot to add 'free(c);' after 'success = 1;'
>
> Another good reason for automatic resource manage-
> ment :)

But I will always find where to blunder.

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

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

#111944

From	supercat@casperkitty.com
Date	2017-06-10 15:21 -0700
Message-ID	<41338d4a-317a-4030-ac3b-0ba182949874@googlegroups.com>
In reply to	#111940

On Saturday, June 10, 2017 at 4:53:39 PM UTC-5, Anton Shepelev wrote:
> Since C has 'break' and 'continue' and supports mul-
> tiple returns from a function,  there  is  rarely  a
> need  for  'goto'  outisde error handling and deini-
> tialization:

It is almost always be *possible* to work around the lack of a "goto"
feature in languages that omit them.  In situations where application
requirements don't easily fit C's control structures, however, contorting
control structures to handle odd cases will often yield less readable
code than using normal control structures for normal cases, and "goto" for
the odd ones.

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

#111945

From	GOTHIER Nathan <nathan.gothier@gmail.com>
Date	2017-06-11 00:19 +0200
Message-ID	<20170611001942.ed785f03a57258054b391b18@gmail.com>
In reply to	#111940

On Sun, 11 Jun 2017 00:53:55 +0300
Anton Shepelev <anton.txt@gmail.com> wrote:

> Since C has 'break' and 'continue' and supports mul-
> tiple returns from a function,  there  is  rarely  a
> need  for  'goto'  outisde error handling and deini-
> tialization:

Can you tell why some self claimed C experts use labels and goto for corner
cases? Why no wonderful solution come to their mind instead of using ashamed
labels and goto? Why do you need to justify yourself from using labels and goto?

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

#111950

From	Anton Shepelev <anton.txt@gmail.com>
Date	2017-06-11 02:15 +0300
Message-ID	<20170611021551.27bf74b14818c5b094b38b4f@gmail.com>
In reply to	#111945

GOTHIER Nathan to Anton Shepelev:

> > Since  C has 'break' and 'continue' and supports
> > multiple  returns  from  a  function,  there  is
> > rarely  a need for 'goto' outisde error handling
> > and deinitialization:
> > [...]
>
> Can you tell why some self claimed C  experts  use
> labels and goto for corner cases?

I  don't  know  about self-claimed experts, but real
experts use whatever facility fits the task best.

> Why no wonderful solution come to their  mind  in-
> stead of using ashamed labels and goto?

Because  wonders  belong in fairy tales and shame to
people.

> Why do you need to justify yourself from using la-
> bels and goto?

I  neither "justify myself from using labels and go-
to" nor need to.  I did not even mention  my  person
in the post you quote.

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

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

#111963

From	"Patrick.Schluter" <Patrick.Schluter@free.fr>
Date	2017-06-11 10:36 +0200
Message-ID	<593d0126$0$15319$426a34cc@news.free.fr>
In reply to	#111945

Le 11.06.2017 à 00:19, GOTHIER Nathan a écrit :
> On Sun, 11 Jun 2017 00:53:55 +0300
> Anton Shepelev <anton.txt@gmail.com> wrote:
> 
>> Since C has 'break' and 'continue' and supports mul-
>> tiple returns from a function,  there  is  rarely  a
>> need  for  'goto'  outisde error handling and deini-
>> tialization:
> 
> 
> Can you tell why some self claimed C experts use labels and goto for corner
> cases? Why no wonderful solution come to their mind instead of using ashamed
> labels and goto? Why do you need to justify yourself from using labels and goto?
> 
Nobody is shaming the use of goto/label when appropriate, for example in 
Anton's example. Your example was not one where it is appropriate. The 
intent of the code was looping until a condition, so a standard loop 
construct is appropriate. An unstandard goto construct in that case is 
wrong.
In Anton's example the goto/label IS the appropriate construct as C 
lacks the high-level constructs that would allow to let the compiler 
insert the gotos itself (exceptions from C++ or scope(exit) from D).

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

#111964

From	GOTHIER Nathan <nathan.gothier@gmail.com>
Date	2017-06-11 10:46 +0200
Message-ID	<20170611104607.289e1354fd01c2bb1016586e@gmail.com>
In reply to	#111963

On Sun, 11 Jun 2017 10:36:54 +0200
"Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:
 
> Nobody ...

Yet the weak kid strategy.

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

#111954

From	asetofsymbols@gmail.com
Date	2017-06-10 22:25 -0700
Message-ID	<de3b35b4-474e-4eec-bf79-98bf0841d2cf@googlegroups.com>
In reply to	#111940

For me goto instruction is fundamental
It is something a language can never omit to have

The abc and foundation for the informatics 

And the one has projected languages without goto instruction are wrong

Yes it is easy use for(;;) for the loop in 90% of the loops
But there are the 10% too

The ones for example has need to stop the loop and continue out of the loop in the more deep loop

As in for(..)
        {
.        ....
.        for(...)
             {if(condition) goto out;
              ...
.             }
.        }
out:

But there are of different type when using some goto simplify the loop structure or better they are almost impossible in other way

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

#111942

From	"Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date	2017-06-10 15:13 -0700
Message-ID	<a34f1954-7ac2-482e-b3d3-c15e2a0867dc@googlegroups.com>
In reply to	#111939

On Saturday, June 10, 2017 at 5:43:49 PM UTC-4, GOTHIER Nathan wrote:
> Indeed. I am stunned by the fierce opposition to labels and goto while many
> detractors acknowledge its incredible power for corner cases where they are
> unable to express clearly their algorithm with a higher level loop structure.

Here's a function that may help you:

    int assess_user(void)
    {
        int misunderstanding;

        if (user == _GOTHIER)
        {
            misunderstanding = 1;
            goto quit;

        } else {
            misunderstanding = 0;
        }

    quit:
        return(misunderstanding);
    }

Thank you,
Rick C. Hodgin

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

#111943

From	bartc <bc@freeuk.com>
Date	2017-06-10 23:21 +0100
Message-ID	<ph__A.28502$9M.11355@fx18.am4>
In reply to	#111939

On 10/06/2017 22:40, GOTHIER Nathan wrote:
> On Sat, 10 Jun 2017 11:52:29 -0700 (PDT)
> David Kleinecke <dkleinecke@gmail.com> wrote:
> 
>> But from the point of view of what is easier to "understand" I
>> suspect the form in goto's has more popular appeal.
> 
> Indeed. I am stunned by the fierce opposition to labels and goto while many
> detractors acknowledge its incredible power for corner cases where they are
> unable to express clearly their algorithm with a higher level loop structure.

Here's the Sieve benchmark [prime number thing] as I generate it now as 
C code (assume some typedefs, not shown):

  int32   count;
  int32   i;
  int32   k;
  int32   prime;
  int32   av_1;
      count = 0;
      av_1 = 20000;
      while (av_1--) {
          for (i=1; i<=8192; ++i) {
              data[i-1] = 1;
          }
          for (i=1; i<=8192; ++i) {
              if (!!data[i-1]) {
                  k = (prime = i+i+3)+i;
                  while (k <= 8192) {
                      data[k-1] = 0;
                      k += prime;
                  }
                  ++count;
              }
          }
      }
      printf("%s %d\n","Count =",count);
  }

Here's what it looks like as 'flat' C code with if/goto and no other 
structuring (and with simple expressions):

i32 count;
i32 i;
i32 k;
i32 prime;
i32 av$1;
byte $1;
i32 $2;

  count = 0;
  av$1 = 20000;
L2:
L5:
  i = 1;
L6:
  *(data+i-1) = 1;
L7:
  ++i;
  if (i <= 8190) goto L6;
L8:
L9:
  i = 1;
L10:
  $1 = *(data+i-1);
  if (!$1) goto L13;
  $2 = i+i;
  prime = $2+3;
  k = i+prime;
  goto L15;
L14:
  *(data+k-1) = 0;
  k = k+prime;
L15:
  if (k <= 8190) goto L14;
L16:
  ++count;
L13:
L11:
  ++i;
  if (i <= 8190) goto L10;
L12:
L3:
  --av$1;
  if (av$1) goto L2;
L4:
  $startprintcon();
  $prints("Count =");
  $printi(count);
  $println();
  $endprint();
L1:

Don't tell me you think the latter is easier to understand.

-- 
bartc

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

#111947

From	GOTHIER Nathan <nathan.gothier@gmail.com>
Date	2017-06-11 00:28 +0200
Message-ID	<20170611002843.81ccd409ff00266ec17fa6ca@gmail.com>
In reply to	#111943

On Sat, 10 Jun 2017 23:21:09 +0100
bartc <bc@freeuk.com> wrote:

> Don't tell me you think the latter is easier to understand.

Don't tell me a human being spend as much time to write the latter code than
the former...

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

#111965

From	bartc <bc@freeuk.com>
Date	2017-06-11 10:56 +0100
Message-ID	<Ct8%A.44193$0L7.41019@fx20.am4>
In reply to	#111947

On 10/06/2017 23:28, GOTHIER Nathan wrote:
> On Sat, 10 Jun 2017 23:21:09 +0100
> bartc <bc@freeuk.com> wrote:
> 
>> Don't tell me you think the latter is easier to understand.
> 
> Don't tell me a human being spend as much time to write the latter code than
> the former...
> 

Nobody wrote either. Both are generated from high level structured form 
similar to the first.

The second demonstrates what code can look like if you take out 
structured statements such as for and while, remove compound statements, 
remove else, and only allow if-statements to be followed a goto statement.

AFAIK you don't want to eliminate indentation and compound statements, 
but consider this while loop:

  while (n--) {
     a[++i] = n;
  }

which can be rewritten with goto like this:

  L231:
    if (n--) goto L232;
    {
      a[++i] = n;
      goto L231;
    }
  L232:

The trouble is that the following has the same structure:

  L231:
    if (n--) goto L232;
    {
      a[++i] = n;
      goto L213;
    }
  L232:

but now does something quite different. It is much less robust.

A goto can be changed from a backward to forward jump, or vice versa, 
and there is no visible difference to the structure of the code. That is 
much harder to do when using proper loops.

-- 
bartc

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

#111967

From	GOTHIER Nathan <nathan.gothier@gmail.com>
Date	2017-06-11 13:27 +0200
Message-ID	<20170611132725.17b2c4db5edb63851e5b071c@gmail.com>
In reply to	#111965

On Sun, 11 Jun 2017 10:56:50 +0100
bartc <bc@freeuk.com> wrote:

> Nobody wrote either. Both are generated from high level structured form 
> similar to the first.

Thus you can't fairly compare your high level loop structure against the low
level one since most of the expressive work have be done at the high level by
the programmer. At a lower level the programmer would define more expressive
label names with more robust block patterns.

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

#111970

From	bartc <bc@freeuk.com>
Date	2017-06-11 13:19 +0100
Message-ID	<0za%A.81067$yT.57797@fx10.am4>
In reply to	#111967

On 11/06/2017 12:27, GOTHIER Nathan wrote:
> On Sun, 11 Jun 2017 10:56:50 +0100
> bartc <bc@freeuk.com> wrote:
> 
>> Nobody wrote either. Both are generated from high level structured form
>> similar to the first.
> 
> Thus you can't fairly compare your high level loop structure against the low
> level one since most of the expressive work have be done at the high level by
> the programmer. At a lower level the programmer would define more expressive
> label names with more robust block patterns.

OK, here's a real piece of C code, for the same task:

  int i,t,iter,prime,k;

  count=0;

  for (iter=1; iter<=20000; ++iter) {
     for (i=1; i<=size; ++i) {
         data[i]=1;
     }

     for (i=1; i<=size; ++i) {
         if (data[i]) {
             prime = i*2+3;
             k = i+prime;
             while (k<=size) {
                 data[k]=0;
                 k=k+prime;
             }
             ++count;
         }
     }
  }

Here's same code, minus the explicit loops:

  int i,t,iter,prime,k;

  count=0;

  iter=1;
  outerloop:
  {
      i=1;
  copyloop:
      {
          data[i]=1;
          ++i;
          if (i<=size) goto copyloop;
      }

      i=1;
  mainloop:
      {
          if (data[i]) {
              prime = i*2+3;
              k = i+prime;
  innerloop:
              {
                  if (k>size) goto endinnerloop;
                  data[k]=0;
                  k=k+prime;
                  goto innerloop;
              }
  endinnerloop:
              ++count;
          }
          ++i;
          if (i<=size) goto mainloop;
      }

      ++iter;
      if (iter<=20000) goto outerloop;
  }

Here, I was able to use my knowledge of the values to move the loop 
tests to the end of the loop in some cases, which is tidier. However, if 
in future that changes because the limits are no longer constants, then 
this code won't automatically change (as happens with a 
compiler-constructed loop), and it may not work properly.

So it's more fragile. Also, as I pointed out before, it is very easy to 
write mainloop instead of copyloop, etc and the compiler won't detect 
the error. Again fragile.

In addition, if I needed to duplicate the body of copyloop for example 
further down the function, then I would need to remember to create a new 
label for it, and to change the name of the embedded goto label. If I 
don't... well that is once more fragile.

That's why people avoid things like goto unless there is no easy 
alternative. It is error prone and can render code unreadable. And 
harder to translate code to another language when that language doesn't 
have goto, or its use is prohibited.

-- 
Bartc

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

#111975

From	Ike Naar <ike@iceland.freeshell.org>
Date	2017-06-11 18:36 +0000
Message-ID	<slrn3vfsojr3ko.smk.ike@iceland.freeshell.org>
In reply to	#111965

On 2017-06-11, bartc <bc@freeuk.com> wrote:
> On 10/06/2017 23:28, GOTHIER Nathan wrote:
>> On Sat, 10 Jun 2017 23:21:09 +0100
>> bartc <bc@freeuk.com> wrote:
>> 
>>> Don't tell me you think the latter is easier to understand.
>> 
>> Don't tell me a human being spend as much time to write the latter code than
>> the former...
>> 
>
> Nobody wrote either. Both are generated from high level structured form 
> similar to the first.
>
> The second demonstrates what code can look like if you take out 
> structured statements such as for and while, remove compound statements, 
> remove else, and only allow if-statements to be followed a goto statement.
>
> AFAIK you don't want to eliminate indentation and compound statements, 
> but consider this while loop:
>
>   while (n--) {
>      a[++i] = n;
>   }
>
> which can be rewritten with goto like this:
>
>   L231:
>     if (n--) goto L232;

You probably forgot a 'not' operator.

>     {
>       a[++i] = n;
>       goto L231;
>     }
>   L232:
>
> The trouble is that the following has the same structure:
>
>   L231:
>     if (n--) goto L232;
>     {
>       a[++i] = n;
>       goto L213;
>     }
>   L232:
>
> but now does something quite different. It is much less robust.

What's the difference (except for the L231 <-> L213 typo)?
If the typo is the point you're making, it's not a strong point,
because a typo in the stuctured while loop would also lead to
incorrect behaviour.

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

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

csiph-web

memscan() function or equivalent

Contents

#111941

#111946

#111949

#111959

#111960

#111979

#111951

#111944

#111945

#111950

#111963

#111964

#111954

#111942

#111943

#111947

#111965

#111967

#111970

#111975