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

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

lalloc() -- local stack allocation

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

Contents

  lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 02:23 -0700
    Re: lalloc() -- local stack allocation Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-12 11:48 +0200
      Re: lalloc() -- local stack allocation Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-12 11:48 +0200
    Re: lalloc() -- local stack allocation Philipp Klaus Krause <pkk@spth.de> - 2015-07-12 13:33 +0200
    Re: lalloc() -- local stack allocation Robert Wessel <robertwessel2@yahoo.com> - 2015-07-12 06:54 -0500
    Re: lalloc() -- local stack allocation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:17 -0700
      Re: lalloc() -- local stack allocation Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-12 16:47 +0200
        Re: lalloc() -- local stack allocation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 11:12 -0700
        Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-08 11:53 -0700
          Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 12:16 -0700
            Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-08 15:46 -0700
              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:12 -0700
                Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 06:53 -0700
                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 16:06 -0700
                    Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 16:17 -0700
                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 16:26 -0700
                        Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 19:22 -0700
                          Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 19:55 -0700
                            Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 20:46 -0700
                              Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 20:50 -0700
                                Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-11 23:59 -0700
                                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 06:22 -0700
                              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 21:10 -0700
                                Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-10 07:08 -0700
                                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 08:17 -0700
                                    Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-10 08:54 -0700
                                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 09:19 -0700
                                        Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-10 16:55 -0700
                                          Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 18:41 -0700
                                            Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-11 09:04 -0700
                                              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 10:17 -0700
                                                Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-11 11:34 -0700
                                                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 11:47 -0700
                                                    Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-11 13:44 -0700
                                                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 17:52 -0700
                                              Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-11 11:37 -0700
                            Re: lalloc() -- local stack allocation Richard Damon <Richard@Damon-Family.org> - 2015-09-10 08:24 -0400
                              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-10 05:55 -0700
                                RDC (Was: lalloc() -- local stack allocation) gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-10 13:01 +0000
                                Re: lalloc() -- local stack allocation Richard Damon <Richard@Damon-Family.org> - 2015-09-11 00:29 -0400
                                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 05:37 -0700
                                    Re: lalloc() -- local stack allocation Richard Damon <Richard@Damon-Family.org> - 2015-09-11 22:48 -0400
                                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 20:05 -0700
                                        Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 20:22 -0700
                                          Re: lalloc() -- local stack allocation Melzzzzz <mel@zzzzz.com> - 2015-09-12 11:57 +0200
                                            Re: lalloc() -- local stack allocation fir <profesor.fir@gmail.com> - 2015-09-12 04:34 -0700
                                              Re: lalloc() -- local stack allocation fir <profesor.fir@gmail.com> - 2015-09-12 07:28 -0700
                                            Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 05:44 -0700
                            Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 13:02 +1200
                              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 18:25 -0700
                                Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 13:42 +1200
                                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 19:11 -0700
                                    Re: lalloc() -- local stack allocation Melzzzzz <mel@zzzzz.com> - 2015-09-12 04:27 +0200
                                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 19:44 -0700
                                      Re: lalloc() -- local stack allocation James Kuyper <jameskuyper@verizon.net> - 2015-09-11 23:01 -0400
                                        Re: lalloc() -- local stack allocation Richard Heathfield <rjh@cpax.org.uk> - 2015-09-12 11:12 +0100
                                          Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 05:55 -0700
                                            Re: lalloc() -- local stack allocation Richard Heathfield <rjh@cpax.org.uk> - 2015-09-12 14:16 +0100
                                              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 06:24 -0700
                                                Re: lalloc() -- local stack allocation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-12 10:57 -0700
                                                  Re: lalloc() -- local stack allocation fir <profesor.fir@gmail.com> - 2015-09-12 11:13 -0700
                                                  Re: lalloc() -- local stack allocation Gareth Owen <gwowen@gmail.com> - 2015-09-12 19:31 +0100
                                                    Re: lalloc() -- local stack allocation gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-12 19:20 +0000
                                                  Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 12:06 -0700
                                                    Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-12 14:24 -0700
                                                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 19:22 -0700
                                    Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 14:54 +1200
                                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 20:18 -0700
                                        Re: lalloc() -- local stack allocation Ian Collins <ian-news@hotmail.com> - 2015-09-12 16:20 +1200
                                          Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 05:43 -0700
                                          Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-12 14:02 -0700
                                  Re: lalloc() -- local stack allocation Melzzzzz <mel@zzzzz.com> - 2015-09-12 04:25 +0200
                              Re: lalloc() -- local stack allocation Bartc <bc@freeuk.com> - 2015-09-12 10:32 +0100
                    Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 16:23 -0700
                      Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 16:38 -0700
                        Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 17:01 -0700
                          Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 17:08 -0700
                            Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-09 17:37 -0700
                              Re: lalloc() -- local stack allocation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 18:06 -0700
                          Re: lalloc() -- local stack allocation Bartc <bc@freeuk.com> - 2015-09-10 10:54 +0100
                    Re: lalloc() -- local stack allocation supercat@casperkitty.com - 2015-09-09 16:24 -0700
          Re: lalloc() -- local stack allocation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-08 20:32 +0100
          Re: lalloc() -- local stack allocation jadill33@gmail.com - 2015-09-08 13:25 -0700
    Re: lalloc() -- local stack allocation "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-12 10:17 -0700
    Re: lalloc() -- local stack allocation gordonb.zziiu@burditt.org (Gordon Burditt) - 2015-07-27 22:41 -0500
      Re: lalloc() -- local stack allocation Keith Thompson <kst-u@mib.org> - 2015-07-28 08:35 -0700

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

#70239

On Friday, September 11, 2015 at 12:29:13 AM UTC-4, Richard Damon wrote:
> On 9/10/15 8:55 AM, Rick C. Hodgin wrote:
> > On Thursday, September 10, 2015 at 8:24:38 AM UTC-4, Richard Damon wrote:
> >> Note, that when ptr goes out of scope, so does the int buff, and you
> >> should release its stack space, but you have 'trapped' it with the
> >> lalloc allocation? (This isn't insolvable, but it doesn't sound like you
> >> have given this any thought).
> >
> > In RDC, int buff[] and float buff[] are static. They exist on the
> > stack always, regardless of scope. And, since they exist outside
> > of each other's scope, they will be partially/fully overlapped.
> >
> > Best regards,
> > Rick C. Hodgin
> >
> 
> Do you do the same for struct type variables on the stack?

When they are like this:

    struct SAbc
    {
        int i;
        float f;
    };

    int main(int argc, char* argv[])
    {
        struct SAbc a;

        // Code here
    }

Yes, a is allocated as a fixed quantity on the stack upon entry into
the function.

> Even just an 
> ordinary int would show the problem, just maybe you can try to brush it 
> under the rug for being small.

There is no problem.  But if you think there is, perhaps you can teach
me what the problem is rather than making comments like "but it doesn't
sound like you have given this any thought" and "maybe you can try to
brush it under the rug".  Those comments aren't helpful, but are rude
and insulting because you discredit me, my prior efforts, accounting my
thought and work not only for nothing, but less than nothing.

If I've made a mistake somewhere, I'll be happy to listen.

> One BIG issue with making arrays automatically static is now no 
> recursive or reenterent function can use an array on the stack!

The are statically allocated within local stack space, so they always
have their fixed slots within each function call.  They are not
dynamically allocated when their scope is entered, but they always
exist from the first instruction in the function, which will reserve
stack space for them.

> You also have likely greatly increased the memory requirement for some 
> programs, as EVERY array used within every function needs to be 
> statically allocated, not just those currently being executed.

All local variables consume some stack space when allocated in local
variable space.  It's just the way of things.

Dynamic arrays, on the other hand, contain a small footprint in local
variable space, and allocate their bulk memory in the main heap.  They
are also still reentrant, but the heap will grow with each call, in
addition to the small footprint growth on the stack.

Best regards,
Rick C. Hodgin

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

#70304

On 9/11/15 8:37 AM, Rick C. Hodgin wrote:
> On Friday, September 11, 2015 at 12:29:13 AM UTC-4, Richard Damon wrote:
>> On 9/10/15 8:55 AM, Rick C. Hodgin wrote:
>>> On Thursday, September 10, 2015 at 8:24:38 AM UTC-4, Richard Damon wrote:
>>>> Note, that when ptr goes out of scope, so does the int buff, and you
>>>> should release its stack space, but you have 'trapped' it with the
>>>> lalloc allocation? (This isn't insolvable, but it doesn't sound like you
>>>> have given this any thought).
>>>
>>> In RDC, int buff[] and float buff[] are static. They exist on the
>>> stack always, regardless of scope. And, since they exist outside
>>> of each other's scope, they will be partially/fully overlapped.
>>>
>>> Best regards,
>>> Rick C. Hodgin
>>>
>>
>> Do you do the same for struct type variables on the stack?
>
> When they are like this:
>
>      struct SAbc
>      {
>          int i;
>          float f;
>      };
>
>      int main(int argc, char* argv[])
>      {
>          struct SAbc a;
>
>          // Code here
>      }
>
> Yes, a is allocated as a fixed quantity on the stack upon entry into
> the function.
>
>> Even just an
>> ordinary int would show the problem, just maybe you can try to brush it
>> under the rug for being small.
>
> There is no problem.  But if you think there is, perhaps you can teach
> me what the problem is rather than making comments like "but it doesn't
> sound like you have given this any thought" and "maybe you can try to
> brush it under the rug".  Those comments aren't helpful, but are rude
> and insulting because you discredit me, my prior efforts, accounting my
> thought and work not only for nothing, but less than nothing.
>
> If I've made a mistake somewhere, I'll be happy to listen.
>
>> One BIG issue with making arrays automatically static is now no
>> recursive or reenterent function can use an array on the stack!
>
> The are statically allocated within local stack space, so they always
> have their fixed slots within each function call.  They are not
> dynamically allocated when their scope is entered, but they always
> exist from the first instruction in the function, which will reserve
> stack space for them.
>

PLEASE try to use the right terms! 'static' is a keyword in C and means 
something very different here.

YOU said arrays were STATIC, that means that they are NOT stored on the 
stack, but at a fixed address in memory that persists between calls to 
the function, and through all levels of recursion.

Since you used a term incorrectly, a number of my comments don't apply.

(You also seem a bit deliberately confusing, as you seem to point out 
that it was ARRAYS that were static, as opposed to saying that ALL 
variables were static.)

C doesn't have a word for the method you are describing (as it doesn't 
affect the behavior of well behaved programs), but one term I would 
think applies is that your functions use a fixed stack frame (as opposed 
to the frame adjusting block to block as the program moves through). (IF 
you really want to use the word static, I suppose something like 
'functions use a static stack frame' would minimize the confusion as 
here at least it is clear that you aren't referring to the C word static.

Some issues with this are:
1) You are basically forced to make two passes through the code in some 
manner, as you need one pass to figure out how much space you need to 
reserve at the start of the function, and then you can generate the code 
(you also could generate the code and then go back and patch the 
preamble, or put the preamble at the end of the function and jump back).

2) You have the possibility of greatly increasing stack usage. IF you 
have a block scope set of variables in the function, and a function call 
that is outside that block scope, then the fixed frame is going to added 
to the usage even though not needed. This is especially bad if you have 
a recursive function that can do the recursion without the need for many 
variables, but at the end, needs a significant amount of memory to do 
the basic operation, all the recursion levels are going to use that 
extra memory.

>> You also have likely greatly increased the memory requirement for some
>> programs, as EVERY array used within every function needs to be
>> statically allocated, not just those currently being executed.
>
> All local variables consume some stack space when allocated in local
> variable space.  It's just the way of things.
>
> Dynamic arrays, on the other hand, contain a small footprint in local
> variable space, and allocate their bulk memory in the main heap.  They
> are also still reentrant, but the heap will grow with each call, in
> addition to the small footprint growth on the stack.
>
> Best regards,
> Rick C. Hodgin
>

It seems more to me that you want to use a simpler and less efficient 
organization as it is what you understand.

One big issue that I see with your method is you are putting extra 
overhead on the compiler to keep track of these heap allocations, so 
that they are automatically deleted on function exit. The big advantage 
of stack based allocations is that the act of resetting the stack point 
is all that is needed to deallocate the memory.

IF you had a special heap for this, outside the regular heap, then the 
deallocation would be simple, as you could just create this heap as 
really a stack, and just roll back the break point to where it was on 
entry. The problem is that now you have 3 changing areas, the heap, this 
special heap, and the stack, so you no longer can place one low and grow 
up, and the other high and grow down and you get to use all of memory 
until they meet. Now, at least one needs to get a specifically allocated 
size. Maybe not an issue if you are only targeting PC sized machines, 
but bad for small systems.

I recall that you have proudly boasted that you have chosen not to study 
what others have done, but to venture forth on your own. The big problem 
with this is that we learn from mistakes, and we really don't have the 
time to make all the mistakes ourselves, so we can only do our best when 
we are willing to look at what others have done, and learn from their 
mistakes as well, and what they did that seems to have worked. It seems 
that many of your ideas remind me so much of things that I heard people 
discussing decades ago, and people learned from the attempts, but you 
haven't, because you have chosen to ignore history. (and I don't think 
this problem is limited to your programming).

History has shown that clean heap based allocations work (with care or 
automation to deallocate it), and clean stack based allocations work 
(simple variables). Dynamic stack based allocation has a checkered 
history, it SEEMS like it should be very useful, but it normally ends up 
with some warts. (one of the reasons that Variable Length Arrays and 
alloca() haven't been broadly adopted).

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

#70307

On Friday, September 11, 2015 at 10:48:31 PM UTC-4, Richard Damon wrote:
> On 9/11/15 8:37 AM, Rick C. Hodgin wrote:
> > On Friday, September 11, 2015 at 12:29:13 AM UTC-4, Richard Damon wrote:
> >> On 9/10/15 8:55 AM, Rick C. Hodgin wrote:
> >>> On Thursday, September 10, 2015 at 8:24:38 AM UTC-4, Richard Damon wrote:
> >>>> Note, that when ptr goes out of scope, so does the int buff, and you
> >>>> should release its stack space, but you have 'trapped' it with the
> >>>> lalloc allocation? (This isn't insolvable, but it doesn't sound like you
> >>>> have given this any thought).
> >>>
> >>> In RDC, int buff[] and float buff[] are static. They exist on the
> >>> stack always, regardless of scope. And, since they exist outside
> >>> of each other's scope, they will be partially/fully overlapped.
> >>>
> >>> Best regards,
> >>> Rick C. Hodgin
> >>>
> >>
> >> Do you do the same for struct type variables on the stack?
> >
> > When they are like this:
> >
> >      struct SAbc
> >      {
> >          int i;
> >          float f;
> >      };
> >
> >      int main(int argc, char* argv[])
> >      {
> >          struct SAbc a;
> >
> >          // Code here
> >      }
> >
> > Yes, a is allocated as a fixed quantity on the stack upon entry into
> > the function.
> >
> >> Even just an
> >> ordinary int would show the problem, just maybe you can try to brush it
> >> under the rug for being small.
> >
> > There is no problem.  But if you think there is, perhaps you can teach
> > me what the problem is rather than making comments like "but it doesn't
> > sound like you have given this any thought" and "maybe you can try to
> > brush it under the rug".  Those comments aren't helpful, but are rude
> > and insulting because you discredit me, my prior efforts, accounting my
> > thought and work not only for nothing, but less than nothing.
> >
> > If I've made a mistake somewhere, I'll be happy to listen.
> >
> >> One BIG issue with making arrays automatically static is now no
> >> recursive or reenterent function can use an array on the stack!
> >
> > The are statically allocated within local stack space, so they always
> > have their fixed slots within each function call.  They are not
> > dynamically allocated when their scope is entered, but they always
> > exist from the first instruction in the function, which will reserve
> > stack space for them.
> >
> 
> PLEASE try to use the right terms! 'static' is a keyword in C and means 
> something very different here.
> 
> YOU said arrays were STATIC, that means that they are NOT stored on the 
> stack, but at a fixed address in memory that persists between calls to 
> the function, and through all levels of recursion.

Static is a proper word to use there.  #1 I was talking about RDC.
#2 it describes the nature of their allocation in local variable
space, in that they are not dynamic as by the use of no base pointer
and a constantly wandering esp. #3 it describes the nature of their
allocation in general.

> Since you used a term incorrectly, a number of my comments don't apply.
> 
> (You also seem a bit deliberately confusing, as you seem to point out 
> that it was ARRAYS that were static, as opposed to saying that ALL 
> variables were static.)

Your example included two arrays.  That's why I said arrays.

> C doesn't have a word for the method you are describing (as it doesn't 
> affect the behavior of well behaved programs), but one term I would 
> think applies is that your functions use a fixed stack frame (as opposed 
> to the frame adjusting block to block as the program moves through).

Correct.

> (IF 
> you really want to use the word static, I suppose something like 
> 'functions use a static stack frame' would minimize the confusion as 
> here at least it is clear that you aren't referring to the C word static.

I don't intend on calling them static in RDC.  I was describing their
nature because I presumed from your example that you were suggesting
they were dynamically allocated.  Your comment about "even an int will
throw it off" indicated the same.  My point was they are static, and
not dynamic, and that mandates the use of a stack frame / base pointer.

> Some issues with this are:
> 1) You are basically forced to make two passes through the code in some 
> manner, as you need one pass to figure out how much space you need to 
> reserve at the start of the function, and then you can generate the code 
> (you also could generate the code and then go back and patch the 
> preamble, or put the preamble at the end of the function and jump back).

#1 Not quite.  #2 So what?  I don't care about trying to do everything in
one pass.  In fact I think it's insane to do that.  I plan on RDC being
an N-pass compiler, even allowing for no forward declarations, but so
long as things are defined somewhere, they will be found and used, which
is as it should be in a language in my opinion.  I realize C is not like
that, but I think that's a flaw in C.

> 2) You have the possibility of greatly increasing stack usage. IF you 
> have a block scope set of variables in the function, and a function call 
> that is outside that block scope, then the fixed frame is going to added 
> to the usage even though not needed. This is especially bad if you have 
> a recursive function that can do the recursion without the need for many 
> variables, but at the end, needs a significant amount of memory to do 
> the basic operation, all the recursion levels are going to use that 
> extra memory.

Yup.  The stack could be used greatly.  How much does memory cost these
days?  Remind me... I can get 16 GB for how many dimes?

RDC -- Rapid DEVELOPMENT Compiler.

Computers are fast, and getting faster.  Developer time is the biggest
associated expense.  My goals with RDC are to empower developers to
have easier problems to solve, less complex things to look at, more
information at their disposal, the ability to see the steps from A to
B to C through a compilation, and so on.

I want to empower people, not processors.  I want people to have what
they need to thrive, with any future optimizations being exactly that:
future optimizations.

> >> You also have likely greatly increased the memory requirement for some
> >> programs, as EVERY array used within every function needs to be
> >> statically allocated, not just those currently being executed.
> >
> > All local variables consume some stack space when allocated in local
> > variable space.  It's just the way of things.
> >
> > Dynamic arrays, on the other hand, contain a small footprint in local
> > variable space, and allocate their bulk memory in the main heap.  They
> > are also still reentrant, but the heap will grow with each call, in
> > addition to the small footprint growth on the stack.
> >
> > Best regards,
> > Rick C. Hodgin
> >
> 
> It seems more to me that you want to use a simpler and less efficient 
> organization as it is what you understand.

As I state above, my goals are to empower people, not machines.

> One big issue that I see with your method is you are putting extra 
> overhead on the compiler to keep track of these heap allocations, so 
> that they are automatically deleted on function exit. The big advantage 
> of stack based allocations is that the act of resetting the stack point 
> is all that is needed to deallocate the memory.

Nope.  By using a base pointer, everything is dumped upon exit.  The
only things I will have to keep track of are calling destructors on
local declared classes when they go out of scope.  The rest is
automatically sorted out with this one assembly instruction:

     leave

Which does the equivalent of:

     mov esp,ebp
     pop ebp

> IF you had a special heap for this, outside the regular heap, then the 
> deallocation would be simple, as you could just create this heap as 
> really a stack, and just roll back the break point to where it was on 
> entry. The problem is that now you have 3 changing areas, the heap, this 
> special heap, and the stack, so you no longer can place one low and grow 
> up, and the other high and grow down and you get to use all of memory 
> until they meet. Now, at least one needs to get a specifically allocated 
> size. Maybe not an issue if you are only targeting PC sized machines, 
> but bad for small systems.

I might use a separate heap.  I haven't decided yet.  But it doesn't
matter.  Dynamic arrays are used for a reason.  I don't see it as
being an issue that they may fragment the heap.  I also have plans
to introduce a memory managed pointer which does a double-layer of
indirection allowing that heap to be defragmented at times.

> I recall that you have proudly boasted that you have chosen not to study 
> what others have done, but to venture forth on your own.

I have not proudly boasted about it.  I have stated that I have done
this because the Lord has blessed me with certain skills, and I desire
to operate under a spirit and knowledge which comes from Him directly,
and is not influenced by the spirit at work in people in this world,
which goes into their work, and out into everyone who receives it.

> The big problem 
> with this is that we learn from mistakes, and we really don't have the 
> time to make all the mistakes ourselves, so we can only do our best when 
> we are willing to look at what others have done, and learn from their 
> mistakes as well, and what they did that seems to have worked. It seems 
> that many of your ideas remind me so much of things that I heard people 
> discussing decades ago, and people learned from the attempts, but you 
> haven't, because you have chosen to ignore history. (and I don't think 
> this problem is limited to your programming).

I'm 45 years old.  I've been programming since I was a teenager.  I
have made lots of mistakes, but over time I am making fewer and
fewer.  And I'm okay with that.  If I make mistakes, it will be me
learning from the Lord about the thing I did wrong.  And in my
experience, He doesn't let me get so far away from myself that I
cannot recover, but instead as I go down wrong paths there is an
inner feeling I have, and it causes me to pause and reflect.

And there are times I seek advice from people face-to-face, but only
up to the point where that spirit enters in.  When that spirit shows
his ugly head, then I walk away.

> History has shown that clean heap based allocations work (with care or 
> automation to deallocate it), and clean stack based allocations work 
> (simple variables). Dynamic stack based allocation has a checkered 
> history, it SEEMS like it should be very useful, but it normally ends up 
> with some warts. (one of the reasons that Variable Length Arrays and 
> alloca() haven't been broadly adopted).

Great!  There's nothing to prevent that optimization from being
added in later if it's really such a horrible performance killer
that the applications can't run without it on these modern 4 GHz
CPUs we have with 2+ MB L2 cache, and 8+ MB L3 cache.

If it becomes an issue, I'll contact you and ask for your help.

Best regards,
Rick C. Hodgin

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

#70309

On Friday, September 11, 2015 at 11:05:43 PM UTC-4, Rick C. Hodgin wrote:
> I'm 45 years old...

Oops!  I'm 46.  I forgot I had a birthday in August. :-)

Best regards,
Rick C. Hodgin

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

#70327

On Fri, 11 Sep 2015 20:22:41 -0700 (PDT)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> On Friday, September 11, 2015 at 11:05:43 PM UTC-4, Rick C. Hodgin
> wrote:
> > I'm 45 years old...
> 
> Oops!  I'm 46.  I forgot I had a birthday in August. :-)
> 

Im 46 as well. 47 in next November ;p

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

#70333

W dniu sobota, 12 września 2015 11:57:25 UTC+2 użytkownik Melzzzzz napisał:
> On Fri, 11 Sep 2015 20:22:41 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > On Friday, September 11, 2015 at 11:05:43 PM UTC-4, Rick C. Hodgin
> > wrote:
> > > I'm 45 years old...
> > 
> > Oops!  I'm 46.  I forgot I had a birthday in August. :-)
> > 
> 
> Im 46 as well. 47 in next November ;p

Im 39 in august but feel like 30

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

#70352

W dniu sobota, 12 września 2015 13:34:59 UTC+2 użytkownik fir napisał:
> W dniu sobota, 12 września 2015 11:57:25 UTC+2 użytkownik Melzzzzz napisał:
> > On Fri, 11 Sep 2015 20:22:41 -0700 (PDT)
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> > 
> > > On Friday, September 11, 2015 at 11:05:43 PM UTC-4, Rick C. Hodgin
> > > wrote:
> > > > I'm 45 years old...
> > > 
> > > Oops!  I'm 46.  I forgot I had a birthday in August. :-)
> > > 
> > 
> > Im 46 as well. 47 in next November ;p
> 
> Im 39 in august but feel like 30

sorry in january (those names mistaked to me a bit)

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

#70337

On Saturday, September 12, 2015 at 5:57:25 AM UTC-4, Melzzzzz wrote:
> On Fri, 11 Sep 2015 20:22:41 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > On Friday, September 11, 2015 at 11:05:43 PM UTC-4, Rick C. Hodgin
> > wrote:
> > > I'm 45 years old...
> > 
> > Oops!  I'm 46.  I forgot I had a birthday in August. :-)
> > 
> 
> Im 46 as well. 47 in next November ;p

Since you're my elder, I can address you more formally if you prefer.

Best regards,
Rick C. Hodgin

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

#70297

Rick C. Hodgin wrote:
>
> In my proposed lalloc() model, even though ptr is no longer accessible
> and is out of scope, those 256 bytes would still be consumed on the
> stack.  In such a case as above it would be wasted memory.  But, it
> also presents the opportunity for something like this, which could
> allow reuse once allocated:
>
>      int main(int argc, char* argv[])
>      {
>          char* mirror;
>
>          if (argc == 2)
>          {
>              char* ptr = lalloc(256);
>              // Process ptr in some way
>              mirror = ptr;
>          }
>          // When you get here, ptr is out of scope, but mirror
>          // points to ptr's allocated data, which still exists
>          // on the stack, and won't be released until main() exits.
>      }

This all looks like a lot of work to implement a poor man's RAII.

I've suggested this before and I'm sure this won't be the last time: why 
don't you just use C++?  It already has or can emulate most of what you 
are looking to do.

-- 
Ian Collins

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

#70298

Ian Collins wrote:
> I've suggested this before and I'm sure this
> won't be the last time: why don't you just use
> C++? It already has or can emulate most of
> what you are looking to do.

First of all, no it won't.

Second of all, Bjarne Stroustrup.

Best regards,
Rick C. Hodgin

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

#70299

Rick C. Hodgin wrote:
> Ian Collins wrote:
>> I've suggested this before and I'm sure this
>> won't be the last time: why don't you just use
>> C++? It already has or can emulate most of
>> what you are looking to do.
>
> First of all, no it won't.
>
> Second of all, Bjarne Stroustrup.

Eh?  Do you reject everything created by someone you dislike?

-- 
Ian Collins

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

#70300

On Friday, September 11, 2015 at 9:42:29 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > Ian Collins wrote:
> >> I've suggested this before and I'm sure this
> >> won't be the last time: why don't you just use
> >> C++? It already has or can emulate most of
> >> what you are looking to do.
> > First of all, no it won't.
> > Second of all, Bjarne Stroustrup.
> 
> Eh?  Do you reject everything created by someone you dislike?

It's not a matter of disliking them.  It is a matter of the spirit
they operate under.  As I've said before, Bjarne Stroustrup is one
of the most arrogant people I've ever met in software.  That does
not come from nothing.  It comes from the presence of evil spirits
who inhabit and/or surround him.

People don't realize the nature of the battles we face in this
world.  They think we are all just people doing people things,
and there are some nice people and there are some average people,
and there are some mean people, with some on the far extremes,
etc.  The truth is markedly different than that, in that because
sin exists there are (1) no good people, and (2) all people are
blind to the spirit nature of our existence because they are
spiritually dead, which means the evil spirits which run this
world through sin, are able to enter into, encourage, influence,
exert feelings into, insert thoughts into, etc., the people of
this world.  People themselves become the vehicles of these
evil spirits and they don't even realize it.

Why is there addiction?  Evil spirits.  Why is it once you
start down some road of evil it gets easier and easier to do
more evil?  Evil spirits.  They entice people to do sinful
things, and once those people do them those evil spirits have
a "legal license" to enter into that person where they begin
to influence them more and more.  In scripture, we read about
a woman named Mary from whom seven evil spirits were driven.
It's possible she was the woman who was caught in the very
act of adultery, brought before Jesus to try to trap Him in
asking Him, "This woman was caught in the very act of
adultery, what should we do with her?"  If true, it only
took seven evil spirits to convince someone that the best
thing they could be doing in life right now was to commit
adultery, something that was, at that time under the Mosaic
Law, a stoning offense.

Evil spirits do nothing but harm.  And they have no redeeming
qualities or traits.  And they are rampant in this world.
Every place you see behavior which does not align with God's
commands unto us, it is sin, and that sin comes from our fallen
state, and our utter helplessness against those evil spirits
which come and deceive us into believing and doing all manner
of falseness.

As a Christian, and one with spiritual discernment, I am
aware of the presence of these spirits in/on/around people.
And it is that spirit to which I move away.  It's why I am
working so hard to create my own products from the ground
up.  The products that exist with GNU carry that spirit
because of Stallman, and many of the other people in GNU.
The Linux kernel and those things allowed into it carry
that spirit because of Linus Torvalds being so vulgar and
obscene in his behavior.  Apple is entirely wrought in
that spirit, as is demonstrated by the total money-based
success they've had in this world -- something that does
not happen to God-seeking entities, but only Satan-seeking
ones (I mean think about it, their logo is a fruit with a
bite out of it, and it used to be rainbow color, the symbol
God used after the flood in the rainbow to indicate He
would never again destroy the Earth by water).

Satan's greatest asset has been that his existence is kept
a secret from those who are not believers.  Because of that,
people don't know they're fighting a war, not just a battle.
And because they don't know they're in a life-or-death
struggle, they just proceed blindly through life following
whatever their belly wants, never listening to a word of
truth because any time that word of truth is spoken, there
are the evil spirits exerting evil influence upon the people
so that when the words are truth of spoken, a person will
feel revulsion, or anger, or hate, or whatever it is for
each person that will keep them away from the one thing that
would set them free from their upcoming eternal fate in Hell.

It breaks my heart to see it happening because it is so
pervasive.  Jesus sets people free, but so very few people
hear Him, and come to Him, and come out from the deception.

It breaks my heart.

Best regards,
Rick C. Hodgin

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

#70302

On Fri, 11 Sep 2015 19:11:45 -0700 (PDT)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> On Friday, September 11, 2015 at 9:42:29 PM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > > Ian Collins wrote:
> > >> I've suggested this before and I'm sure this
> > >> won't be the last time: why don't you just use
> > >> C++? It already has or can emulate most of
> > >> what you are looking to do.
> > > First of all, no it won't.
> > > Second of all, Bjarne Stroustrup.
> > 
> > Eh?  Do you reject everything created by someone you dislike?
> 
> It's not a matter of disliking them.  It is a matter of the spirit
> they operate under.  As I've said before, Bjarne Stroustrup is one
> of the most arrogant people I've ever met in software.  That does
> not come from nothing.  It comes from the presence of evil spirits
> who inhabit and/or surround him.

Very old Christian argument to discredit competition....

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

#70303

On Friday, September 11, 2015 at 10:27:52 PM UTC-4, Melzzzzz wrote:
> On Fri, 11 Sep 2015 19:11:45 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > On Friday, September 11, 2015 at 9:42:29 PM UTC-4, Ian Collins wrote:
> > > Rick C. Hodgin wrote:
> > > > Ian Collins wrote:
> > > >> I've suggested this before and I'm sure this
> > > >> won't be the last time: why don't you just use
> > > >> C++? It already has or can emulate most of
> > > >> what you are looking to do.
> > > > First of all, no it won't.
> > > > Second of all, Bjarne Stroustrup.
> > > 
> > > Eh?  Do you reject everything created by someone you dislike?
> > 
> > It's not a matter of disliking them.  It is a matter of the spirit
> > they operate under.  As I've said before, Bjarne Stroustrup is one
> > of the most arrogant people I've ever met in software.  That does
> > not come from nothing.  It comes from the presence of evil spirits
> > who inhabit and/or surround him.
> 
> Very old Christian argument to discredit competition....

It's not to discredit competition.  It is to speak the truth about
the nature of the battle we are facing in this world.  God commands
us to go forth and teach all nations.  It is that which we do, but
because of the nature of sin (death), people cannot hear the truth
no matter how clearly we speak it.  It requires them being willing
to hear the truth, and that is a supernatural act of God that takes
place, something He knows about people, that enables them.

And for the rest, the day will come for them as well, for all people,
where these things we Christians have talked about, things that God
Himself has given us through information found in scripture, and
through direct knowledge given us through the born again nature and
the discernment that spirit gives (able to discern spiritual things
in the same way the eye can discern light, or the ears can discern
sound), that every person, once stripped of this sinful flesh, then
standing before God, they too will know the truth, and they will
look back upon their life and see every point and time when someone
like me came forward and spoke the truth as best we're able, and
how it was not received because of sin, sin's influence upon a
person's thinking, beliefs, everything, and the influence of evil
spirits which then pile on top of that sin nature all manner of
falseness and alternate ideas which, to the person dead in sin,
seem to be so true and right because they appeal to the reasoning
mind, the flesh, but not are at war against the spirit.

It will be a day of weeping and gnashing of teeth.  It is called
the great and terrible day of the Lord.  Judgement Day.  And it
is coming for all people unless they repent.  And it's why the
non-believers in this world will soon round up people like me
and put them in prison, and execute them, rather than listening
to these words we speak because we testify of the truth, and the
people in this world who are dead in sin want nothing to do with
the truth because the truth testifies against everything they are
pursuing with their lives.

Christians will be killed for teaching them about the way to be
saved, the way to have real love inside, the kind of love that is
of life eternal given us through forgiveness of sin, by Jesus and
His sacrifice on the cross.  The words we speak will be sufficient
reason for people to round us up and kill us in heinous ways
because the truth is that powerful, and there is no way to battle
against it.  All evil can do against truth is attempt to silence
it, for there is no victory against it ever.  Truth owns everything
it encounters, because it is of God, for God Himself is truth, and
life, and power, and glory, and His Kingdom endures forever.

It is a real battle taking place in this world.  And those who are
not asking forgiveness from Jesus Christ are on the WRONG SIDE of
that battle, and will pay for it with their ETERNAL LIFE IN HELL.

Best regards,
Rick C. Hodgin

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

#70306

On 09/11/2015 10:27 PM, Melzzzzz wrote:
> On Fri, 11 Sep 2015 19:11:45 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
...
>> they operate under.  As I've said before, Bjarne Stroustrup is one
>> of the most arrogant people I've ever met in software.  That does
>> not come from nothing.  It comes from the presence of evil spirits
>> who inhabit and/or surround him.
> 
> Very old Christian argument to discredit competition....

To be entirely fair, Christians have no monopoly on the use of "evil
spirits" to discredit people.
-- 
James Kuyper

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

#70330

On 12/09/2015 04:01, James Kuyper wrote:
> On 09/11/2015 10:27 PM, Melzzzzz wrote:
>>  On Fri, 11 Sep 2015 19:11:45 -0700 (PDT)
>>  "Rick C. Hodgin"<rick.c.hodgin@gmail.com>  wrote:
> ...
>>>  they operate under.  As I've said before, Bjarne Stroustrup is one
>>>  of the most arrogant people I've ever met in software.  That does
>>>  not come from nothing.  It comes from the presence of evil spirits
>>>  who inhabit and/or surround him.
>>
>>  Very old Christian argument to discredit competition....
>
> To be entirely fair, Christians have no monopoly on the use of "evil
> spirits" to discredit people.

To be even fairer, Christians are required by the tenets of their faith 
not to judge others. They might reasonably criticise a person's 
behaviour, but not their personality. It is reasonable for a Christian 
to say "this man has behaved arrogantly", but not to say "this man is 
arrogant". Rick's claim is not in keeping with Matthew 7:1.

Rick - your zeal is commendable but your abuse of this newsgroup is not. 
If you wish to preach poor theology to people, you really need to find a 
better place to do it. Here, people are not impressed by sloppy thinking 
and off-topic ranting.

(Pace, Keith, I'm leaving it there.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#70339

On Saturday, September 12, 2015 at 6:12:48 AM UTC-4, Richard Heathfield wrote:
> On 12/09/2015 04:01, James Kuyper wrote:
> > On 09/11/2015 10:27 PM, Melzzzzz wrote:
> >>  On Fri, 11 Sep 2015 19:11:45 -0700 (PDT)
> >>  "Rick C. Hodgin"<rick.c.hodgin@gmail.com>  wrote:
> > ...
> >>>  they operate under.  As I've said before, Bjarne Stroustrup is one
> >>>  of the most arrogant people I've ever met in software.  That does
> >>>  not come from nothing.  It comes from the presence of evil spirits
> >>>  who inhabit and/or surround him.
> >>
> >>  Very old Christian argument to discredit competition....
> >
> > To be entirely fair, Christians have no monopoly on the use of "evil
> > spirits" to discredit people.
> 
> To be even fairer, Christians are required by the tenets of their faith 
> not to judge others. They might reasonably criticise a person's 
> behaviour, but not their personality. It is reasonable for a Christian 
> to say "this man has behaved arrogantly", but not to say "this man is 
> arrogant". Rick's claim is not in keeping with Matthew 7:1.

Does your knowledge of theology consist of single passages?  Or did you
read the whole book to obtain the full message of what Jesus Christ/the
Holy Spirit are teaching?

PEOPLE ARE GOING TO ENTER INTO HELL FOREVER, RICHARD.  DO YOU GET THAT?
THEY WILL NEVER COME BACK FROM THAT END, AND THEY HAVE ONE CHANCE TO
AVOID IT, ONE NAME HAS BEEN GIVEN UNTO MANKIND THROUGH WHICH WE MUST,
I REPEAT MUST, BE SAVED.  JESUS CHRIST IS THAT MAN, AND HE IS THE DOOR.
HE IS THE GATEWAY.  HE IS THE ONLY PATH WE HAVE TO BE REDEEMED.

And you would have me be silent?  Whose voice are you speaking with,
Mr. Heathfield?

> Rick - your zeal is commendable but your abuse of this newsgroup is not.

Is it really your thinking, Mr. Heathfield, that someday when I stand
before Jesus Christ He will say to me, "Rick, I appreciate your zeal,
but you really should've respected the rules of the usenet newsgroup
comp.lang.c, and spent less time teaching about me, and more time
teaching about C" ??

You are totally deceived, Richard, totally deceived, if you believe
for one moment that we have to isolate our walk with Jesus Christ
from the other things we do in our life.  That is a teaching from
Satan, and one which leads to this world of hate we have around us.

Men are NOT holding on to God in ALL areas of their lives, so that
in ALL of those areas to which they DO NOT hold on to God, Satan is
able to come in unabashed and work his harm, to steal, kill, destroy.

It is a direct teaching from the enemy's mouth that we must divide
our allegiances and attentions into that part of us which relates to
faith over here, and that part of us which relates to other things
over there, or to obey rules of men which would silence the
continuous baptism (Matthew 28:19) of the Father, Son, and Holy
Spirit.

Truth is not divided.  And man is not so divided by his created
nature, but only by his sin nature, for Satan and falseness are
divided.  They speak with many voices.  But the truth stands always
alone, speaking always with one voice.

"How old are you, Rick?"  There is ONE right answer to that
question, and many false answers.

"What is the way to enter into Heaven?"  There is ONE right answer
to that question, and many false answers.  And you, Mr. Heathfield,
are believing in and teaching the false answers.

> If you wish to preach poor theology to people, you really need to find a 
> better place to do it. Here, people are not impressed by sloppy thinking 
> and off-topic ranting.
> 
> (Pace, Keith, I'm leaving it there.)

We shall see, Mr. Heathfield.  My prayer for you would be that you come
to know the Lord Jesus Christ as your personal savior, and that you be
born again of the spirit, following after God with the fullness of your
heart, mind, body, soul, and spirit.

Best regards,
Rick C. Hodgin

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

#70342

On 12/09/2015 13:55, Rick C. Hodgin wrote:

> Does your knowledge of theology consist of single passages?

No.

> Or did you
> read the whole book to obtain the full message of what Jesus Christ/the
> Holy Spirit are teaching?

Yes.

> And you would have me be silent?

Certainly not! But preaching here is inappropriate for the same reason 
that giving a lecture on recursive descent parsers is inappropriate in 
your church.

> Whose voice are you speaking with, Mr. Heathfield?

My own. And when you preach bad theology in inappropriate places, you 
are speaking not with God's voice but your own. So please take the 
holier-than-thou somewhere where it's on topic.

<Poor theology snipped>

>>  (Pace, Keith, I'm leaving it there.)

Oops.

> We shall see, Mr. Heathfield.  My prayer for you would be that you come
> to know the Lord Jesus Christ as your personal savior, and that you be
> born again of the spirit, following after God with the fullness of your
> heart, mind, body, soul, and spirit.

You seem to think that anyone who disagrees with you must, by 
definition, be a non-Christian. It doesn't work like that. When you 
abuse social resources like this one, you are not representing Jesus 
Christ, and it is fraudulent to pretend otherwise. It is also 
inappropriate to call Christians non-Christians just because they don't 
agree with your preaching in inappropriate places.

If you were to go into a supermarket and preach there, you'd be thrown out.
If you were to go into a courthouse and preach there, you'd be thrown 
out (or arrested).
If you were to go into a theatre and preach there, you'd be thrown out.
If you were to go into a restaurant and preach there, you'd be thrown out.

And rightly so, in all four of those cases. The only reason you're 
preaching here is that you know you can't be thrown out, but it's just 
as inappropriate here as it is in a supermarket, a courthouse, a 
theatre, or a restaurant.

This is a newsgroup that discusses the C programming language. You, like 
all of us, are welcome to join in such discussions. But none of us has 
the right to preach here. Not me, not you, not anyone. It is true that 
nobody can stop you from doing this wrong thing, but that doesn't make 
it right.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#70344

On Saturday, September 12, 2015 at 9:17:09 AM UTC-4, Richard Heathfield wrote:
> So please take the 
> holier-than-thou somewhere where it's on topic.

Your colors are flying high for all to see, Richard.  I advise you:
repent.

Best regards,
Rick C. Hodgin

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

#70360

On Saturday, September 12, 2015 at 2:24:33 PM UTC+1, Rick C. Hodgin wrote:
> On Saturday, September 12, 2015 at 9:17:09 AM UTC-4, Richard 
> Heathfield wrote:
>
> > So please take the 
> > holier-than-thou somewhere where it's on topic.
> 
> Your colors are flying high for all to see, Richard.  I advise 
> you:repent.
> 
Richard Heathfield is an extremely committed Christian.
I'm also a committed Christian who attends church every Sunday
and has authored books on Christian subjects.

We're from very different denominations and Christian
traditions (these divisions, bequeathed us by our ancestors, 
are extremely sad). But we both agree that what you are doing
is inappropriate and counter-productive. Please listen.

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

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

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

csiph-web