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

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

Learning C as an existing programmer

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

Contents

  Learning C as an existing programmer rammy <nospam@nospam.com> - 2012-06-24 21:52 +0000
    Re: Learning C as an existing programmer Ian Collins <ian-news@hotmail.com> - 2012-06-25 10:26 +1200
      Re: Learning C as an existing programmer "Charles Richmond" <numerist@aquaporin4.com> - 2012-06-24 18:28 -0500
        Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 01:05 -0600
        Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 01:10 -0600
          Re: Learning C as an existing programmer Weland <weland@faeroes.freeshell.org> - 2012-06-25 08:20 +0000
            Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-07-02 01:46 -0600
        Re: Learning C as an existing programmer Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-06-25 20:37 +0000
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 16:51 -0400
          Re: Learning C as an existing programmer Keith Thompson <kst-u@mib.org> - 2012-06-25 14:25 -0700
            Re: Learning C as an existing programmer Les Cargill <lcargill99@comcast.com> - 2012-06-25 17:50 -0500
            Re: Learning C as an existing programmer William Ahern <william@wilbur.25thandClement.com> - 2012-06-25 16:52 -0700
          Re: Learning C as an existing programmer Les Cargill <lcargill99@comcast.com> - 2012-06-25 17:49 -0500
          Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:09 -0700
      Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 00:55 -0600
      Re: Learning C as an existing programmer Nachy <mazwolfe@gmail.com> - 2012-06-25 13:26 -0700
        Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 17:07 -0400
        Re: Learning C as an existing programmer Nachy <mazwolfe@gmail.com> - 2012-06-25 14:56 -0700
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 18:29 -0400
          Re: Learning C as an existing programmer pete <pfiland@mindspring.com> - 2012-06-25 18:56 -0400
            Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:21 -0700
              Re: Learning C as an existing programmer Robert Wessel <robertwessel2@yahoo.com> - 2012-06-26 02:56 -0500
              Re: Learning C as an existing programmer Ike Naar <ike@sverige.freeshell.org> - 2012-06-26 08:10 +0000
          Re: Learning C as an existing programmer "J. J. Farrell" <jjf@bcs.org.uk> - 2012-06-26 07:06 +0100
        Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:18 -0700
          Re: Learning C as an existing programmer Keith Thompson <kst-u@mib.org> - 2012-06-26 00:23 -0700
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-26 06:47 -0400
    Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 01:21 +0100
    Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 00:54 -0600
    Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 09:19 +0200
      Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 11:15 +0100
        Re: Learning C as an existing programmer "Ronald Benedik" <Aon.912717285@aon.at> - 2012-06-25 12:30 +0200
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 11:43 +0100
            Re: Learning C as an existing programmer "Ronald Benedik" <Aon.912717285@aon.at> - 2012-06-25 12:55 +0200
        Re: Learning C as an existing programmer Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-25 10:38 +0000
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 13:05 +0100
        Re: Learning C as an existing programmer Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-06-25 10:56 +0000
        Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 13:34 +0200
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 12:43 +0100
            Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 15:16 +0200
              Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 14:39 +0100
                Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 11:07 +0200
                  Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-26 12:05 +0100
                    Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 14:28 +0200
              Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 14:39 +0100
      Re: Learning C as an existing programmer 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-25 18:21 -0700
        Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 11:03 +0200
    Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-25 00:50 -0700
      Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 11:50 +0100
        Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-25 04:32 -0700
          Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 14:25 +0100
            Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-26 02:38 -0700
              Re: Learning C as an existing programmer jacob navia <jacob@spamsink.net> - 2012-06-26 12:13 +0200
                Re: Learning C as an existing programmer jacob navia <jacob@spamsink.net> - 2012-06-26 12:15 +0200
                Re: Learning C as an existing programmer Ian Collins <ian-news@hotmail.com> - 2012-06-26 23:08 +1200
              Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-27 01:55 +0100
                Re: Learning C as an existing programmer 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-26 18:43 -0700
          Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:27 -0700
            Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-26 00:18 -0700
              Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 04:02 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 05:54 -0700
                Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 07:22 -0700
                  Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-28 04:28 -0700
                    Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 10:07 -0700
                      Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-02 08:57 -0700
                        Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-07-03 03:26 -0700
                          Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 16:28 -0700
                        Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 18:16 -0700
                          Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 04:51 -0700
                            Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-07 16:48 +0100
                              Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 09:07 -0700
                            Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 12:27 -0700
                Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-03 15:01 +0100
                  Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 16:13 -0700
                    Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-07 19:35 +0100
                      Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 11:52 -0700
                      Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 19:40 -0700
            Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-26 03:03 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 06:34 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 06:40 -0700
              Re: Learning C as an existing programmer Gareth Owen <gwowen@gmail.com> - 2012-06-27 07:16 +0100
                Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-27 06:48 -0400
              Re: Learning C as an existing programmer "io_x" <a@b.c.invalid> - 2012-06-28 09:18 +0200
                Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-28 02:02 -0700
                  Re: Learning C as an existing programmer "io_x" <a@b.c.invalid> - 2012-06-28 12:19 +0200
            Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-03 15:00 +0100
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 15:56 -0700
                Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 09:18 -0700
                  Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 11:56 -0700

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

#22789

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

>  Tim Rentsch:
>> gwowen <gwowen@gmail.com> writes:
>> 
>> What you mean is that VLAs have no portably guaranteed failure
>> mechanism.  On a particular implementation they may very well
>> have a well-defined, implementation-supplied, such mechanism.
>>
> And these days if you're writing C you're probably more likely to be
> writing components rather than complete programs. A component does
> know what to do on out of memory -sometimes relying on the OS to
> kill the process is the best you can do, sometimes its completely
> unacceptable.

Completely beside the point I was making, as using malloc() is
no different in this regard.

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

#22798

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>A component does
>
>   not?
>
>>>know what to do on out of memory
>>as using malloc() is no different in this regard.
>
>   When a library-grade function needs to allocate memory
>   and this fails, it knows what to do: Notify the caller
>   of the failure (usually via a status code).

You snipped too much context.  If a piece of code isn't
able to deal with an allocation failure, it doesn't matter
where the allocation falure came from.  If a piece of
code is able to deal with allocation failure in some way,
that applies equally to allocation failures for malloc()
and VLAs, assuming of course that VLA allocation failure
can be detected, which I pointed out upthread that it
can in a conforming implementation, if the implementation
so desires.  The ability or non-ability of some piece of
code to respond sensibly to allocation failure has no
bearing on the point I was making.

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

#22926

בתאריך יום שלישי, 26 ביוני 2012 15:22:35 UTC+1, מאת Tim Rentsch:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
> You snipped too much context.  If a piece of code isn't
> able to deal with an allocation failure, it doesn't matter
> where the allocation falure came from.  If a piece of
> code is able to deal with allocation failure in some way,
> that applies equally to allocation failures for malloc()
> and VLAs, assuming of course that VLA allocation failure
> can be detected, which I pointed out upthread that it
> can in a conforming implementation, if the implementation
> so desires.  The ability or non-ability of some piece of
> code to respond sensibly to allocation failure has no
> bearing on the point I was making.
>
We're talking about libraries.

I want to find the convex hull of a set of points. The algorithm I'm using needs a temporary buffer.

With malloc() we write

int convexhull(double *x, double *y, int N, double *xout, double *yout)
{
  void *ptr;
  int Nhullpoints;

  ptr = malloc(sizeof(double) * 2 * N);
  if(!ptr)
    return -1;
  Nhullpoints = dothegubbins(x, y, N, xout, yout, ptr); 
  return Nhullpoints;
}

with a vla it's a bit more difficult to provide a corresponding solution.

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

#22986

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

>  Tim Rentsch:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> 
>> You snipped too much context.  If a piece of code isn't
>> able to deal with an allocation failure, it doesn't matter
>> where the allocation falure came from.  If a piece of
>> code is able to deal with allocation failure in some way,
>> that applies equally to allocation failures for malloc()
>> and VLAs, assuming of course that VLA allocation failure
>> can be detected, which I pointed out upthread that it
>> can in a conforming implementation, if the implementation
>> so desires.  The ability or non-ability of some piece of
>> code to respond sensibly to allocation failure has no
>> bearing on the point I was making.
>>
> We're talking about libraries.
>
> I want to find the convex hull of a set of points. The algorithm I'm
> using needs a temporary buffer.  [snip example]
> with a vla it's a bit more difficult to provide a corresponding solution.

You're making basically the same point that you made upthread, to
which I already responded that it's beside the point I was making.
Did you not understand the point I was making?  Do you not
understand what it means for something to be beside the point?  Do
you think that repeating yourself is going to magically change
whether what you have to say is relevant?  The statement above
(the last one in the quoted excerpt) is true but also obvious
and irrelevant to what I was saying.  

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

#23079

בתאריך יום שישי, 29 ביוני 2012 18:07:29 UTC+1, מאת Tim Rentsch:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> >  Tim Rentsch:
> >> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >> 
> >> You snipped too much context.  If a piece of code isn't
> >> able to deal with an allocation failure, it doesn't matter
> >> where the allocation falure came from.  If a piece of
> >> code is able to deal with allocation failure in some way,
> >> that applies equally to allocation failures for malloc()
> >> and VLAs, assuming of course that VLA allocation failure
> >> can be detected, which I pointed out upthread that it
> >> can in a conforming implementation, if the implementation
> >> so desires.  The ability or non-ability of some piece of
> >> code to respond sensibly to allocation failure has no
> >> bearing on the point I was making.
> >>
> > We're talking about libraries.
> >
> > I want to find the convex hull of a set of points. The algorithm I'm
> > using needs a temporary buffer.  [snip example]
> > with a vla it's a bit more difficult to provide a corresponding solution.
> 
> You're making basically the same point that you made upthread, to
> which I already responded that it's beside the point I was making.
> Did you not understand the point I was making?  Do you not
> understand what it means for something to be beside the point?  Do
> you think that repeating yourself is going to magically change
> whether what you have to say is relevant?  The statement above
> (the last one in the quoted excerpt) is true but also obvious
> and irrelevant to what I was saying.
>
Platform specific code can deal with platform-specific stack overflow signals sensibly. Portable code can't. That doesn't mean that portable code might not be able to pass up an out of memory condition, if it can detect it. Caller might not be able to do anything sensible if that happens.

You say
> >>If a piece of
> >> code is able to deal with allocation failure in some way,
> >> that applies equally to allocation failures for malloc()
> >> and VLAs, assuming of course that VLA allocation failure
> >> can be detected
>
That sounds reasonable, but the devil is in "can be detected". Does it mean can be detected in the supposedly portable code, at cost of turning it into mass of conditional compilations, which means that it can't be tested or modified easily on a platform that doesn't provide for VLA failures?

VLA failure is not the same as malloc() failure. malloc() has a clear, portable interface for allocation failure. 

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

#23080

On Jul 2, 4:57 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
>
> VLA failure is not the same as malloc() failure. malloc() has a clear,
> portable interface for allocation failure.

It doesn't matter.  Whatever objection you raise, Tim's hypothetical
compiler will have a convenient fix for it.

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

#23117

gwowen <gwowen@gmail.com> writes:

> On Jul 2, 4:57 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>>
>> VLA failure is not the same as malloc() failure. malloc() has a clear,
>> portable interface for allocation failure.
>
> It doesn't matter.  Whatever objection you raise, Tim's
> hypothetical compiler will have a convenient fix for it.

I'm happy to respond to comments or objections regarding
what I write, as long as they are indeed about what I was
writing about.  I often don't have much to say in response
to statements on some different topic, except to say "that's
not what I was talking about," or "that's beside the point
I was making," which is a fair summary of the situation in
this case.

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

#23128

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

>  Tim Rentsch:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> >  Tim Rentsch:
>> >> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> >> 
>> >> You snipped too much context.  If a piece of code isn't
>> >> able to deal with an allocation failure, it doesn't matter
>> >> where the allocation falure came from.  If a piece of
>> >> code is able to deal with allocation failure in some way,
>> >> that applies equally to allocation failures for malloc()
>> >> and VLAs, assuming of course that VLA allocation failure
>> >> can be detected, which I pointed out upthread that it
>> >> can in a conforming implementation, if the implementation
>> >> so desires.  The ability or non-ability of some piece of
>> >> code to respond sensibly to allocation failure has no
>> >> bearing on the point I was making.
>> >>
>> > We're talking about libraries.
>> >
>> > I want to find the convex hull of a set of points. The algorithm I'm
>> > using needs a temporary buffer.  [snip example]
>> > with a vla it's a bit more difficult to provide a corresponding solution.
>> 
>> You're making basically the same point that you made upthread, to
>> which I already responded that it's beside the point I was making.
>> Did you not understand the point I was making?  Do you not
>> understand what it means for something to be beside the point?  Do
>> you think that repeating yourself is going to magically change
>> whether what you have to say is relevant?  The statement above
>> (the last one in the quoted excerpt) is true but also obvious
>> and irrelevant to what I was saying.
>>
> Platform specific code can deal with platform-specific stack overflow
> signals sensibly. Portable code can't. That doesn't mean that portable
> code might not be able to pass up an out of memory condition, if it
> can detect it. Caller might not be able to do anything sensible if
> that happens.

>
> You say
>> >>If a piece of
>> >> code is able to deal with allocation failure in some way,
>> >> that applies equally to allocation failures for malloc()
>> >> and VLAs, assuming of course that VLA allocation failure
>> >> can be detected
>>
> That sounds reasonable, but the devil is in "can be detected". Does it
> mean can be detected in the supposedly portable code, at cost of
> turning it into mass of conditional compilations, which means that it
> can't be tested or modified easily on a platform that doesn't provide
> for VLA failures?
>
> VLA failure is not the same as malloc() failure. malloc() has a clear,
> portable interface for allocation failure.

What point are you making that's different from the
two I already responded to, saying that your
comments were irrelevant to the point I was making?
Or are you just repeating the same irrelevant comments?

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

#23157

בתאריך יום שבת, 7 ביולי 2012 02:16:26 UTC+1, מאת Tim Rentsch:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
gwowoen:
> >
> > VLA failure is not the same as malloc() failure. malloc() has a clear,
> > portable interface for allocation failure.
> 
Ben:
> Really? Only if they're (i) of bounded size or (ii) of trivially small 
> size. Otherwise you're just asking for horrible, undetectable stack 
> overflow bugs, because VLAs have no failure mechanism. 
Tim:
What you mean is that VLAs have no portably guaranteed failure 
mechanism.  On a particular implementation they may very well 
have a well-defined, implementation-supplied, such mechanism
>
> What point are you making that's different from the
> two I already responded to, saying that your
> comments were irrelevant to the point I was making?
> Or are you just repeating the same irrelevant comments?
>
You're right. But a "well-defined, implementation supplied mechanism" isn't very useful, given the way that a lot of C is actually used, which is to create components.
You haven't replied to that point, just said "it's irrelevant", without giving a justification, except to claim that "malloc is the same", which isn't the case. Then you've repeated "you're making irrelevant points" ad nauseum. Which become irritating after a while.

-- 
Visit my website
http://www.malcolmmclean.site11.com/www

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

#23165

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> Ben:
>> Really? Only if they're (i) of bounded size or (ii) of trivially small 
>> size. Otherwise you're just asking for horrible, undetectable stack 
>> overflow bugs, because VLAs have no failure mechanism. 

I never said that.

<snip>
-- 
Ben.

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

#23167

בתאריך יום שבת, 7 ביולי 2012 16:48:22 UTC+1, מאת Ben Bacarisse:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
> > Ben:
> >> Really? Only if they're (i) of bounded size or (ii) of trivially small 
> >> size. Otherwise you're just asking for horrible, undetectable stack 
> >> overflow bugs, because VLAs have no failure mechanism. 
> 
> I never said that.
> 
Sorry. I had to go back in the thread, and you seemed to be in the attribution line.

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

#23183

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

> Tim Rentsch:
> [snip apparently misquoted previous context]
>
>> [in response to upthread posting]
>> What you mean is that VLAs have no portably guaranteed failure 
>> mechanism.  On a particular implementation they may very well 
>> have a well-defined, implementation-supplied, such mechanism
>>
>> [in response to last posting
>> What point are you making that's different from the
>> two I already responded to, saying that your
>> comments were irrelevant to the point I was making?
>> Or are you just repeating the same irrelevant comments?
>
> You're right. But a "well-defined, implementation supplied
> mechanism" isn't very useful, given the way that a lot of C is
> actually used, which is to create components.

I agree that an implementation-specific mechanism isn't
useful for writing maximally portable components, or
even, depending on the particulars, "widely" portable
components.

I don't agree that therefore such mechanisms aren't
very useful.  Even if 90% of C code being developed
were intended to be widely portable (which I don't
think is true, but let's assume it is for the moment),
helping the remaining 10% is certainly enough to
qualify as useful.

> You haven't replied to that point, just said "it's
> irrelevant", without giving a justification,

What I said was, it's irrelevant to the point I was
making;  and it is, because even though I believe
such an extension is useful, I hadn't said anything
about whether or how or under what circumstances it
would be useful.

> except to claim that "malloc is the same", which isn't the
> case.

You have misunderstood my comment;  the sense in
which you read it is not the same as the sense
in which I wrote it.

> Then you've repeated "you're making irrelevant points" ad
> nauseum. Which become irritating after a while.

Yes, as long as responses to what I write seem
irrelevant to what I'm saying, I'm likely to
reply saying they are beside the point of what
I'm saying.  For most people, that's sort of a
tip off that maybe they didn't get whatever
point I was trying to make in the first place.

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

#23082

Tim Rentsch wrote:

> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
>>  Tim Rentsch:
>>> gwowen <gwowen@gmail.com> writes:
>>> 
>>> What you mean is that VLAs have no portably guaranteed failure
>>> mechanism.  On a particular implementation they may very well
>>> have a well-defined, implementation-supplied, such mechanism.
>>>
>> And these days if you're writing C you're probably more likely to be
>> writing components rather than complete programs. A component does
>> know what to do on out of memory -sometimes relying on the OS to
>> kill the process is the best you can do, sometimes its completely
>> unacceptable.
> 
> Completely beside the point I was making, as using malloc() is
> no different in this regard.

How so?


Rui Maciel

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

#23116

Rui Maciel <rui.maciel@gmail.com> writes:

> Tim Rentsch wrote:
>
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>>>  Tim Rentsch:
>>>> gwowen <gwowen@gmail.com> writes:
>>>> 
>>>> What you mean is that VLAs have no portably guaranteed failure
>>>> mechanism.  On a particular implementation they may very well
>>>> have a well-defined, implementation-supplied, such mechanism.
>>>>
>>> And these days if you're writing C you're probably more likely to be
>>> writing components rather than complete programs. A component does
>>> know what to do on out of memory -sometimes relying on the OS to
>>> kill the process is the best you can do, sometimes its completely
>>> unacceptable.
>> 
>> Completely beside the point I was making, as using malloc() is
>> no different in this regard.
>
> How so?

My phrasing in that sentence wasn't as good as it might
have been..  sorry about that.

If he's talking about not being able to handle an allocation
failure adequately, it doesn't matter whether the handler runs
as a result of detecting a malloc() failure or detecting a VLA
allocation failure;  in either case the failure can't be
handled.

If he's talking about malloc() having a standard interface for
detecting allocation failures and VLAs not having such a
mechanism, that's beside the point I was making, since I was
explicitly talking about implementation-specific mechanisms.
Obviously I know that there is no Standard-defined mechanism for
dealing with VLA allocation failure, as my point was that an
implementation-specific one can be provided.  In that context,
however, where there is such a mechanism, there is no difference
between dealing with allocation failures for malloc() or VLAs.

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

#23177

Tim Rentsch wrote:

> My phrasing in that sentence wasn't as good as it might
> have been..  sorry about that.
> 
> If he's talking about not being able to handle an allocation
> failure adequately, it doesn't matter whether the handler runs
> as a result of detecting a malloc() failure or detecting a VLA
> allocation failure; 

With malloc(), if it isn't possible to allocate memory then it returns a 
null pointer.  Therefore, an allocation failure is detected by testing the 
pointer returned by malloc().

Can you point out how you would handle an allocation failure caused by a 
VLA?


> If he's talking about malloc() having a standard interface for
> detecting allocation failures and VLAs not having such a
> mechanism, that's beside the point I was making, since I was
> explicitly talking about implementation-specific mechanisms.

This newsgroup is supposed to be about standard C.  Moreover, if I'm not 
mistaken you are yet to point out a single implementation which implements 
such a mechanism.  When I asked you about that in a previous post, this was 
what you replied:

<quote>
> Is there any implementation that actually implements such
> a mechanism?

I don't know.  On the other hand, I don't know if there is
any implementation that faithfully implements array bounds
checking (ie, for C), yet such implementations are often
brought up in newsgroup postings;  moreover the mechanism
that I suggested for detecting VLA allocation failure is
much easier to add to an implementation than support for
array bounds checking is.
</quote>


So, what exactly are you talking about?  Hypothetical implementation-
specific mechanisms which don't exist in the real world?


Rui Maciel

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

#23179

בתאריך יום שבת, 7 ביולי 2012 19:35:43 UTC+1, מאת Rui Maciel:
> Tim Rentsch wrote:
>  
> So, what exactly are you talking about?  Hypothetical implementation-
> specific mechanisms which don't exist in the real world?
> 
> 
Say I write a command line utility to read in a DNA sequence, and scan it for lots of restriction sites (places in the DNA where enzymes cut it). Let's say that the plaform I'm using terminates the program with the nessage "segmentation fault" on stack overflow.
That's likely to be perfectly acceptable. The alternative is to detect the condition and terminate the program with the message "this program has run out of memory". That's slightly nicer but it doesn't buy me much.

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

#23196

Rui Maciel <rui.maciel@gmail.com> writes:

> Tim Rentsch wrote:
>
>> My phrasing in that sentence wasn't as good as it might
>> have been..  sorry about that.
>> 
>> If he's talking about not being able to handle an allocation
>> failure adequately, it doesn't matter whether the handler runs
>> as a result of detecting a malloc() failure or detecting a VLA
>> allocation failure; 
>
> With malloc(), if it isn't possible to allocate memory then it returns a 
> null pointer.  Therefore, an allocation failure is detected by testing the 
> pointer returned by malloc().
>
> Can you point out how you would handle an allocation
> failure caused by a VLA?

I have mentioned one particular idea in another thread.
My plan at this point is to start a new thread about it,
most likely in comp.std.c.

>> If he's talking about malloc() having a standard interface for
>> detecting allocation failures and VLAs not having such a
>> mechanism, that's beside the point I was making, since I was
>> explicitly talking about implementation-specific mechanisms.
>
> This newsgroup is supposed to be about standard C.  [snip elaboration]

It is, and what I'm talking about is what the Standard allows;
surely the subject is just as topical as other discussions about
what implementations are allowed to do in various obscure
circumstances.  I thought the idea might be interesting to some
people here, which has been borne out by some other responses;
if it isn't interesting to you, please feel free to ignore any
further comments on the matter.

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

#22772

On Jun 25, 10:27 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:

> What you mean is that VLAs have no portably guaranteed failure
> mechanism.  On a particular implementation they may very well
> have a well-defined, implementation-supplied, such mechanism.


Well, yes.  But you could say the same for NULL pointer dereferences.
The only difference is that implentations that give predictable
behaviour for NULL pointer dereferences actually exist, as opposed to
being completely theoretical.

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

#22794

gwowen <gwowen@gmail.com> writes:

> On Jun 25, 10:27 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
>> What you mean is that VLAs have no portably guaranteed failure
>> mechanism.  On a particular implementation they may very well
>> have a well-defined, implementation-supplied, such mechanism.
>
>
> Well, yes.  But you could say the same for NULL pointer dereferences.
> The only difference is that implentations that give predictable
> behaviour for NULL pointer dereferences actually exist, as opposed to
> being completely theoretical.

(Linguistic nit: 'hypothetical' is probably a better word choice
than 'theoretical'.  But no matter...)

I don't disagree, but the distinction is still important.  There
is no reason an implementation couldn't allocate VLAs outside
the regular stack space (eg, using malloc()/free() or something
like them), keeping only a pointer to the allocated space in
the stack frame.  This isn't even that hard to do.  In such an
implementation it's really easy to deal with VLA allocation
failure, eg,

    double product[m][n];
    if(  ! &product  )  ...

Now here comes the interesting part.  Suppose this idiom were
commonly followed.  Compilers certainly could check for it,
and substitute a check for sufficient stack space being available
for the VLA (ie, before adjusting the stack pointer to allocate
the VLA in the stack frame).  The result is we have VLAs that
are implemented just like the VLAs we're used to now, except
there is an easy way to deal with allocation failure.  And no
language changes required -- just smarter implementations.

Obviously it would be better if such a scheme were blessed in
the language standard, so it could be used portably.  In the
meantime, however, it can easily be implemented now, without
any language changes needed.  That the existing standard
accommodates such a scheme is a significant property.

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

#22795

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> gwowen <gwowen@gmail.com> writes:
>>Well, yes.  But you could say the same for NULL pointer dereferences.
>
>   One can always guard: >>if(p)*p;<<, I am not aware of the corresponding
>   guard for VLAs.

If the variable 'v' is a VLA, a test like 'if( ! &v )' might check for
allocation failure.  This doesn't work now, but it easily could,
first in particular implementations, later incorporated into the
Standard.  C 202X, anyone?

[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