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

Groups > comp.lang.c > #94237

Re: old c

Show all headers | View raw

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Sunday, September 25, 2016 at 11:24:40 AM UTC+1, Ben Bacarisse wrote:
>> Rosario19 <Ros@invalid.invalid> writes:
>> 
>> > i think
>> > in the compiler i use code as
>> >
>> > int v;g(u){v=strlen(u);}
>> > main(){return v==g("main");}
>> >
>> > would compile...
>> 
>> You may want to aim higher -- just managing to get some code to generate
>> an executable is a rather low bar, especially since C compilers tend to
>> be very generous in overlooking problems.
>> 
> Say you've got some legacy code written in the 1970s which is a madman's
> attempt at solving the halting problem, and on a now obsolete ferrite
> core machine, it does work.
>
> It's worth studying, but the ferrite core machine is on its last
> legs and no-one can now compile C source for it. But the code is, 
> obviously, a tangled web that works on some algorithmic principle
> that only the madman understood, and he's now sadly deceased, he 
> can't tell you how he did it any more.

Obviously we are in agreement that one should aim higher than just
getting some C code to generate an executable.  Had the madman been
given (and taken) such advice we would not be in this situation.

> So what to do? Best bet is to compile and run it, and verify that
> it actually does solve the halting problem, at least on any inputs
> you can devise. Then insert diagnostic printfs or step through it
> in a debugger, and gradually try to work out how it achieves it.

But here we disagree.  I've never come across a program that is easier
to understand dynamically than it is to understand statically.  If the
machine's documentation is not available, you might well want to write
and run some small test programs to find out what various constructs do,
but once you know the answers to these questions, it's always going to
be easier to understand a program "on paper".  For anything but trivial
algorithms, dynamic execution traces through the static code tell you
very little compared to a step by step deconstruction of the program's
necessarily finite text.

<snip>
-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

old c Rosario19 <Ros@invalid.invalid> - 2016-09-25 11:41 +0200
  Re: old c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:24 +0100
    Re: old c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-28 21:08 -0700
      Re: old c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-29 11:01 +0100
        Re: old c Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-29 10:11 -0400
          Re: old c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-29 17:13 +0100
            Re: old c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-29 09:51 -0700
            Re: old c Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-29 17:15 -0400
        Re: old c supercat@casperkitty.com - 2016-09-30 08:03 -0700
  Re: old c luser droog <luser.droog@gmail.com> - 2016-09-25 11:13 -0700
    Re: old c jgk@panix.com (Joe keane) - 2016-09-28 21:02 +0000
      Re: old c luser droog <luser.droog@gmail.com> - 2016-09-28 15:28 -0700

csiph-web