«

On Mar 24, 1:57 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Old Wolf <oldw...@inspire.net.nz> writes:
> > On Mar 22, 4:19 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> Sensei <Sensei's e-mail is at Mac-dot-com> writes:
>
> >> > int x[];
>
> >> > would be an incomplete type. This quite puzzles me, since I don't
> >> > understand how x[] could then be used in a code block.
>
> >> It can't be.
>
> > In fact it can,
>
> Yes, and I went on to say this (albeit without an example).

You contradicted yourself, then. I don't think there is any
grounds to make an absolute statement "It can't be" (which
you made an entire paragraph on its own), when in fact it
can be, and it is not uncommon to do so in real code.

You mention the example of int x[]; but didn't mention at
all the much more common:
extern int x[];

> It seems
> rather unfair to clip that and claim I missed something.

I'm sure you didn't miss it personally, but I think it
is confusing to say the very least to say "Y is not possible."
and go on quoting more text from the original, and then later
down the page bury a sentence "except for..."

> It will become impossible to write explanations for people new to C if
> every statement must stand up when taken out of the context of the
> reply. If you wanted to explain this point to the OP, then you could
> have replied to their "I don't understand how x[] could then be used
> in a code block" (with a note to say you are taking "code block" to
> mean file-scope declarations).

I'm taking "code block" to mean stuff at block scope. The case
I am highlighting is the one where x is used at block scope,
as the OP said, but declared at file scope.

On Mar 22, 12:33*am, Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
> On 2008-03-21 20:24:53 +0100, user923005 <dcor...@connx.com> said:
>
> > Automatic variables are typically placed on a *cough* stack. The
> > generation of these variables is really just a simple subtraction.
> > The generation of dynamic memory is more complicated and requires
> > functions to track the allocations carefully.
> > The speed of access will be similar between automatic and dynamically
> > allocated memory. *It is the book keeping of generation and disposal
> > that differ significantly.
>
> > So why not just use automatic memory all the time? *It is a very
> > limited resource, and when it fails, it does not fail gracefully like
> > malloc() which will tell you that something went wrong by returning an
> > NULL pointer. *If an automatic allocation fails you can expect a core
> > dump or some sort of undefined behavior.
>
> Ok, so I understand why VLAs are usually faster, and I understand also
> that sizes of VLAs may be limited compared to malloc'ed arrays, since
> the memory VLAs are allocated into is quite precious and limited.

This is typically true. Many systems have a fixed size for automatic
variables (and often you can change the amount by a linker switch or
program that modifies the executable after linking).
With allocated memory, you will sometimes get the amount of virtual
memory that is possible on the machine, and sometimes you will get the
amount allowed by a user limit of some kind.

At any rate, you have perceived correctly that the (typically) faster
allocation of automatic memory comes at a price of danger.
Because C allows recursion, it is hard to know how big automatic
memory can become except heuristically by measurement. The same goes
for allocated memory, of course, but often there is more allocated
memory available to a process and it is always possible to catch a
problem with calloc() or malloc() because NULL will be returned if the
memory is not available.

These sorts of details are more or less common practice but do not
necessarily predict how an arbitrary C implementation might behave.

On 2008-03-24 23:58:09 +0100, user923005 <> said:

>> Ok, so I understand why VLAs are usually faster, and I understand also
>> that sizes of VLAs may be limited compared to malloc'ed arrays, since
>> the memory VLAs are allocated into is quite precious and limited.
>
> This is typically true. Many systems have a fixed size for automatic
> variables (and often you can change the amount by a linker switch or
> program that modifies the executable after linking).
> With allocated memory, you will sometimes get the amount of virtual
> memory that is possible on the machine, and sometimes you will get the
> amount allowed by a user limit of some kind.
>
> At any rate, you have perceived correctly that the (typically) faster
> allocation of automatic memory comes at a price of danger.
> Because C allows recursion, it is hard to know how big automatic
> memory can become except heuristically by measurement. The same goes
> for allocated memory, of course, but often there is more allocated
> memory available to a process and it is always possible to catch a
> problem with calloc() or malloc() because NULL will be returned if the
> memory is not available.
>
> These sorts of details are more or less common practice but do not
> necessarily predict how an arbitrary C implementation might behave.

Thanks! It's always a good thing to know more about common behaviors
and good practices.

--

Sensei*<Sensei's e-mail is at Mac-dot-com>

We know Linux is the best, it can do infinite loops in five seconds.
(Linus Torvalds)