The portability sacred cow

[jacob navia]

Le 20/04/2014 23:14, jacob navia a écrit :

[snip]

I forgot to say that in the name of portability, C99 was "off limits"
for this newsgroup between 2000 and around 2009? (when Heathfield left)

All the times I would bring an example of C99 code I was reminded that
it "wasn't portable", and that "portable code should stay with C89"

Now, it seems that the same people changed their attitude (a bit), maybe
because a new standard is out who knows, they never explained their change.

That is why I speak about "portability crazyness", because it was that.
Everything was sacrified in the name of "portable code" even when it
meant less features, and reinventing old wheels again.

 

[Malcolm McLean]

All the times I would bring an example of C99 code I was reminded that
it "wasn't portable", and that "portable code should stay with C89"

Now, it seems that the same people changed their attitude (a bit), maybe
because a new standard is out who knows, they never explained their change.

That is why I speak about "portability crazyness", because it was that.
Everything was sacrified in the name of "portable code" even when it
meant less features, and reinventing old wheels again.

Microsoft didn't support C99. Windows was such an important platform that
effectively we had to say that C99 was only for single platform code.

For people like myself, portability is extremely important. I don't really
know what system my code will be required to run on in the future. That has
the effect of squeezing out language experiments. Which isn't a good thing
in itself. I don't hold that C89 was perfect and the last word in language
design. But it is a pretty good abstraction of von Neumann architecture.
No C dialects offer a clear and unambiguous improvement over C89.

 

[jacob navia]

Le 22/04/2014 23:02, Malcolm McLean a écrit :

Microsoft didn't support C99. Windows was such an important platform that
effectively we had to say that C99 was only for single platform code.

Microsoft doesn't support C99 even today, 15 years after the standard
publication... I am sure it will never will. As they said in their
blogs, there is no "customer demand" for C99.

Microsoft doesn't support C any more in many of its system interfaces...

So what?

Why should be that a problem for you?

 

[jacob navia]

Le 22/04/2014 23:02, Malcolm McLean a écrit :

For people like myself, portability is extremely important. I don't really
know what system my code will be required to run on in the future. That has
the effect of squeezing out language experiments. Which isn't a good thing
in itself.

Agree with that. It is not a good thing.

And it has a cost, a cost that means that users of your code in more
advanced systems can't have all the simplifications that modern
languages offer. It means that you are bound to rewrite snprintf, if you
need it, for instance.

http://www.tedunangst.com/flak/post/worst-common-denominator-programming
<quote>
The real snprintf returns the number of characters it wanted to print,
regardless of buffer size. The imitation BIO_snprintf returns the number
of characters printed, unless truncation occurs, in which case it
returns -1. So they’re mostly the same, except in those situations where
bad things like overflow are happening, in which case normal C
programmers need to remember that OpenSSL C is not normal.

if (BIO_snprintf(buf,sizeof buf,"%s_default",v->name) >= (int)sizeof(buf))
That’s how one checks real snprintf for truncation, but not
BIO_snprintf! Ironically, the code would have worked even so, because -1
implicitly converted to size_t is going to be quite large, but then
somebody went full retard and cast sizeof to int. Never do this. (The
cast would be mostly harmless with real snprintf. Only the combination
of wrapper and cast cause the error. The planets must have been in
alignment. Still, don’t cast sizeof.)
<end quote>

snprintf is a real improvement... Why should you abandon it or rewrite it?

I do not want to question your choices, I am just saying that they have
a cost.

 

[luser droog]

My view is that you need to separate programs into the bit-shuffling section and the the IO section.
Some parts of the program rearrange bits in memory, other parts manipulate output devices.

Any code that is interesting in a computer science, mathematical, logical, artistic or other sense
will be bit shuffling code. That should be written portably, there's no reason to use any non-portable
constructs, there's no reason to be interested in what type of processor you're running on. (OK,
I haven't addressed parallellisation and other forms of hardware acceleration, it's a general scheme).

The code that does IO is essentially a job for a hacker. It's not necessarily easy to write, but the
difficulties aren't of a fundamental order. It's a case of one human understanding a system designed
by another human and knowing how to interact with it. A lot of it isn't portable, and portability means
something else. It means devising common interfaces, not agreeing on a common language for
specifying algorithms.

Now what do we need to specify an algorithm? Essentially a human-usable Turing complete system.
A way of getting an arbitrary-sized memory buffer, a way of reading and writing to it, conditional
jumps, and, to make things usable, arithmetical and logical operations on scalars and a way of
dividing up code into human-meaningful units or modules . But that's it. Just a thin layer of syntax >
over these.

This. (but your paragraphs are too wide.)

Using this methodology, I've been able to implement my postscript
interpreter portably for Ms Windows or Unix+X11 by treating a window
as an RGB device that needs event handling support.

http://code.google.com/p/xpost

(It also helped a lot to have an Autotools guru actively contributing.)

 

[Thomas Jahns]

Microsoft didn't support C99. Windows was such an important platform that
effectively we had to say that C99 was only for single platform code.

The Intel compiler does support C99 on Windows very well. It's just a question
of buying the compiler that has the features you want. With Microsoft's C
compiler I wouldn't know which that would be, but there's your choice.

Thomas

 

[Kenny McCormack]

The Intel compiler does support C99 on Windows very well. It's just a question
of buying the compiler that has the features you want. With Microsoft's C
compiler I wouldn't know which that would be, but there's your choice.

Thomas

It doesn't matter. Nobody (Yes, this is hyperbole) uses the Intel
compiler.

Like it or not, MS's compilers are like the 800 pound gorilla. What they
do (or don't do) matters. A lot. It's what people follow.

 

[JohnF]

MS's compilers are like the 800 pound gorilla.
It's what people follow.

Off-topic, but what are the pluses/minuses of
the mingw compiler
http://www.mingw.org/
for C programs under windows?
And, while you're at it, also compare and contrast
the dos djgpp if you're familiar with it
http://www.delorie.com/djgpp/
And any other similar compiler.

I try to mostly work under linux, but can't ignore windows,
and use mingw for that platform. Seems fine for my purposes
so far, but I assume there must be some drawbacks/differences
vis-a-vis ms compilers.

 

[Thomas Jahns]

Like it or not, MS's compilers are like the 800 pound gorilla. What they
do (or don't do) matters. A lot. It's what people follow.

I most certainly don't, I'm using pgcc, icc, gcc, xlc and clang on a number of
platforms, all of which support C99 (or will accept a bug-report if some part is
missing). Your 800 pound gorilla looks like some gray-haired, asthmatic animal,
unable to catch up with the herd, to me.

Thomas

 

[Malcolm McLean]

I most certainly don't, I'm using pgcc, icc, gcc, xlc and clang on a number of
platforms, all of which support C99 (or will accept a bug-report if some part is
missing). Your 800 pound gorilla looks like some gray-haired, asthmatic animal,
unable to catch up with the herd, to me.

I don't know where most of my code will have to run. but it's quite likely that someone
will want to run it through Visual Studio at some point.
Currently my main machine is an Apple Mac.

 

[Thomas Jahns]

I don't know where most of my code will have to run. but it's quite likely that someone
will want to run it through Visual Studio at some point.

The Intel compiler comes with VS integration, so wanting to use VS doesn't mean
one is tied to msvc.

Thomas

 

[Keith Thompson]

The Intel compiler comes with VS integration, so wanting to use VS
doesn't mean one is tied to msvc.

True, but there are other reasons one might be tied to MSVC.

I doubt that most programmers really have the luxury of choosing which
compiler will be used to compile their code. I've used Visual Studio
myself at a previous job; picking a different compiler was not an
option.

 

[Kenny McCormack]

Off-topic, but what are the pluses/minuses of
the mingw compiler
http://www.mingw.org/
for C programs under windows?
And, while you're at it, also compare and contrast
the dos djgpp if you're familiar with it
http://www.delorie.com/djgpp/
And any other similar compiler.

Those compilers are good if you've developed your code with Unix/Linux/gcc
and just want a quick port to Windows. Like, for example, when they want
to produce Windows versions of things like AWK, GAWK, Perl, etc. Or things
like cut, join, paste, wc, etc, etc.

But most people are not like us (so it says in The Great Gatsby). They are
coming at it from the other side - they are developing for, by, and on
Windows, so they want a compiler with Windows sensibilities. The MS
compilers are therefore their first (and basically only) choice.

 

[Kenny McCormack]

That's nice. But so what?
Indeed.


Yes. Yes. And? No one cares. The majority use something else.

Very well put.

 

[Kaz Kylheku]

Those compilers are good if you've developed your code with Unix/Linux/gcc
and just want a quick port to Windows. Like, for example, when they want
to produce Windows versions of things like AWK, GAWK, Perl, etc. Or things
like cut, join, paste, wc, etc, etc.

But most people are not like us (so it says in The Great Gatsby). They are
coming at it from the other side - they are developing for, by, and on
Windows, so they want a compiler with Windows sensibilities. The MS
compilers are therefore their first (and basically only) choice.

You can call Windows API's when developing with MinGW.

The C library that is used is Microsoft's; you can make programs that can ship
as nothing but a single .exe file, and run on people's Windows boxes.

What is lacking is a resource compiler for defining dialogs and strings.
Or is it?

Googling slightly: http://www.mingw.org/wiki/MS_resource_compiler

 

[jacob navia]

Le 25/04/2014 20:17, Kenny McCormack a écrit :

Those compilers are good if you've developed your code with Unix/Linux/gcc
and just want a quick port to Windows. Like, for example, when they want
to produce Windows versions of things like AWK, GAWK, Perl, etc. Or things
like cut, join, paste, wc, etc, etc.

lcc-win is another compiler that shouldn't be mentioned in this group.
It supports windows of course, it is written in C and it can produce
double-clickable applications under the windows OS.

I have been flamed so often in this newsgroup for speaking about
lcc-win, that I will never do it again.

I agree that my compiler should be boycotted. It is NGNU (not gnu), nor
is it GPLed and obeys nobody actually. This is not good in this
newsgroup

You should be in some kind of group, trying to get influence, control
whatever. And a NICO (non identified compiling object) is looked upon
with well grounded suspicion I agree. My compiler lcc-win should not be
mentioned in this community of C lovers.

Besides its heretical attitude, my compiler supports operator
overloading, and many improvements (most of them from C++) that make
people that respect standards go nuts.

Sad really, but yes, the boycott is well justified, even from people
like "kenny mccormack" that was kind of critical some time ago.

Yes, times pass but the boycott against lcc-win remains, I agree that
there is no other choice for the C community, and I repeat my promise:

I will not speak about lcc-win again.

One of the worst sins is that it is not msvc compatible since it
supports C99. I remember several discussions about that here.

Of course, even worst is the fact that uses extra precision floats with
132 significant digits. It shouldn't be even mentioned.

All those sins... there is no redemption possible. Kiki will go really
nuts and will swallow his killfile

 

[glen herrmannsfeldt]

(snip)

lcc-win is another compiler that shouldn't be mentioned in this group.
It supports windows of course, it is written in C and it can produce
double-clickable applications under the windows OS.

I don't know about mentioning the compiler, but the book that goes
with it is pretty good. So, without mentioning any compiler:

"A Retargetable C Compiler: Design and Implementation. Addison-Wesley.
ISBN 0-8053-1670-1."

is a good book on understanding how C compilers work, and how
to write one.

-- glen

 

[Malcolm McLean]

You can call Windows API's when developing with MinGW.

The C library that is used is Microsoft's; you can make programs that can ship
as nothing but a single .exe file, and run on people's Windows boxes.

What is lacking is a resource compiler for defining dialogs and strings.
Or is it?

Googling slightly: http://www.mingw.org/wiki/MS_resource_compiler

One of the features of programming is that most programming tools,
applications, interfaces etc have a core functionality which is interesting
from a computer science perspective, and easy enough for someone to program
up in their spare time. That then gets attached to some sort of user
interface, to create something which, in a formal sense, offers a lot
of functionality.

However the soft problems are easily underestimated. If you've got to
download something from the internet, install to a specific directory,
set a path in some sort of configuration file, only to receive a message
that some bit somewhere is misconfigured, then it can easily take all
day to install the tool, and it's not usable in a commercial or consumer
setting (academic programmers and hobbyists can still use it, but even
then, only if particularly committed).

It's hard to make software really nice to use, integrated with the
environment but not falling over when something about that environment is
not as expected, flexible but not getting into a confusing state when
options are set, making it difficult for the user to make mistakes but
not fighting with the user when he really wants to do something
the program disapproves of. Then you've got the standards problem. If
the Evil Corporation is going to respond to your tool by deliberately
making it so that Evil Corporation products break it, then it can be hard
to get enough momentum for the tool to stop them.

 

[Stephen Sprunk]

If the Evil Corporation is going to respond to your tool by deliberately
making it so that Evil Corporation products break it, then it can be hard
to get enough momentum for the tool to stop them.

"DOS isn't done until Lotus won't run."

S

 

[JohnF]

You can call Windows API's when developing with MinGW.
The C library that is used is Microsoft's; you can make programs that can
ship as nothing but a single .exe file, and run on people's Windows boxes.
What is lacking is a resource compiler for defining dialogs and strings.
Or is it?
Googling slightly: http://www.mingw.org/wiki/MS_resource_compiler

Thanks Kenny, Kaz, et al. "Developed with unix/gcc and just want
a quick port to windows" is indeed what I want, and it sounds like
mingw is indeed a good choice for that purpose.