The illusion of "portability"

[Kenneth Brody]

Richard Heathfield a écrit : [... C99 ...]

Mixed declarations? Sugar.

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

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

Many people don't like sugar in their coffee.

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

Portability.

[...]

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.

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

Both solutions aren't specially good. The first one implies using malloc
with all associated hassle,

What "hassle"?

Oh, no! I have to remember to free it! However shall I handle the
pressure?

and the second risks allocating not enough
memory. C99 allows you to precisely allocate what you need and no more.

Yet, as I understand it, if the VLA can't be allocated, the result
is undefined behavior. With malloc/free, you have well-defined
behavior for failure. True, you have to check for failure, but at
least you _can_ check for failure, unlike VLAs.

[...]

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

Because they're not part of C itself.

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.

C99 is portable to systems which have C99 compilers.

AFAIK, C99 questions are not off-topic here, even if people will
point out that it's C99. (Of course, I may be wrong.)

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.

Umm... Isn't that what we do here?

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.

That was probably a concession to not break formerly "working"
programs which weren't really "right" to begin with.

--
+-------------------------+--------------------+-----------------------+
| 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]>

 

[Al Balmer]

I can easily imagine legal problems for a C compiler vendor
who claimed in their advertizing that their compiler adhered to the
ANSI/ISO C standard but in fact, failed badly on many measures.

But this has nothing to do with the legal status of the standard. it
has to do with the claim. It's exactly the same as a car dealer
selling me an eight-cylinder car which turns out to have only six
cylinders. The dealer is at risk of both legal and civil action, but
not because eight cylinder cars are standard.

 

[Kenneth Brody]

A "good" programmer can write FORTRAN code in any language

A "great" programmer can even write it in FORTRAN.

--
+-------------------------+--------------------+-----------------------+
| 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]

Keith Thompson wrote: [...]

I think you meant to drop the first "not" in that last sentence;
"people not being told" should be "people being told".

I'll write a program to write out 1000 time, "Do not post to comp.lang.c
at almost 2AM."

#include <stdio.h>

int main(void)
{
int i;

for (i=0; i<1000; i++)
puts("Do not post to comp.lang.c at almost 2AM.");

return 0;
}

Nor should you post at 3:30AM.

No terminating newline in your output.

--
+-------------------------+--------------------+-----------------------+
| 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]>

 

[Thomas Carter]

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

Portability for them means the least common denominator.

I am not sure about that - somewhere I read that a program is said to be
portable if the amount of work involved in compiling it for a platform
different than the one it was developed under is less than teh work
necessary to develop it from scratch for the new platform.

 

[Richard Heathfield]

Ben Pfaff said:

I consider calling exit(EXIT_FAILURE) strictly better than
undefined behavior due to dereferencing a null pointer.

I agree entirely. Perhaps you misread my reply?

 

[Kenneth Brody]

jacob navia wrote:
[...]

1) VLAs allow you to precisely allocate the memory the program needs
instead of using malloc (with all its associated problems) or having
to decide a maximum size for your local array, allocating too much
for most cases.

int fn(int n)
{
int tab[n];
}

allocates JUST what you need AT EACH CALL.

[...]

You've mentioned the "hassle" and "problems" of using malloc, yet I
don't see any description of what you mean by that.

Also, how do you handle the fact that failure to allocate a VLA for
whatever reason invokes UB?

--
+-------------------------+--------------------+-----------------------+
| 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]

Keith Thompson wrote: [...]

(e-mail address removed) a écrit :
C99 is standard C. Other standards must be prefaced by the name of
the standard (IMO-YMMV). That's because C99 legally replaces the
previous C standard.

[...]
First, I disagree with the use of the term "legally". ISO is not a
governmental body, and the C standard does not have the force of law.
Nobody is going to arrest a user or an implementer for failing to
conform to it.

ANSI is connected to the U.S. government and (along with NIST) is used
to establish standards in the United States. While standard adoption
is 'voluntary' there can still be legal ramifications. For instance,
if I stamp the head of my bolt with a certain number of diamond shapes
on it, that is a claim of adherence to a standard. If the claim is
false, the manufacturer could get sued, possibly go to jail, etc.
Sometimes, formal standards do get adopted with more or less legal
weight, which would vary from country to country and standard to
standard. I can easily imagine legal problems for a C compiler vendor
who claimed in their advertizing that their compiler adhered to the
ANSI/ISO C standard but in fact, failed badly on many measures.

But there is nothing "illegal" about not following these standards.
The "illegal" part is claiming conformance when you don't, but that's
no different than my claiming to sell "half-gallon" containers of
ice cream and only putting 63 ounces in them. There's nothing illegal
about selling 63-ounce containers of ice cream. (Now, there may be
segments of society/business/whatever, where the law says you must
follow a given standard, but that's not the case here.)

[...]

--
+-------------------------+--------------------+-----------------------+
| 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]

Tom St Denis wrote:
[...]

No one expects a 3D video game to work on an 8051.

Well, no "reasonable" person, anyway.

On the otherhand, one would expect some non-interface type routine to
work anywhere.

My own math lib [LibTomMath] has been built on things as low as an 8086
with TurboC all the way up through the various 64-bit servers and
consoles. Without sacrificing too much speed or ANY functionality.

Similarly my crypto code is used pretty much anywhere without hacking
for this compiler, that compiler, etc.

Oh, you're _that_ Tom?

I can vouch for LibTomCrypt's "portability" to the extent that I have
used it in our program, which runs on Windows, Unix, Linux, and several
others, on numerous hardware platforms.

--
+-------------------------+--------------------+-----------------------+
| 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]>

 

[Richard Heathfield]

Kenneth Brody said:

Keith Thompson wrote: [...]

I think you meant to drop the first "not" in that last sentence;
"people not being told" should be "people being told".

I'll write a program to write out 1000 time, "Do not post to comp.lang.c
at almost 2AM."

#include <stdio.h>

int main(void)
{
int i;

for (i=0; i<1000; i++)
puts("Do not post to comp.lang.c at almost 2AM.");

return 0;
}

Nor should you post at 3:30AM.

No terminating newline in your output.

You shouldn't post at 4:16pm. He used puts(), not printf().

 

[Walter Roberson]

Flash Gordon wrote:

Nor should you post at 3:30AM.

No terminating newline in your output.

puts() automatically adds newline.

 

[jacob navia]

jacob navia wrote:
[...]

1) VLAs allow you to precisely allocate the memory the program needs
instead of using malloc (with all its associated problems) or having
to decide a maximum size for your local array, allocating too much
for most cases.

int fn(int n)
{
int tab[n];
}

allocates JUST what you need AT EACH CALL.

[...]

You've mentioned the "hassle" and "problems" of using malloc, yet I
don't see any description of what you mean by that.

Also, how do you handle the fact that failure to allocate a VLA for
whatever reason invokes UB?

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.

 

[jacob navia]

puts() automatically adds newline.

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

 

[Tom St Denis]

malloc and friends rely on you freeing the memory.

Yeah, oddly enough malloc and STACKS solve different problems. You
halfwit malcontent.


ooh, ooh next you'll point out that memset is the faster qsort()!!!

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.

Yeah except you can't free VLAs [or alloca's] in random order.

Tom

 

[Skarmander]

It primarily means that conforming compilers have been implemented on a
wide variety of hardware and OS combinations, so that conforming code
on one platform can be expected to behave the same on any other
platform.

Secondarily, it means structuring your code so that it supports
multiple platforms concurrently with minimal effort, which I've had to
do on numerous occasions (the most painful being classic MacOS,
Solaris, and Windows 3.1).

And as far as supporting the "least common denominator", it's not my
fault that Microsoft went out of its way to make it nigh impossible to
code for Windows and *anything else* by "extending" C to such a
ridiculous degree. Nor is it my fault that the bulk of the lossage was
on the Windows side.

It's not exactly "nigh impossible" in a technical sense; it's just that if
you choose the path of least resistance (that is, you code as Microsoft
recommends) you've already lost, and practically consigned your program to
single-platform hell for all eternity. (Alright, so the various flavors of
Windows technically constitute different platforms, but you know what I mean.)

It's very true that you are much better off aiming for a portable program
that runs on Win32 than a Win32 program that's portable. If you drink the
Kool-Aid and litter your program with BOOL, LPSTR and UINT because that's
what the Windows-specific parts of it use, you lose. Portability for Windows
is a delicate topic, for which the documentation of the natives offers you
little to no help.

S.

 

[Skarmander]

It's not exactly "nigh impossible" in a technical sense; it's just that
if you choose the path of least resistance (that is, you code as
Microsoft recommends) you've already lost, and practically consigned
your program to single-platform hell for all eternity. (Alright, so the
various flavors of Windows technically constitute different platforms,
but you know what I mean.)

Point in case: the rest of my post used "Win32" where Win16/32/64 would have
done just as well (or perhaps even better, since the problems you'll have
porting between even these platforms are illustrative).

S.

 

[Ben Pfaff]

Ben Pfaff said:


I agree entirely. Perhaps you misread my reply?

My goal was not really to correct you, but to make my own
position clear.

 

[Andrew Poelstra]

Well, at least this kind of macro always casts to the right type,
unlike manual casts.

Possibly. You can still do
long *x = MALLOC (short, 15);
although in that case you should get a diagnostic.

Hmm. It seems this is superior to a manual malloc (s * sizeof(type)),
but of course using

p = malloc (n * sizeof *p);

is superior to both.


(Not suggesting that you didn't know that; I'm merely commenting that
the macro is a reasonable(?) solution that shouldn't necessarily be
thrown out.)

 

[Flash Gordon]

Kenneth Brody said:

Keith Thompson wrote: [...]
I think you meant to drop the first "not" in that last sentence;
"people not being told" should be "people being told".
I'll write a program to write out 1000 time, "Do not post to comp.lang.c
at almost 2AM."

#include <stdio.h>

int main(void)
{
int i;

for (i=0; i<1000; i++)
puts("Do not post to comp.lang.c at almost 2AM.");

return 0;
}

Nor should you post at 3:30AM.

No terminating newline in your output.

You shouldn't post at 4:16pm. He used puts(), not printf().

What is worse, I did it maliciously and with forethought ;-)

In any case, I posted it at 8:33AM. Aren't time zones wonderful?

 

[Keith Thompson]

jacob navia wrote: [...]

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.

C99 is portable to systems which have C99 compilers.

AFAIK, C99 questions are not off-topic here, even if people will
point out that it's C99. (Of course, I may be wrong.)

C99 questions are certainly topical here, and we discuss them all the
time. (We also point out that using C99-specific features can lead to
portability problems, and sometimes we suggest C90 alternatives.)

[...]

That was probably a concession to not break formerly "working"
programs which weren't really "right" to begin with.

Such programs "worked" only on some platforms. On many systems,
falling off the end of main() would return a failure indication; for
example, on Solaris it would do the equivalent of exit(1).