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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#70363

W dniu sobota, 12 września 2015 19:58:07 UTC+2 użytkownik Malcolm McLean napisał:
> 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.

I not quite agree.. The things how those words of RHodgin are received depend imo  on attitude some build towards it - 

thus imo if someone is criticisizing it 
it is on ethe basis of the ttitude someone builded to it not 'stright'

I feel personally rtcher positive to this
words, except if RHodgin directs it stright to me (then i feel bothered
to waste my time on answer directed ot me)
but otherwise i thing if good attitude would be builded those words my gave some potential spitiyual benefit, why no..

(my attidude toward christianity is 
mostly ok, i even somewgat feel often like a saint (this comes just from the thing i feel i just see a bit better than average what is better and what is worse (i may be not perfect but on average i think i see it slightly better really)

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

#70368

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

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

Well said.

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

#70374

In article <87oah7qyk5.fsf@gmail.com>, Gareth Owen  <gwowen@gmail.com> wrote:
>Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> 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.
>
>Well said.

Of course.

But it boils down to this:  If we didn't want to keep reading RCH's
nonsense, then we would just stop responding to him.  This "freezing out"
technique works pretty well, as long as everybody cooperates.

But the fact is that this newsrgroup would be pretty much dead without
RCH's postings to lighten things up, and I'm pretty sure that most of the
posters here recognize that fact (loath as they would be to ever admit it).
So, we keep responding, he keeps bloviating, and life goes on...

-- 
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

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

#70372

On Saturday, September 12, 2015 at 1:58:07 PM UTC-4, Malcolm McLean wrote:
> 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.

Am I washed in the blood of the Lamb?  Has He paid the price of
sin for me?  Has He given me the new birth, the born again nature
that has fundamentally changed me from within, a complete and total
re-wiring of every circuit, every synapse, every thought, every
feeling?  Has He come into my heart and made His permanent
residence with me?  Has He become the focus of my life, that it is
no longer I live, but Christ within me?

If so, then I will speak of Him, because there are others who will
come, who are not here yet, who have not yet been washed in the
blood of the Lamb, but who will be called, and who will respond to
His call, before the great and mighty day of His return.

The Lord Jesus Christ has washed me by His own blood.  He has made
me whiter than snow before God the Father.  I was bought at a price,
and my life is not my own.  I do merely speak of these things that
I do speak about, but I also live them.  I am constantly examining
my life to see where I fall short, and the sheer tonnage of where
I fall short brings me to weeping before my Lord and Savior, and He
pours out upon me repentance, and guidance for my life.  And I
believe, and because I believe I walk, and where I walk I speak,
and the words I speak are His words first given unto me, that I may
also speak them to others so that they too would know who this
Great and Mighty Savior is ... the man Jesus Christ.

Best regards,
Rick C. Hodgin

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

#70385

On Saturday, September 12, 2015 at 2:07:01 PM UTC-5, Rick C. Hodgin wrote:
> If so, then I will speak of Him, because there are others who will
> come, who are not here yet, who have not yet been washed in the
> blood of the Lamb, but who will be called, and who will respond to
> His call, before the great and mighty day of His return.

I believe I have come to know the Holy Spirit better than most people, and
would eagerly speak to those whom I would expect to listen with interest,
but I also recognize that speaking excessively to those who are not ready to
hear will harden their hearts and close their ears, and delay rather than
hasten the day when they are able to receive God's word.

While I do not doubt the sincerity of you or many others who seek to inject
God's word into all that they do, and while I would recognize your actions as
being consistent with some of the parables about scattering much seed in the
hopes that some will take root, I would suggest that burying even the most
fertile ground an inch deep with even the best seeds is apt to yield a yield
far below what could be obtained by a scattering of mediocre seeds on mediocre
ground.

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

#70395

On Saturday, September 12, 2015 at 5:25:08 PM UTC-4, supe...@casperkitty.com wrote:
> On Saturday, September 12, 2015 at 2:07:01 PM UTC-5, Rick C. Hodgin wrote:
> > If so, then I will speak of Him, because there are others who will
> > come, who are not here yet, who have not yet been washed in the
> > blood of the Lamb, but who will be called, and who will respond to
> > His call, before the great and mighty day of His return.
> 
> I believe I have come to know the Holy Spirit better than most people, and
> would eagerly speak to those whom I would expect to listen with interest,
> but I also recognize that speaking excessively to those who are not ready to
> hear will harden their hearts and close their ears, and delay rather than
> hasten the day when they are able to receive God's word.
> 
> While I do not doubt the sincerity of you or many others who seek to inject
> God's word into all that they do, and while I would recognize your actions as
> being consistent with some of the parables about scattering much seed in the
> hopes that some will take root, I would suggest that burying even the most
> fertile ground an inch deep with even the best seeds is apt to yield a yield
> far below what could be obtained by a scattering of mediocre seeds on mediocre
> ground.

If you'd like to hear it, I have an interesting testimony about how I
came to this question I now ask you:

     What should we be doing when we are not going full throttle
     for the Lord?  What activity should we introduce which is
     more worthwhile than doing all we do throughout our normal
     days for Him, sprinkling continuously all of our work with
     His presence, and therefore His teachings?

Best regards,
Rick C. Hodgin

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

#70305

Rick C. Hodgin 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.

Well that wasn't the impression I get when we met.  Anyway, the 
evolution of C++, like C is managed by a committee not one man.

-- 
Ian Collins

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

#70308

On Friday, September 11, 2015 at 10:54:21 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin 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.
> 
> Well that wasn't the impression I get when we met.

Are you a Christian?  Are you born again?  Do you have spiritual
discernment?

Evil spirits are not evil toward each other, nor those they are
guiding toward destruction.  So long as people are operating against
God, in the world, toward their destruction, there is this great
call of smoothness, and "love is love", and how the new Pope is
such a great guy that he's calling for a unification of religions
that have been at war for so long... and so on and so on and so
on.

The Bible says it this way:

    http://biblehub.com/kjv/romans/1.htm
    28 And even as they did not like to retain God in their knowledge,
       God gave them over to a reprobate mind, to do those things which
       are not convenient;
    29 Being filled with all unrighteousness, fornication, wickedness,
       covetousness, maliciousness; full of envy, murder, debate, deceit,
       malignity; whisperers,
    30 Backbiters, haters of God, despiteful, proud, boasters, inventors
       of evil things, disobedient to parents,
   31 Without understanding, covenant breakers, without natural affection,
      implacable, unmerciful:
   32 Who knowing the judgment of God, that they which commit such things
      are worthy of death, not only do the same, but have pleasure in them
      that do them.

"But have pleasure in them that do them."  The people in this world who
are perishing are all going down together in a happy fest of self-
involved aspirations of false unity and false love, coupled to all manner
of other falseness.  The world calls people toward a particular end, the
end of which is death, and everyone who is not born again will be
deceived and go down to that end, to their destruction in Hell.  It is
why I reach out to try to teach people this end.  But there are no
people who can hear it except for those who are willing to hear the
truth, and that is a miracle of God taking place inside a person to
know if they will, and then to draw them to it, so they will then
know it.

> Anyway, the 
> evolution of C++, like C is managed by a committee not one man.

So is GNU.  But Stallman started it.  It descended from him.  And
that spirit is not isolated to Stallman, or to Stroustrup, and all
those who receive it with open arms, because they embrace that same
spirit that is at war against truth, the one which is leading
Stallman to his destruction, and Stroustrup to his.  And everyone
else who is not born again to theirs.

People do not realize the pervasiveness of this spirit.  And
because it is so pervasive, when men and women stand up the way
I do and speak about Jesus Christ, we are the ones being called
names.  We are the ones being called judgmental and mean, unkind
and unloving, and so much more, when it is God Himself who has
set aside a day of Judgement (with a capital "J"), and we are
here as messengers sent ahead to warn people of that end so that
people can know in advance, turn from their sin, and bypass
judgement entering instead into life.

Ours is the voice you need to hear.  Ours is the warning you
need to heed, because it is the warning from God given unto man
so that people might be saved.  Those who are saved by God will
speak and teach as He has commanded, so that others will hear
these things, and those who have an ear to hear them will hear
them, and come out from the deception, acknowledging their sin,
asking forgiveness, and being saved.

Jesus makes all things possible.  And I don't know what He saw
in me to draw me to Himself and set me on this path ... but here
I am.  I love Him, and I speak His words as best I'm able.

Best regards,
Rick C. Hodgin

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

#70311

Rick C. Hodgin wrote:
> On Friday, September 11, 2015 at 10:54:21 PM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin 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.
>>
>> Well that wasn't the impression I get when we met.
>
> Are you a Christian?  Are you born again?  Do you have spiritual
> discernment?
>
> Evil spirits are not evil toward each other, nor those they are
> guiding toward destruction.

And you talk of others as being arrogant!

Do not presume to judge those you do not know.  A great many of us 
choose to help others not through an obligation to some deity but 
because it is the decent thing to do.  Christians do not have a monopoly 
over decency just as non-Christians do not have a monopoly over indecency.

There, someone has finally goaded me into replying to a religious post. 
  I'll try harder next time.

-- 
Ian Collins

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

#70335

On Saturday, September 12, 2015 at 12:21:00 AM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Friday, September 11, 2015 at 10:54:21 PM UTC-4, Ian Collins wrote:
> >> Rick C. Hodgin 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.
> >>
> >> Well that wasn't the impression I get when we met.
> >
> > Are you a Christian?  Are you born again?  Do you have spiritual
> > discernment?
> >
> > Evil spirits are not evil toward each other, nor those they are
> > guiding toward destruction.
> 
> And you talk of others as being arrogant!
> 
> Do not presume to judge those you do not know.  A great many of us 
> choose to help others not through an obligation to some deity but 
> because it is the decent thing to do.  Christians do not have a monopoly 
> over decency just as non-Christians do not have a monopoly over indecency.

Hell is going to be filled with people who did both good and bad things.
Heaven is going to be filled with people who did both good and bad
things.  Hell is going to be filled with sinners who did not repent,
nor ask forgiveness from Jesus Christ.  Heaven is going to be filled
with sinners who did repent, and who asked forgiveness from Jesus
Christ.

Jesus is the key to where we wind up after we die.  Not our behavior.
Not our good deeds or merits.  Not even our sin.  Jesus forgives the
murderer the same as He forgives the adulterer the same as He forgives
the liar or the thief.

> There, someone has finally goaded me into replying to a religious post. 
>   I'll try harder next time.
> 
> -- 
> Ian Collins

Our lives are a precious gift.  Sin has torn into that gift and
ripped it to shreds.  Jesus comes to restore all things, to make
all things new, to undo the damage done by sin, and by the enemy
of God (and the enemy of us) through sin.

Jesus is our Redeemer.  Our Savior.  He is the ONLY way, and He is
THE truth, and THE life.  It's why I teach about Him.  We all need
Him because He takes our sin away, which restores all things.

Best regards,
Rick C. Hodgin

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

#70384

> "Ian Collins"  wrote in message news:d5hnh3FcgmvU5@mid.individual.net...

> > Rick C. Hodgin wrote:
[...]
> > Are you a Christian?  Are you born again?  Do you have spiritual
> > discernment?
> >
> > Evil spirits are not evil toward each other, nor those they are
> > guiding toward destruction.

> And you talk of others as being arrogant!

For some strange reason, sometimes I want to trust Merlin and Archimedes 
from the
following Disney movie over a hard core God that just might kill your as% in 
a heart beat for
not being perfect:

https://www.youtube.com/watch?v=J5cO_KBY60c

;^) 

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

#70301

On Sat, 12 Sep 2015 13:42:15 +1200
Ian Collins <ian-news@hotmail.com> 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?
> 

Seems so. But he will get ideas and do same anyway...

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

#70326

On 12/09/2015 02:02, Ian Collins wrote:
> 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.
>

And then what? It might be necessary to do some actual work!

Devising new things is more fun and more satisfying.

-- 
Bartc

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

#70087

On Wednesday, September 9, 2015 at 6:07:15 PM UTC-5, Rick C. Hodgin wrote:
> There are definitely workable solutions to allow allocation and
> de-allocation.  However, I still think the purpose of lalloc() would
> be in its speed and no requirement of cleanup after use.
> 
>     // char* ptr = lalloc(20);
>     mov ptr,esp
>     sub esp,20
> 
> Two assembly instructions is all that's required to get the memory
> allocated.  Compare that to the overhead of a function call to
> the stalloc() function, and then later a stfree() function, let
> alone the processing involved in walking the local heap to see
> where suitable blocks are.

  // stfree(ptr,20)
  mov esp,ptr
  add esp,20

A compiler could easily elide that immediately preceding a "mov esp,ebp" at
the end of a function, though it should be noted that using that style of
lalloc() would require that a compiler maintain a frame pointer if it has
any local variables at stack-relative addresses, making lalloc() not quite
so cheap as you suggest.

> I agree we need a stalloc() and stfree() though.  But, I think they
> should be in addition to lalloc() which may need to be renamed
> fastalloc() to convey its purpose.

My complaint about a lalloc() that doesn't require a call to a "freeing"
function is that not all platforms would be able to support it without making
breaking changes to the ABI of things like setjmp/longjmp [with the stalloc
and stfree as I've suggested, code which uses setjmp would need to do a
stalloc(0) beforehand and a corresponding stfree() to avoid a memory leak
if a longjmp() might be performed between an intermediate layer's stalloc()
and stfree(), but code which doesn't need to support such semantics would not
need to be modified.

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

#70094

On Wednesday, September 9, 2015 at 7:24:49 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, September 9, 2015 at 6:07:15 PM UTC-5, Rick C. Hodgin wrote:
> > There are definitely workable solutions to allow allocation and
> > de-allocation.  However, I still think the purpose of lalloc() would
> > be in its speed and no requirement of cleanup after use.
> > 
> >     // char* ptr = lalloc(20);
> >     mov ptr,esp
> >     sub esp,20
> > 
> > Two assembly instructions is all that's required to get the memory
> > allocated.  Compare that to the overhead of a function call to
> > the stalloc() function, and then later a stfree() function, let
> > alone the processing involved in walking the local heap to see
> > where suitable blocks are.
> 
>   // stfree(ptr,20)
>   mov esp,ptr
>   add esp,20
> 
> A compiler could easily elide that immediately preceding a "mov esp,ebp" at
> the end of a function, though it should be noted that using that style of
> lalloc() would require that a compiler maintain a frame pointer if it has
> any local variables at stack-relative addresses, making lalloc() not quite
> so cheap as you suggest.

How are you accessing local variables and parameters after this stalloc()
allocation without a stack frame? The compiler could theoretically adjust
the offset to each local variable and input parameter based on use, but
that would only work for a known traversal through logic blocks, and it
would not work based on allocation across conditionals.

> > I agree we need a stalloc() and stfree() though.  But, I think they
> > should be in addition to lalloc() which may need to be renamed
> > fastalloc() to convey its purpose.
> 
> My complaint about a lalloc() that doesn't require a call to a "freeing"
> function is that not all platforms would be able to support it without making
> breaking changes to the ABI of things like setjmp/longjmp [with the stalloc
> and stfree as I've suggested, code which uses setjmp would need to do a
> stalloc(0) beforehand and a corresponding stfree() to avoid a memory leak
> if a longjmp() might be performed between an intermediate layer's stalloc()
> and stfree(), but code which doesn't need to support such semantics would not
> need to be modified.

The compiler could be setup to enforce a policy of freeing each lalloc()
before exit, but I don't see the point. :-)  The purpose of lalloc() is
to grab some memory, a type of dynamic local variable basically, one
which, once allocated, persists until the function call returns, just as
the normal statically allocated variables do, but it is only in use if
needed.

To me, lalloc() seems to be an absolutely essential requirement in
data processing, one of the true fundamental abilities which should
exist in a near-machine-level programming language.

Best regards,
Rick C. Hodgin

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

#70097

On Wednesday, September 9, 2015 at 6:38:13 PM UTC-5, Rick C. Hodgin wrote:
> How are you accessing local variables and parameters after this stalloc()
> allocation without a stack frame? The compiler could theoretically adjust
> the offset to each local variable and input parameter based on use, but
> that would only work for a known traversal through logic blocks, and it
> would not work based on allocation across conditionals.

I was suggesting that if a compiler implemented "stalloc()" the way you
implemented "lalloc", the corresponding "stfree()" function would be just
as fast and wouldn't require traversing any sort of data structure, though
I'd personally probably rather have something that was a bit more robust
and wouldn't risk bombing the stack; a robust implementation in a multi-
threaded environment would require some sort of thread-local storage, but
the design of the optimal implementation would depend upon the environment
in question.

>>
> To me, lalloc() seems to be an absolutely essential requirement in
> data processing, one of the true fundamental abilities which should
> exist in a near-machine-level programming language.
<<

Suppose you need to process some data which has records each of which is
preceded by a size word.  To my mind, a good pattern would be:

    do
    {
      if (!fread(file, sizeof len, 1, &len)) break;
      if (!len) break;
      ptr = stalloc(len);     
      fread(file, 1, len, ptr);
      process_data(ptr, len);
      stfree(ptr, size);
    } while(1);

How would you write the code without either using "stfree()", a fixed-size buffer, or malloc()/calloc()?

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

#70099

On Wednesday, September 9, 2015 at 8:01:24 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, September 9, 2015 at 6:38:13 PM UTC-5, Rick C. Hodgin wrote:
> > How are you accessing local variables and parameters after this stalloc()
> > allocation without a stack frame? The compiler could theoretically adjust
> > the offset to each local variable and input parameter based on use, but
> > that would only work for a known traversal through logic blocks, and it
> > would not work based on allocation across conditionals.
> 
> I was suggesting that if a compiler implemented "stalloc()" the way you
> implemented "lalloc", the corresponding "stfree()" function would be just
> as fast and wouldn't require traversing any sort of data structure, though
> I'd personally probably rather have something that was a bit more robust
> and wouldn't risk bombing the stack; a robust implementation in a multi-
> threaded environment would require some sort of thread-local storage, but
> the design of the optimal implementation would depend upon the environment
> in question.
> 
> >>
> > To me, lalloc() seems to be an absolutely essential requirement in
> > data processing, one of the true fundamental abilities which should
> > exist in a near-machine-level programming language.
> <<
> 
> Suppose you need to process some data which has records each of which is
> preceded by a size word.  To my mind, a good pattern would be:
> 
>     do
>     {
>       if (!fread(file, sizeof len, 1, &len)) break;
>       if (!len) break;
>       ptr = stalloc(len);     
>       fread(file, 1, len, ptr);
>       process_data(ptr, len);
>       stfree(ptr, size);
>     } while(1);
> 
> How would you write the code without either using "stfree()", a
> fixed-size buffer, or malloc()/calloc()?

I can see two solutions I would use.  The first would be an initial
allocation based on a "good guess" as to how much maximum space I
would need.  I would then compare the size of each requested block
and increase the size of my original allocation once it gets larger.

The other solution would be the one I would actually use.  For it,
I created what I call a "builder" for support of my VJr language,
one which allocates an initial buffer and then has the ability to
grow up as is necessary with realloc().

You can see it here:

    https://github.com/RickCHodgin/libsf/blob/master/utils/common/cpp/builder.h
    https://github.com/RickCHodgin/libsf/blob/master/utils/common/cpp/builder.cpp

In that case, I would allocate a buffer of my first good guess, and
then just ensure it's the right size each time and re-load from the
beginning.  Such a solution for a repeated set of data processing
would allow that data to be in the highest speed/level cache, and
it would only require the prologue overhead, and the epilogue
overhead.

Best regards,
Rick C. Hodgin

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

#70104

> "Rick C. Hodgin"  wrote in message 
> news:4fcedb5a-a31c-4012-ae7a-611338129c07@googlegroups.com...

> > On Wednesday, September 9, 2015 at 8:01:24 PM UTC-4, 
> > supe...@casperkitty.com wrote:
[...]
> > How would you write the code without either using "stfree()", a
> > fixed-size buffer, or malloc()/calloc()?

> I can see two solutions I would use.  The first would be an initial
> allocation based on a "good guess"
[...]

That basically violates the rules, right? 

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

#70109

On Wednesday, September 9, 2015 at 8:46:37 PM UTC-4, Chris M. Thomasson wrote:
> > "Rick C. Hodgin"  wrote in message 
> > news:4fcedb5a-a31c-4012-ae7a-611338129c07@googlegroups.com...
> 
> > > On Wednesday, September 9, 2015 at 8:01:24 PM UTC-4, 
> > > supe...@casperkitty.com wrote:
> [...]
> > > How would you write the code without either using "stfree()", a
> > > fixed-size buffer, or malloc()/calloc()?
> 
> > I can see two solutions I would use.  The first would be an initial
> > allocation based on a "good guess"
> 
> That basically violates the rules, right?

I suppose it does from the strict stack allocation requirement.  That's
not where I would use that type of ability though (personal programming
style).

Best regards,
Rick C. Hodgin

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

#70146

On 10/09/2015 01:01, supercat@casperkitty.com wrote:

> Suppose you need to process some data which has records each of which is
> preceded by a size word.  To my mind, a good pattern would be:
>
>      do
>      {
>        if (!fread(file, sizeof len, 1, &len)) break;
>        if (!len) break;
>        ptr = stalloc(len);
>        fread(file, 1, len, ptr);
>        process_data(ptr, len);
>        stfree(ptr, size);
>      } while(1);
>
> How would you write the code without either using "stfree()", a fixed-size buffer, or malloc()/calloc()?
>

stalloc and stfree allocate and deallocate from the stack? (I haven't 
followed the thread.)

In general, this is not going to work if someone does:

   A=stalloc(m);
   B=stalloc(n);
   stfree(A,m);
   stfree(B,n);

So it needs more discipline and gives less freedom than using 
malloc/free. C people also won't like having to keep track of the size 
to give to stfree. (And if someone neglects to call stfree(), will the 
memory be recovered on the next function return?)

There's also a stack overflow vulnerability when a much larger than 
expected record has to be read. This can be solved with extra logic: 
using stalloc/stfree up to some limit N, and the heap (with failure 
checks) for larger records.

But then the same approach can be taken using a fixed size buffer (on 
the stack or the heap) for records up to size N; you don't need dynamic 
stack allocation.

(I can see it also being troublesome with code generators that like to 
use fixed offsets from the stack for variables. I assume stalloc/stfree 
manipulate the stack pointer. It would be interesting to sort out code 
like this too:

   fn(a1=stalloc(n1), a2=stalloc(n2));
   ....
   stfree(a1,n1); stfree(a2,n2);   // which order? or:

   fn(a=stalloc(g(b=stalloc(n));
)

-- 
Bartc

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

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

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

csiph-web