Visual C++ Express Edition or lcc-win32?

[Guy Macon]

Hunh? I am confused. I have left everything you quoted.

Sorry for being unclear. I was referring to the suggestion
you made in this post in comp.arch.embedded:

|
| Message-ID: <[email protected]>
| Date: Thu, 06 Sep 2007 20:15:42 -0400
| From: CBFalconer <[email protected]>
| Newsgroups: comp.arch.embedded
| Subject: Re: 16/32 bit processor for OS development
|
|
| Guy Macon wrote:
| >
| ... snip ...
| >
| > To digress a bit from the original question...
| > One interesting idea that I am just starting to explore is to run
| > FreeBASIC under FreeDOS (It also runs under 32-bit Windows and
| > Linux). What is most interesting about FreeBASIC is that it is
| > written in FreeBASIC, thus making it easy for BASIC programmers
| > to modify/extend the language. I am pretty good at assembly
| > language and modern, structured BASICs, and can find my way
| > around FORTH, but my C/C++ skills are something to be pitied,
| > which means that extending or modifying the OS or the compiler
| > tends to blow up in my face.
|
| Why don't you hang out on comp.lang.c for a while. That will
| probably lick your C abilities into shape quite quickly. We
| attempt to keep the discussions to portable things, i.e. standard
| C. You should rapidly learn who the idiots are.
|
|
|

 

[Chris Hills]

Jerry Coffin said:


The support for C99 in the real world is such that the distinction
between "C90" and "C" is not a useful one.

The MISRA-C team has to make a decision: should it move from Referencing
C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C?

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. There are a lot that are C95+.

Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .

 

[Walter Bright]

Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .

The problem is, nobody using C seems to care about C99 compliance. Or if
they do care, they keep it to themselves.

Digital Mars C is very close to C99 (not perfect), and C99 is what I use
when resolving issues of how things should work, but the demand for it
isn't there.

P.S. I consider demand for a feature being what people will actually pay
money for <g>. I get plenty of features asked for every day from paying
customers, and nobody asks for 100% C99 compliance.

P.P.S. DMC does implement C99 things like complex & imaginary floating
point numbers, VLAs, restrict, variadic macros, unicode, long longs,
long doubles, etc.

 

[CBFalconer]

.... snip ...

The MISRA-C team has to make a decision: should it move from
Referencing C95 (9899:1990+A1+RC1+TC2) to referencing C99 for
the next MISRA-C?

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. There are a lot that are C95+.

Any thoughts from anyone involved in writing compilers? Either to
the NG or to my email address. Yes, I have asked most of the
main embedded compiler companies I have contacts for (about 15 of
them so far) .

Since the C99 standard is easily available, and the C90 is not, I
think MISRA should switch. Their recommended practices can be used
to eliminate C99 features that are not widely implemented. The GNU
C99 report should be an excellent guide.

F'ups set to eliminate silly crossposting.

 

[Greg Comeau]

The MISRA-C team has to make a decision: should it move from Referencing
C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C?

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. There are a lot that are C95+.

Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .

Comeau C99 and Dinkumware C99 lib have both been available for
many years on a number of mainstream platforms. Both companies
also do custom porting with a fairly fast turnaround, and at a
low cost, including to embedded platforms.

As a company involved with compilers, I would go with C99.
It is clear that that standard is in slo-mo, however, the standard
is real, is being adopted incrementally, and is the standard one
normally will get when requesting C from the standards orgs.
C99 will also get a prod as C++ compilers pick up C99 features
(as Comeau C++ has in some C++ modes like variadic macros, long long,
etc ) even if only library ones.

Since IMO MISRA-C is, um, shall I say cautious, I don't think C99
would be a set back to that line of approach.

 

[James Kanze]

[...]

This needs stamping as sarcasm. Nobody sane should accept MS
efforts to divert the normal standardization efforts, especially
ISO standards.

And that's loaded language. The ISO standard (for both C and
C++) is written by those who choose to participate. ISO sets
the rules. MS obviously participates for reasons of its own.
Just as do Sun, IBM and... myself. If you consider any
willingness to invest one's time in the standard an attempt at
diversion, then everyone working on it is diverting it. And
without them, there'd be no standard.

 

[James Kanze]

James Kanze <[email protected]> writes:

[...]> PJP certainly knows the situation better than I do, but my

impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.

[...]

Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

What if it only compiles a subset of C?

Tracking recent standards is certainly an issue, though.

Perhaps I didn't really express myself clearly. From what I
understand (and I could easily be mistaken---I don't follow
developments under Windows very closely), Microsoft only
commercializes a C++ compiler system. That compiler system does
compile some C, for reasons of backwards compatibility, or
interfacing existing systems, or whatever, but it is not sold as
a conforming C compiler, and it makes no attempt to be
conforming. In sum, it's like the bundled C compiler in the
final versions of Sun OS 4.x.

 

[Keith Thompson]

impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.

[...]

Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

What if it only compiles a subset of C?

Tracking recent standards is certainly an issue, though.

Perhaps I didn't really express myself clearly. From what I
understand (and I could easily be mistaken---I don't follow
developments under Windows very closely), Microsoft only
commercializes a C++ compiler system. That compiler system does
compile some C, for reasons of backwards compatibility, or
interfacing existing systems, or whatever, but it is not sold as
a conforming C compiler, and it makes no attempt to be
conforming. In sum, it's like the bundled C compiler in the
final versions of Sun OS 4.x.

My understanding (and I also could be easily mistaken) is that
Microsoft's C compiler conforms quite well to the C90 standard, but
not to the C99 standard. (How they choose to market it is another
matter.)

 

[Jerry Coffin]

[ ... ]

Perhaps I didn't really express myself clearly. From what I
understand (and I could easily be mistaken---I don't follow
developments under Windows very closely), Microsoft only
commercializes a C++ compiler system. That compiler system does
compile some C, for reasons of backwards compatibility, or
interfacing existing systems, or whatever, but it is not sold as
a conforming C compiler, and it makes no attempt to be
conforming. In sum, it's like the bundled C compiler in the
final versions of Sun OS 4.x.

That's incorrect (or at least misleading). Microsoft's compiler runs in
two different modes, one as a C compiler and the other as a C++
compiler. In C mode, it has quite good conformance up through C95, but
little of what was added in C99 is supported. It attempts to conform
quite closely with those standards, and succeeds about as well as most
(i.e. I've seen a few bugs in its implementation, but while I haven't
kept a log of them, I don't recall them being particularly problematic
or frequently encountered).

 

[James Kanze]

[ ... ]

Perhaps I didn't really express myself clearly. From what I
understand (and I could easily be mistaken---I don't follow
developments under Windows very closely), Microsoft only
commercializes a C++ compiler system. That compiler system does
compile some C, for reasons of backwards compatibility, or
interfacing existing systems, or whatever, but it is not sold as
a conforming C compiler, and it makes no attempt to be
conforming. In sum, it's like the bundled C compiler in the
final versions of Sun OS 4.x.

That's incorrect (or at least misleading). Microsoft's compiler runs in
two different modes, one as a C compiler and the other as a C++
compiler. In C mode, it has quite good conformance up through C95, but
little of what was added in C99 is supported. It attempts to conform
quite closely with those standards, and succeeds about as well as most
(i.e. I've seen a few bugs in its implementation, but while I haven't
kept a log of them, I don't recall them being particularly problematic
or frequently encountered).

But is that because they are still trying to sell C, and track
the standard, and just aren't succeeding, or is it because they
no longer consider C relevant to their marketing strategy, and
the current state corresponds more or less to the state the
compiler had when they made this decision. (My own impression
is that nobody in the Windows world uses C any more, but I'll
admit that I don't really know that well what goes on in the
Windows world.)

 

[Jerry Coffin]

[ ... ]

But is that because they are still trying to sell C, and track
the standard, and just aren't succeeding, or is it because they
no longer consider C relevant to their marketing strategy, and
the current state corresponds more or less to the state the
compiler had when they made this decision. (My own impression
is that nobody in the Windows world uses C any more, but I'll
admit that I don't really know that well what goes on in the
Windows world.)

As far as I can tell, it's somewhere between the two -- MS has reduced
the priority on development of the C compiler considerably, but seems to
still make minor updates, at least ocassionally. It IS a bit hard to
tell how much of this is by design and how much is more or less an
accidental by-product of development on the C++ compiler though. In
particular, while each obviously has an independent front-end, I believe
the code-generation and such are shared, and (of course) most of the C
library is used by the C++ compiler as well. Some of the things that
affect the C compiler may really originate with development on the C++
part -- I'm just not sure.

Unless I'm badly mistaken, however, that's substantially different from
the situation with Sun's compilers. If memory serves, the C and C++
compilers they sold for developement were entirely separate from the
ancient C compiler that was included with the OS -- IIRC, updates to the
development system had no effect on the one included with the OS at all.