The illusion of "portability"

[Keith Thompson]

malloc and friends rely on you freeing the memory.

They need a potentially expensive call to get the memory
since malloc must go through the free list looking for a right
sized block.

All this is avoided with VLAs. No need to free the block,
and no expensive looking up of the free list to see if the block
can be coalesced into a larger block to avoid memory fragmentation,
etc.

And no possibility of catching errors.

A conforming implementation could simply ignore an allocation error
for a VLA, allowing the program to continue attempting to access it,
possibly stepping on other variables or system data structures.

But it's more likely that a stack overflow will immediately abort the
program (and not allow any opportunity for cleanup).

It's true that the same consideration applies to ordinary automatic
variables, particularly with deep recursion, but VLAs are more likely
to cause problems.

The bad (i.e., mildly inconvenient) thing about malloc and friends is
that they require to to manage memory allocation yourself. The good
(i.e., vital) think about malloc and friends is that they *allow* you
to manager memory allocation yourself.

 

[jacob navia]

And no possibility of catching errors.

It depends, my implementation allows to catch the equivalent
of SIGSTACKOVFL, i.e. you can have a try/catch block around this
and catch the stack overflow. The handler must be specially written,
and I describe this in the tutorial of lcc-win32. Obviously this is
a non portable solution.

 

[Keith Thompson]

It depends, my implementation allows to catch the equivalent
of SIGSTACKOVFL, i.e. you can have a try/catch block around this
and catch the stack overflow. The handler must be specially written,
and I describe this in the tutorial of lcc-win32. Obviously this is
a non portable solution.

By contrast, allocation errors can be caught using 100% portable code
if you use malloc() instead.

 

[Peter Nilsson]

By contrast, allocation errors can be caught using 100% portable code
if you use malloc() instead.

That's not strictly true. On platforms with lazy allocation schemes,
malloc
may _never_ return a null pointer, but the program can still crash with
(say) an unspecified signal being raised.

Fact is, in C you _never_ have a guarantee over the allocation of
automatic storage. And the 'guarantee' for dynamic storage is only
truly applicable to the virtual C machine.

Note that VLAs are not optional for conforming freestanding C99
implementations, but malloc and friends are.

I tend to try and limit automatic allocations to less than 256 bytes.
VLAs don't preclude such measures. The handling would be no
different to the handling of malloc.

 

[Dik T. Winter]

> In article <[email protected]>

> >VLAs? More sugar.

>
> Here I have to disagree: when you need VLAs, you really need them.
> In particular, they allow you to write matrix algebra of the sort
> that Fortran has had for years:
>
> void some_mat_op(int m, int n, double mat[m][n]) {
> ...
> }

This is something different. You are dimensioning the arguments here.
What it solves is problems like:
void some_mat_op(int m, int n, double mat[m][n]) {
double temp[m][n];
...
}
something that Fortran has only since 1990. It was in Algol 60 from
the very beginning.

 

[Keith Thompson]

That's not strictly true. On platforms with lazy allocation schemes,
malloc may _never_ return a null pointer, but the program can still
crash with (say) an unspecified signal being raised.

Good point; I forgot about lazy allocation schemes.

In my opinion, such schemes violate the C standard, but I suppose
we're stuck with them.

One workaround is to initialize the allocated object after malloc()
succeeds, but (a) that can be expensive, and (b) a failure to
initialize it can't be caught anyway.

On an OS that does lazy allocation, it should still be possible to
provide a routine that does non-lazy allocation, ensuring that the
supposedly allocated memory really is allocated, and harmlessly
deallocating the memory and returning an error code if it isn't. (I
suggest using a null pointer as the error code, and calling the
routine "malloc".)

Fact is, in C you _never_ have a guarantee over the allocation of
automatic storage. And the 'guarantee' for dynamic storage is only
truly applicable to the virtual C machine.

Note that VLAs are not optional for conforming freestanding C99
implementations, but malloc and friends are.

True. We tend to assume hosted implementations here. I wouldn't want
to require every article here to explicitly note the difference, but
we should probably mention it more often than we do.

I tend to try and limit automatic allocations to less than 256 bytes.
VLAs don't preclude such measures. The handling would be no
different to the handling of malloc.

malloc at least has a mechanism for reporting an allocation failure
without killing the caller. VLAs don't (at least not portably).

 

[Dik T. Winter]

>
> Good point; I forgot about lazy allocation schemes.
>
> In my opinion, such schemes violate the C standard, but I suppose
> we're stuck with them.

I think to, and they also violate quite a few other things. In the
OS's that came with lazy allocation schemes we have always shut it off.
It can lead to problems later on that can be very serious. (When did
that daemon die, and why?)

> On an OS that does lazy allocation, it should still be possible to
> provide a routine that does non-lazy allocation, ensuring that the
> supposedly allocated memory really is allocated, and harmlessly
> deallocating the memory and returning an error code if it isn't.

It should be, but in general isn't. Because the lazy allocation is
done by the system itself, not by the C runtime, or what you want to
call it. I have worked with one such system (SGI IRIX) and it was
horrible. It could happen that your X server was shut down because
of overallocation of memory or that some other random process got
killed.

>
> malloc at least has a mechanism for reporting an allocation failure
> without killing the caller. VLAs don't (at least not portably).

With numerical algorithms that use VLA's, you will frequently see that
the allocation with VLA's largely exceeds the 256 bytes. Consider an
algorithm that has as input a matrix and that needs temporary storage
of the same size. Suppose the input matrix (of doubles) is 100x100
(not uncommon), you need temporary storage for 80,000 bytes. Some
numerical algorithms need large amounts of temporary storage, and I
would rather trust malloc in that case.

 

[Herbert Rosenau]

In this group there is a bunch of people that call themselves 'regulars'
that insist in something called "portability".

Jacob Navia means: there is a twit in the group who means that there
is ony one OS and ony one crappy compiler and portability is nothing
worth.

This group is for the klanguage named C, not for something the twit
means that C shoulb be.

Jacob navia should piss off this group and go spamming for his pissy
thing soewhere as Jacob Naia will never learn for what portability is
made and how that will save money as he is too braindead to accept
that programming is not only a hobby but to make processes more
simple, to save money by writing programs once instead to fiddle
around weith lots of different mashines under different opeating
systems using different compilers.

Programs are not only written once but maintained over a long, really
long livetime where not only compilers going out of maintenance but
the current hardware gets out of lifetime, OSes and compilers change
theyr behavior by changing from version to version or even the need to
change the underlying operating system completely, by chaning from 8
to 16 to 62 to 64.... bit wide words and so on.

Having a language like C that guarantees its behavior by a standard
makes it possible to write programs even in worst case widenly
standard conforming reduces costs.

Only twits like Jacob Navia are whining that the standard hinders them
to get things right. Programmers with a bit working brain knows how to
write portable programs. They know what to do even when this is
partially impossible.

But at least this group is defined to help to write standard
conforming C programs and not to write something a twit means that it
should be C even as it is not.


Jacob Navia piss off this group, it is not designed for you but for
people who need help to get portable programs working.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Richard Heathfield a écrit :

True, C99 didn't really advance the language that much, but it has some
good points. Anyway, if we are going to stick to standard C, let's agree
that standard C is Standard C as defined by the standards comitee.

// comments? More sugar. VLAs? More sugar.

And what do you have against sugar?
You drink your coffee without it?

If the coffee is really excellent then the answer is simply: yes.

I mean, C is just syntatic sugar for assembly language. Why
not program in assembly then?

That is because jacob Navia is too dumb to understund why there is a
standard and what standard conforming programming really means.

Mixed declarations are a progress in the sense that they put the
declaration nearer the usage of the variable, what makes reading
the code much easier, specially in big functions.

True, big functions are surely not a bright idea, but they happen

Really? May be, but written only by idiots who have no idea of program
design.

I accept that this is not a revolution, or a really big progress in C
but it is a small step, what is not bad.

VLAs are a more substantial step since it allows to allocate precisely
the memory the program needs without having to over-allocate or risk
under allocating arrays.

Jacob Navia should learn how program design works in contrast to
blindly hack around. In 30 years programming in C I've never had a
need for VLAs even as in most of the programs I've written most of the
data I had to handle was in unknown size from some KB up to some
hundret MB in size. In any case an array was always worst case and to
avoid by design.

Under C89 you have to either:
1) allocate memory with malloc
2) Decide a maximum size and declare a local array of that size.

What will you say? When you knows how malloc work then it is the best
solution to get data handled when you need semirandom access. When you
have linear access you does not even need an single array.

Learn how to design a program right and you have no problem to handle
some GB on data - even with only some KB memory available. True is you
must be a real programmer, not a braindead hacker to get it right.

Both solutions aren't specially good. The first one implies using malloc
with all associated hassle, and the second risks allocating not enough
memory. C99 allows you to precisely allocate what you need and no more.

Bullshit, pure bullshit that shows only that Jacob Navia is unable to
program right.
In no ways will an VLA able to get thing right you have to handle
reals mass data at once.
Learn to handle malloc(), realloc() and free right, learn which of the
endless long list of tree types helps you to get your data handy by
using a minimum of memory by minimising the time to access it for your
needs.

They do come handy, but again, they are not such a huge progress.

Maybe, maybe not, I have no data concerning this. In any case it
promotes portability (yes, I am not that stupid! since it
defines a common interface for many math functions. Besides the control
you get from the abstracted FPU is very fine tuned.

You can portably set the rounding mode, for instance, and many other
things. In this sense the math library is quite a big step from C99.


That is a progress too, but (I do not know why) we never discuss them
in this group.

Why should we? This group is for standard C, not for a single specific
CPU or FPU. There are more different and incompatible FPUs as the twit
Jacob navia will ever drem of. Standard C will help you simply to hide
the internals and a halfways good compiler will give you the best that
is possible on each of them.

Maybe what frustrates me is that all this talk about "Stay in C89, C99
is not portable" is that it has taken me years of effort to implement
(and not all of it) C99 and that not even in this group, where we should
promote standard C C99 is accepted as what it is, the current standard.

Stop spamming for your crap. There are reasons enough to stay on C89.
They are named too often here to repeat them again.

Here in this group is nobody who forces you not to use a C99 compiler
when you have one who is 100% compilant for all the environments you
needs to program for.

I mean, each one of us has a picture of what C "should be". But if we
are going to get into *some* kind of consensus it must be the published
standard of the language, whether we like it or not.

Why is Jacob Navia unable to follow his own words? I'm able to write
100% conforming C89 programs as proven already but I would be unable
to to so for C99 because there is no compiler available for all
different environments I have to write for. So I'm bounded to C89.

For instance the fact that main() returns zero even if the programmer
doesn't specify it I find that an abomination. But I implemented that
because it is the standard even if I do not like it at all.

Boah, ey! That will at least not help to trust it because its
developer is proven as twit already.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Kenneth Brody]

puts() automatically adds newline.

Yeah, but... Umm... Err... Oops... :-(

Shows you how long it's been since I've used puts().

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenneth Brody]

It depends, my implementation allows to catch the equivalent
of SIGSTACKOVFL, i.e. you can have a try/catch block around this
and catch the stack overflow. The handler must be specially written,
and I describe this in the tutorial of lcc-win32. Obviously this is
a non portable solution.

^^^^^^^^^^^^^^^^^^^^^

Ding, ding, ding! We have a winner!

We should stick to the (less-widely available) C99 standard because
it offers so much more, like VLAs. But, to avoid the inherent UB
of using VLAs, we should stick to non-standard, non-portable
workaround?

And are try/catch part of C99?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Walter Roberson]

Walter Roberson wrote:

You are cheating since you posted at 19:35...

It was about 12:35 here; 19:35... hmmm, that would have been
some european summer time zone.

 

[Chris Torek]

[VLAs] allow you to write matrix algebra of the sort
that Fortran has had for years:

void some_mat_op(int m, int n, double mat[m][n]) {
...
}

This is something different. You are dimensioning the arguments here.

Different from what? (It is still a VLA, or at least, it is in the
draft C99 standard I use.)

What it solves is problems like:
void some_mat_op(int m, int n, double mat[m][n]) {
double temp[m][n];
...
}

It does this too; but being able to give variable dimensions for
a parameter is valuable on its own. It avoids any need to fake
out the routine with code like this:

void some_mat_op(int m, int n, double *mat) {
... refer to mat[i * n + j] instead of mat[j] ...
}
...
void f(void) {
double mat[300][5];
...
some_mat_op(300, 5, &mat[0][0]);
...
}

which is not even strictly valid in C89/C90 (due to out-of-bounds
subscript usage in some_mat_op(), whenever i>0). The faked-out
version usually works; but one is at least skating on thin ice,
and of course the C99 version is much more convenient.

something that Fortran has only since 1990.

Well, this is still "years"

[Automatic duration, runtime-sized arrays were] in Algol 60 from
the very beginning.

As has oft been said, Algol was an improvement on its successors.

 

[Dik T. Winter]

> >> [VLAs] allow you to write matrix algebra of the sort
> >> that Fortran has had for years:
> >>
> >> void some_mat_op(int m, int n, double mat[m][n]) {
> >> ...
> >> }

>

> >This is something different. You are dimensioning the arguments here.

>
> Different from what? (It is still a VLA, or at least, it is in the
> draft C99 standard I use.)

Different from what Jacob Navia wrote, but I do not remember whether
he wrote it before you or after you.

....

> It does this too; but being able to give variable dimensions for
> a parameter is valuable on its own. It avoids any need to fake
> out the routine with code like this: ....
Indeed.

> >[Automatic duration, runtime-sized arrays were] in Algol 60 from
> >the very beginning.

>
> As has oft been said, Algol was an improvement on its successors.

Certainly for me, as Algol 60 was the first programming language that
I did learn.