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

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

old c

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

Contents

  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

#94013 — old c

i think
in the compiler i use code as

int v;g(u){v=strlen(u);}
main(){return v==g("main");}

would compile... in other compile compile too

v;g(u){v=strlen(u);}
main(){return v==g("main");}

but it not compile
int v;g(u){return *u;}
main(){return v==g("main");} 

this because can not be done *u when u is one int

exist C compiler command option for programs that use int as a
pointers to char?
[in the meaning it is possible do *w or w[j] where w is one int]

[toc] | [next] | [standalone]

#94015

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.

> in other compile compile too
>
> v;g(u){v=strlen(u);}
> main(){return v==g("main");}

Yes, that make the use of implicit int declarations consistent.  You
still have an extraneous newline, though.  Assuming a type of int when the
type is missing was always considered bad style (I'm going back to the
70s here) but it's not even legal syntax in modern C.

> but it not compile
> int v;g(u){return *u;}
> main(){return v==g("main");} 
>
> this because can not be done *u when u is one int

That's right.  Dereferencing an int is not permitted.  However, a
compiler is permitted to ignore that and generate code anyway.  I don't
know if any actually will.

> exist C compiler command option for programs that use int as a
> pointers to char?

Pass.  Why does it matter to you?

-- 
Ben.

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

#94234

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.

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.

So if it's dereferencing ints, then you want to be able to do
the same. With any luck, the ints are not absolute addresses but
derived from pointers. Once you've understood it, of course, replace
the dereferenced ints with modern pointers, test against the 
functional copy to check you haven't inadvertently changed anything
important, then drop the legacy code.

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

#94237

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.

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

#94239

On 9/29/2016 6:01 AM, Ben Bacarisse wrote:
> 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>
> 

I have - many times.  When a program gets to be too big, you can get
lost in the details without understanding the overall picture
(forest/trees problem).  In cases like this, it is often helpful to draw
a flow chart to get an overall picture of what's going on.  It's easier
when you can understand the dynamics of the program's operation.

When you're talking 100K+ LOC and thousands of functions, you just can't
look at the code and understand how it operates - even if it is commented.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#94250

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 9/29/2016 6:01 AM, Ben Bacarisse wrote:
>> 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>
>> 
>
> I have - many times.  When a program gets to be too big, you can get
> lost in the details without understanding the overall picture
> (forest/trees problem).  In cases like this, it is often helpful to draw
> a flow chart to get an overall picture of what's going on.  It's easier
> when you can understand the dynamics of the program's operation.

We may be talking at cross purposes here.  I'm talking about the method
of gaining that understanding.

> When you're talking 100K+ LOC and thousands of functions, you just can't
> look at the code and understand how it operates - even if it is
> commented.

I've never found it helpful to watch a few of the billions upon billions
of execution traces that such a large program is capable of.  But I am
happy to note a difference between up here and leave it at that.

-- 
Ben.

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

#94253

On Thursday, September 29, 2016 at 5:13:13 PM UTC+1, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
> > When you're talking 100K+ LOC and thousands of functions, you just can't
> > look at the code and understand how it operates - even if it is
> > commented.
> 
> I've never found it helpful to watch a few of the billions upon billions
> of execution traces that such a large program is capable of.  But I am
> happy to note a difference between up here and leave it at that.
> 
There are lots of tricks. Like getchars() to halt after a diagnostic printf().
Or the use of static counters to print out only the first few passes.
Or commenting out or stubbing functions to gain an understanding
of the basic flow control.

However of course it is often overwhelming. Functions are often called
milions of times, and only two or three of those calls might make crucial
decisions, the rest just pass through data. Finding the two or three calls
that make the rest of the logic hang together can be difficult

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

#94266

On 9/29/2016 12:13 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 9/29/2016 6:01 AM, Ben Bacarisse wrote:
>>> 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>
>>>
>>
>> I have - many times.  When a program gets to be too big, you can get
>> lost in the details without understanding the overall picture
>> (forest/trees problem).  In cases like this, it is often helpful to draw
>> a flow chart to get an overall picture of what's going on.  It's easier
>> when you can understand the dynamics of the program's operation.
> 
> We may be talking at cross purposes here.  I'm talking about the method
> of gaining that understanding.
>

So am I.

>> When you're talking 100K+ LOC and thousands of functions, you just can't
>> look at the code and understand how it operates - even if it is
>> commented.
> 
> I've never found it helpful to watch a few of the billions upon billions
> of execution traces that such a large program is capable of.  But I am
> happy to note a difference between up here and leave it at that.
> 

Maybe you're looking at the wrong traces.  The initial traces I look at
is only function calls - get an idea of the flow.  Then I look into the
functions as necessary.

You can't get a handle on what a function does unless you understand
what the functions it calls do.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#94302

On Thursday, September 29, 2016 at 5:01:49 AM UTC-5, Ben Bacarisse wrote:
> But here we disagree.  I've never come across a program that is easier
> to understand dynamically than it is to understand statically.

Different people gain understanding different ways, but at least for some
people in some situations, seeing how things work dynamically offers some
major insights which are much harder to get from a static printed page.
In most cases, the goal isn't purely to watch a program running, but rather
interact with pieces of it to identify the effect of changing something.

I've noticed that some people here have a tendency to presume that anything
which they don't personally find useful should be considered "useless", not
withstanding the fact that if *anyone* makes use of something to accomplish
some purpose, that would be prima facie evidence of usefulness.

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

#94040

On Sunday, September 25, 2016 at 4:41:41 AM UTC-5, Rosario19 wrote:
> i think
> in the compiler i use code as
> 
> int v;g(u){v=strlen(u);}
> main(){return v==g("main");}
> 
> would compile... in other compile compile too
> 
> v;g(u){v=strlen(u);}
> main(){return v==g("main");}
> 
> but it not compile
> int v;g(u){return *u;}
> main(){return v==g("main");} 
> 
> this because can not be done *u when u is one int
> 
> exist C compiler command option for programs that use int as a
> pointers to char?
> [in the meaning it is possible do *w or w[j] where w is one int]

One technique you can use to get pointer-like behavior
from (implicit) ints is to use the integer values as
offsets or *cursors*. For most unix-like platforms I
have used, you can use the `brk()` system call to get
a base-pointer that can be used to access heap memory
with cursors.

#include<unistd.h>
int x;
char*mem;
main(){
    mem=brk();
    x=strdup("Hello, World!")-mem;
    printf("%s\n", &mem[x]);
}

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

#94218

In article <d2bac960-66bb-4c28-97ec-22c6fa35f244@googlegroups.com>,
luser droog  <luser.droog@gmail.com> wrote:
>One technique you can use to get pointer-like behavior
>from (implicit) ints is to use the integer values as
>offsets or *cursors*. For most unix-like platforms I
>have used, you can use the `brk()` system call to get
>a base-pointer that can be used to access heap memory
>with cursors.
>
>#include<unistd.h>
>int x;
>char*mem;
>main(){
>    mem=brk();
>    x=strdup("Hello, World!")-mem;
>    printf("%s\n", &mem[x]);
>}

Why?

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

#94227

On Wednesday, September 28, 2016 at 4:02:45 PM UTC-5, Joe keane wrote:
> In article <d2bac960-66bb-4c28-97ec-22c6fa35f244@googlegroups.com>,
> luser droog  <luser.droog@gmail.com> wrote:
> >One technique you can use to get pointer-like behavior
> >from (implicit) ints is to use the integer values as
> >offsets or *cursors*. For most unix-like platforms I
> >have used, you can use the `brk()` system call to get
> >a base-pointer that can be used to access heap memory
> >with cursors.
> >
> >#include<unistd.h>
> >int x;
> >char*mem;
> >main(){
> >    mem=brk();
> >    x=strdup("Hello, World!")-mem;
> >    printf("%s\n", &mem[x]);
> >}
> 
> Why?

golf.

[toc] | [prev] | [standalone]

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

csiph-web