A good compiler

[Chris Hills]

[snips]

My company wants to modfiy Gcc and supply it without releasing aNy of
the source that's OK right?

Nope.

So Gcc has a restrictive license then....

Are you making money off the process? If so, you should stop; this is not
an advertising medium.

Why is making money the only criteria here? The OP asked for a good
compiler for windows. Being free was not given as a requirement.

As it happens I don't sell any MS products. However MS VC 2005 E can be
used to support some software source code I do sell but is not
essential.

So for the OP: Lcc is a valid choice as much as gcc or MS VC 2005 E.....
ALL of which he can download for FREE and try out.

If the then wants gcc for free that is OK. It is also OK if he decided
to go for one of the 6000 USD compilers too. Or any in between even lcc.

So why this religious fanaticism against lcc but nothing else? It is
on FREE download for eval just like may other compilers.

I have recommended both free and commercial compilers. It depends onthe
application. However I do note that many FOSS devotees will recommend
gcc no matter what the situation.

 

[Richard Heathfield]

Chris Hills said:

You are equivocating but like most FOSS devotees are blind to a
balanced argument.

Let's see whether you can see my balanced argument, then: we should have
no gcc advertisements in comp.lang.c, no lcc advertisements, no VC
advertisements, no Borland advertisements - in short, no compiler
advertisements at all. In fact, no advertisements of any kind - except
in properly constructed sig blocks, so that good newsreaders can spot
them and remove them automatically from followups.

(I note from comp.std.c, where my killfile was a little tardy in
blocking Mr Navia, that he has started putting a link to his site at
the bottom of every article. Now all he has to do is learn about sig
block delimiters. Sheesh - netiquette should take a few days or, at
most, weeks to learn. Not nine years.)

Where were we? Oh yes. C discussions are topical here. Compiler
advertisements are not.

Where a compiler recommendation is requested, that is a not unreasonable
question for comp.lang.c, but anyone with a financial or religious axe
to grind ought either to stay out of that discussion or at the very
least to declare their interest.

Frankly, I couldn't care less which compiler I use. On my C resources
Web page, I list several free compilers and several non-free compilers,
and I have no financial or religious interest in any of them. I like
some of them, sure, but I'm not interesting in compiler proselytism.
Any compiler that conforms at least to C90 will do fine for me.

So my own recommendation to the OP is that he finds at least two
compilers conforming to ISO/IEC 9899 (any version), each from a
different provider, and that he tests all his code on both. If one of
the compilers can be installed only on a mainframe, so much the better.

 

[Chris Hills]

Chris Hills said:



Let's see whether you can see my balanced argument, then: we should have
no gcc advertisements in comp.lang.c, no lcc advertisements, no VC
advertisements, no Borland advertisements - in short, no compiler
advertisements at all. In fact, no advertisements of any kind - except
in properly constructed sig blocks, so that good newsreaders can spot
them and remove them automatically from followups.
OK

(I note from comp.std.c, where my killfile was a little tardy in
blocking Mr Navia, that he has started putting a link to his site at
the bottom of every article. Now all he has to do is learn about sig
block delimiters. Sheesh - netiquette should take a few days or, at
most, weeks to learn. Not nine years.)

Point taken. Perhaps if Navia puts it in his sig that will stop everyone
complaining ad infinitum. Then of course he advertises it in EVERY post
not just the ones where it is relevant.

Where were we? Oh yes. C discussions are topical here. Compiler
advertisements are not.

The OP asked for compiler recommendations.

Where a compiler recommendation is requested, that is a not unreasonable
question for comp.lang.c, but anyone with a financial or religious axe
to grind ought either to stay out of that discussion or at the very
least to declare their interest.

Declare an interest I agree. However this is as you say not just
financial interests.

So my own recommendation to the OP is that he finds at least two
compilers conforming to ISO/IEC 9899 (any version), each from a
different provider, and that he tests all his code on both.

That's reasonable

 

[Richard Heathfield]

Chris Hills said:

Heathfield <[email protected]> writes

Point taken. Perhaps if Navia puts it in his sig that will stop
everyone complaining ad infinitum. Then of course he advertises it in
EVERY post not just the ones where it is relevant.

That's entirely up to him, and nobody can reasonably complain about the
contents of a conforming sig block, introduced by a "-- \n" and
continuing for no more than four lines thereafter - no matter what
advertisements it contains. You link to your Web site in your sig
block, and I link to mine in mine. That's what they're for.

And you're right - then he'd be advertising lcc-win32 in every article
he posts. All he would then have to learn (apart from C, of course) is
how to avoid plugging it within the *body* of the article.

<snip>

 

[Richard]

And you're right - then he'd be advertising lcc-win32 in every article
he posts. All he would then have to learn (apart from C, of course) is

You really can not help yourself can you? You really are terribly
snide for someone who promotes himself as a charitable institution here
for the good of the C programming community.

how to avoid plugging it within the *body* of the article.

<snip>

Just to remind you again, the OP asked for compiler recommendations.

 

[jacob navia]

You really can not help yourself can you? You really are terribly
snide for someone who promotes himself as a charitable institution here
for the good of the C programming community.


Just to remind you again, the OP asked for compiler recommendations.

Leave it Richard, this guy is not worth the typing effort of answering
his rants

 

[Michal Nazarewicz]

You keep using that word "FOSS". What, if anything, does it mean?

Free/Open Source Software

 

[Shadowman]

[snips]

It goes beyond your comprehension that strcpy is unsafe by design?

It is? Hmm. News to me. I've been using it for, well, 20 years give or
take, never had an issue with it. Wonder why that is?

Oh, yes - because, as with all tools, I learned how to use it properly.

strcpy is no more or less safe than most other functions, when used
properly. When used improperly, well, what do you expect if you let a
semi-educated chimp write code?

Good point, but there are unfortunately quite a few semi-educated chimps
out there writing code. I suppose one could argue the warning is
there in hope that those who need it would try to find out *why* strcpy
is unsafe or how to use it properly. Or perhaps they'd just be
persuaded to use strcpy_s or gets_s as an alternative. Better than just
blindly churning out bad code -- not everyone's an expert, I'm afraid.

For those of us who already know better, we can just suppress or ignore
that particular warning, right?

 

[santosh]

You keep using that word "FOSS". What, if anything, does it mean?

Free and Open Source Software

Two quite different categories glued together for PR purposes.

 

[Chris Hills]

the requirements, i.e. be capable of learning. The description is
easily found in N869, harder in N1124 (because that is in .pdf
format).

Which ISO standard is that one?

 

[Chris Hills]

You keep using that word "FOSS". What, if anything, does it mean?

Free Open Source Software apparently. No my acronym but one used by the
open source crowd

 

[Chris Hills]

As a matter of fact, YES. What you can't do is supply the revised
gcc elsewhere without releasing your source modifications. Your
internal use of it is up to you. Do read the GPL license some day.

I didn't say internal.

So I can't modify/adapt etc the FOSS SW and issue it without disclosing
the source.

 

[Kelsey Bjarnason]

[snips]

Good point, but there are unfortunately quite a few semi-educated chimps
out there writing code.

There are, indeed.

I suppose one could argue the warning is
there in hope that those who need it would try to find out *why* strcpy
is unsafe or how to use it properly. Or perhaps they'd just be
persuaded to use strcpy_s or gets_s as an alternative. Better than just
blindly churning out bad code -- not everyone's an expert, I'm afraid.

For those of us who already know better, we can just suppress or ignore
that particular warning, right?

I think the problem with this - for me, at least - is it's attempting to
do the Wrong Thing, yet make it appear to be the Right Thing.

One can try to make a language "safe", remove all the potentially risky
constructs, check and validate everything, hand-hold at every possible
opportunity and so forth, but what is the result of this?

I tend to think it's going to be a lot of even *worse* code, written by
people who rely on the compiler or language to spot the flaws rather than
applying good practices, while the actual good programmers get stuck with
tools that, once useful, are now crippled to the point of uselessness.

You can't prevent bad coders writing bad code; you *can*, however, make
the languages or tools so bad that good coders can no long write good code
with them.

 

[Kelsey Bjarnason]

[snips]

Why is making money the only criteria here?

Spam is unwelcome everywhere, and spammers deserve to die slow, painful
deaths. you know, spam... unsolicited commercial posts, such as, oh,
advertising products you have a financial interest in?

'Sides, who'd want a tool - compiler or otherwise - produced by such a
degenerate lowlife they have to resort to spam in the first place? Not
like you could ever trust it; they've demonstrated they have no morals, no
ethics, no concern for others.

 

[Keith Thompson]

In which case they should probably avoid lcc-win32 like the plague,
considering its many unusual (and standards contravening)
extensions. I may well be mistaken in this.

I believe you are. My understanding is that lcc-win32 provides a
command-line option that causes it conform to C90 and another that
*nearly* causes it to conform to C99 (some features are not
implemented). Furthermore, I think that at least some of its
extensions are done in a conforming manner, i.e., they don't affect
the behavior of any strictly conforming program; nevertheless, I think
that the above-mentioned command-line options disable those
extensions.

(This is based on what I've read; I don't actually use lcc-win32, so
don't take my word for all this.)

This is quite similar to what gcc and other compilers do, and there's
no good reason to object to it. Most compilers are not conforming by
default; most compilers are conforming (modulo bugs and the occasional
unimplemented feature) in some mode.

The problem, of course, is ... well, we've already pounded that into
the ground quite enough in this thread.

 

[jacob navia]

[snips]

Good point, but there are unfortunately quite a few semi-educated chimps
out there writing code.

There are, indeed.

I suppose one could argue the warning is
there in hope that those who need it would try to find out *why* strcpy
is unsafe or how to use it properly. Or perhaps they'd just be
persuaded to use strcpy_s or gets_s as an alternative. Better than just
blindly churning out bad code -- not everyone's an expert, I'm afraid.

For those of us who already know better, we can just suppress or ignore
that particular warning, right?

I think the problem with this - for me, at least - is it's attempting to
do the Wrong Thing, yet make it appear to be the Right Thing.

One can try to make a language "safe", remove all the potentially risky
constructs, check and validate everything, hand-hold at every possible
opportunity and so forth, but what is the result of this?

I tend to think it's going to be a lot of even *worse* code, written by
people who rely on the compiler or language to spot the flaws rather than
applying good practices, while the actual good programmers get stuck with
tools that, once useful, are now crippled to the point of uselessness.

You can't prevent bad coders writing bad code; you *can*, however, make
the languages or tools so bad that good coders can no long write good code
with them.

This is a valid point of view, but as always in these things, it depends
on many other factors if it is applicable or not.

Why you do not build big systems in assembly language?

Because the abstraction level is so low, that even careful programmers
have a difficult time avoiding mistakes.

Usage of bad tools can be compensated by the programmer, but they will
eventually provoke an error. Eeven if the programmer is good at his/her
job, he/she is human, and hence mistakes are unavoidable.

A good language gives tools that are not foolproof, but that help
avoid mistakes.

Robert Seacord, of CERT, says about strcpy:

(article in Dr Dobbs, Oct 1st, 2005)
<quote>
Standard Library string functions like strcpy() are not considered
secure by today's standards. The Managed String Library is one possible
solution.

Robert C. Seacord is Senior Vulnerability Analyst for CERT/CC and author
of Secure Coding in C and C++ (Addison-Wesley, 2005). He can be reached
at (e-mail address removed).

Strings—such as command-line arguments, environment variables, and
console input—are of special concern in secure programming because they
account for most of the data exchanged between an end user and a
software system. Graphic and web-based applications make extensive use
of text input fields and, because of standards like XML, data exchanged
between programs is increasingly in string form as well. As a result,
weaknesses in string representation, string management, and string
manipulation have led to a broad range of software vulnerabilities and
exploits.

Many of the vulnerabilities in existing C code result from interactions
with standardized library calls that, by today's standards, would no
longer be considered secure (strcpy(), for example). Unfortunately,
because these functions are standard, they continue to be supported and
developers continue to use them—often to detrimental effect.

<end quote>


The article goes on, pointing several of the many bugs you can build
into your code by using strcpy. It makes for a good read.

jacob

 

[Keith Thompson]

[snips]

Why is making money the only criteria here?

Spam is unwelcome everywhere, and spammers deserve to die slow, painful
deaths. you know, spam... unsolicited commercial posts, such as, oh,
advertising products you have a financial interest in?

The usual Usenet definition of "spam" is a post with a Breidbart index
exceeding 20. (Google "Breidbart index" for more information.) That
means essentially the same article being cross-posted or multi-posted
multiple times. Any commercial aspect has nothing to do with it;
posting "Have a nice day!" to 100 newsgroups is spam just as much as
posting "MAKE MONEY FAST!!".

Nothing jacob navia has done comes close to this criterion. I would
argue that much of what he has posted is off-topic, but that doesn't
make it spam.

Commercial postings may themselves be considered unacceptable here,
but not because they're spam.

There is a tendency, I think, to assume that all bad things in a given
field fall into a single category; all Usenet abuse is spam, all
malware is a virus, etc.

If you want to criticize jacob, go ahead (though I suggest, yet again,
doing so only in direct response to posts that you deem worthy of
criticism) -- but please don't weaken the term "spam" by using it
where it doesn't apply.

 

[Chris Hills]

[snips]

Why is making money the only criteria here?

Spam is unwelcome everywhere, and spammers deserve to die slow, painful
deaths. you know, spam... unsolicited commercial posts, such as, oh,
advertising products you have a financial interest in?

That is not the only definition of spam. Spam does not have to be just
commercial

'Sides, who'd want a tool - compiler or otherwise - produced by such a
degenerate lowlife they have to resort to spam in the first place? Not
like you could ever trust it; they've demonstrated they have no morals, no
ethics, no concern for others.

Much the same with many who spam news groups with the answer Linux, gcc
etc no mater how unsuitable it is. However I note that in clc that is
permitted whilst the odd one or two who are not of theFOSS faith get
savaged no matter what.

If the net nannies on here stopped all this persecution and OT rubbish
we would have a much better signal to noise ration. Their OT posts
generate most of the noise.

 

[Richard Heathfield]

Keith Thompson said:

The usual Usenet definition of "spam" is a post with a Breidbart index
exceeding 20.

So what you're saying is that the Breidbard index fails to take into
account multiple different articles all advertising the same product.
If so, it is not a good method for measuring spam.

 

[Richard Bos]

There are, indeed.


I think the problem with this - for me, at least - is it's attempting to
do the Wrong Thing, yet make it appear to be the Right Thing.

True, but the greatest problem is that the educated chimps are not going
to be using strcpy_s() in the first place. strcpy_s() will be used by
people with a bee in their bonnet about security-by-magic; the educated
chimps will keep using strcpy() on uninitialised pointers; intelligent
programmers will continue to use strcpy() safely. Thus, this entire
_s-debacle will be yet another useless bag on the side of C.

Richard