Learning C as an existing programmer

[Guest]

char *p;

in some place i write...
p=0; *p=0;
do you think it is not good?

dunno. what effect were you hoping for? If there's any sort of memory management it'll likely crash.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×œ×™×©×™, 26 ביוני 2012 15:22:35 UTC+1, מ×ת Tim Rentsch:

(e-mail address removed)-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.

 

[Tim Rentsch]

Tim Rentsch:

(e-mail address removed)-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.

 

[Joe.]

You owe me a new keyboard, I just spilled coffee all over mine when I
burst
into laughter.

Why don't I find that funny?

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×™×©×™, 29 ביוני 2012 18:07:29 UTC+1, מ×ת Tim Rentsch:

Tim Rentsch:

(e-mail address removed)-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 sayThat sounds reasonable, but the devil is in "can be detected". Does it meancan 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.

 

[gwowen]

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.

 

[Rui Maciel]

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.

Is there any implementation that actually implements such a mechanism? And
if this sort of mechanism isn't required by the standard, is it a good idea
to write code counting on it?


Rui Maciel

 

[Rui Maciel]

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

How so?


Rui Maciel

 

[Tim Rentsch]

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.

And if this sort of mechanism isn't required by the standard,
is it a good idea to write code counting on it?

That depends on the context for which the code is being
written. Almost all programs that I write, or work on,
make some assumptions about the environment(s) in which
they will run. I don't see anything wrong with relying
on a platform-specific capability if the nature of the
problem being solved means it is going to be run only
on platforms that support the capability. Furthermore,
the particular mechanism I suggested is completely safe
in the sense that it does no harm in an implementation
that does not support it. To me it makes more sense,
assuming the associated costs of the extra code aren't
too high, to include code that helps on some platforms
and is essentially ignored on others. Certainly there
are cases where maximum portability is paramount, and
in such cases we might want to avoid even a hint of any
platform-specific features; I expect, though, that it
is more common for programs to be closer to the other
end of the spectrum, targeting a particular platform or
a small number of related platforms, and in those cases
the benefits (ie, of using a non-ubiquitous capability)
are more likely to outweigh the costs. As usual there
is no hard-and-fast rule that's always right, and what
makes sense in one case might be a very poor decision
in another. (Like a friend of mine used to say: "I've
found a way to eliminate tradeoffs; the only thing is,
you have to give up something else...")

 

[Tim Rentsch]

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.

 

[Tim Rentsch]

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.

 

[Tim Rentsch]

Tim Rentsch:

Tim Rentsch:
(e-mail address removed)-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
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?

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,7 ביולי 2012 02:16:26 UTC+1, מ×ת Tim Rentsch:

gwowoen:
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'tvery 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'tthe case. Then you've repeated "you're making irrelevant points" ad nauseum. Which become irritating after a while.

 

[Ben Bacarisse]

Ben:

I never said that.

<snip>

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,7 ביולי 2012 16:48:22 UTC+1, מ×ת Ben Bacarisse:

I never said that.

Sorry. I had to go back in the thread, and you seemed to be in the attribution line.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×™×©×™, 6 ביולי 2012 23:56:34 UTC+1, מ×ת Tim Rentsch:

I expect, though, that it
is more common for programs to be closer to the other
end of the spectrum, targeting a particular platform or
a small number of related platforms, and in those cases
the benefits (ie, of using a non-ubiquitous capability)
are more likely to outweigh the costs.

Most programs don't have to run on more than a limited set of platforms, often just one.
But most components can be written portably. Basically you need to ask, does this bit of funtionality perform IO? If not, it can be written in pure ANSI C, and normally it should be written in pure ANSI C. There is a problem with malloc(), and there are some side issues with DMA engines and the likewhich blur the distinction between IO and processing.
With some embedded programs the calculation side of what they do is so trivial that this isn't of any real use. Essentially the whole program is aboutinteracting with the various ports, with just a bit of logic to hold it all together. But a lot of programs are the opposite, mainly calculation witha trvial bit of IO to get the data in and pass the results back.

 

[Rui Maciel]

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:

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

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,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.

 

[Tim Rentsch]

Tim Rentsch:

I expect, though, that it
is more common for programs to be closer to the other
end of the spectrum, targeting a particular platform or
a small number of related platforms, and in those cases
the benefits (ie, of using a non-ubiquitous capability)
are more likely to outweigh the costs.

Most programs don't have to run on more than a limited set of
platforms, often just one.

But most components can be written portably. Basically you need to
ask, does this bit of funtionality perform IO? If not, it can be
written in pure ANSI C, and normally it should be written in pure ANSI
C. There is a problem with malloc(), and there are some side issues
with DMA engines and the like which blur the distinction between IO
and processing. [snip elaboration]

I might have to be concerned about that, if what I was
talking about had to do with writing portable components.
But it wasn't.

 

[Tim Rentsch]

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.