473,414 Members | 1,609 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,414 software developers and data experts.

Good shareware compiler for C?

H.
I am a student taking a machine structures class in a university, which
includes learning C. I am looking for a good freeware or shareware
compiler which can be used in a "C only" mode. C++ isn't allowed in
assignments, and I would like the compiler to check for C syntax
instead of C++ syntax. Besides that, ease of use for a beginner and
basic debugging capabilities are important.

Suggestions are welcome.

Jan 18 '07
87 3691
In article <ql************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:
>napi wrote, On 22/01/07 04:12:
>H. wrote:
>>I am a student taking a machine structures class in a university, which
includes learning C. I am looking for a good freeware or shareware
compiler which can be used in a "C only" mode. C++ isn't allowed in
assignments, and I would like the compiler to check for C syntax
instead of C++ syntax. Besides that, ease of use for a beginner and
basic debugging capabilities are important.

Suggestions are welcome.

Hi:

You can try AMPC (Axiomatic Multi-Platform C) compiler which supports
ANSI C (1989).

No it does not. According to your web site "AMPC covers a very large
subset of ANSI C (1989)." A large subset is *not* the language defined
It *could* be (noting that "could" is a word frequently used in this ng
as if it meant "is")

Hint: In mathematics, every set is a subset of itself. I.e., the set
itself can be referred to as a subset.

Jan 22 '07 #51

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
[...]
>You need to look into which flags you pass to the compiler -- not only to
make sure you're not using C++, but also to enforce modern type checking,
warnings for stupid beginner's mistakes, to disable compiler-specific
extensions to the language, and to choose the C89 or C99 standard. For
gcc,
a good starting point is

gcc -W -Wall -pedantic -std=c89
or
gcc -W -Wall -pedantic -std=c99

The latter doesn't entirely conform to the C99 standard;
it might or might not be close enough for your purposes.
See <http://gcc.gnu.org/c99status.html>.
Wow, is there a reason that this is *still* not finished?
Jan 22 '07 #52
Serve Laurijssen wrote, On 22/01/07 17:16:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
[...]
>>You need to look into which flags you pass to the compiler -- not only to
make sure you're not using C++, but also to enforce modern type checking,
warnings for stupid beginner's mistakes, to disable compiler-specific
extensions to the language, and to choose the C89 or C99 standard. For
gcc,
a good starting point is

gcc -W -Wall -pedantic -std=c89
or
gcc -W -Wall -pedantic -std=c99
The latter doesn't entirely conform to the C99 standard;
it might or might not be close enough for your purposes.
See <http://gcc.gnu.org/c99status.html>.

Wow, is there a reason that this is *still* not finished?
Yes. No one has put in the work to finish it.
--
Flash Gordon
Jan 22 '07 #53
Serve Laurijssen wrote:
"Keith Thompson" <ks***@mib.orgwrote in message
>Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
.... snip ...
>>>
gcc -W -Wall -pedantic -std=c89
or
gcc -W -Wall -pedantic -std=c99

The latter doesn't entirely conform to the C99 standard;
it might or might not be close enough for your purposes.
See <http://gcc.gnu.org/c99status.html>.

Wow, is there a reason that this is *still* not finished?
Partially because gcc depends on local libraries, which are not
automatically updated, but belong to the individual system. I
believe most things that can be completely handled within the
compiler have been dealt with.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

Jan 22 '07 #54
CBFalconer <cb********@yahoo.comwrites:
Serve Laurijssen wrote:
"Keith Thompson" <ks***@mib.orgwrote in message
Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
... snip ...
>>
gcc -W -Wall -pedantic -std=c89
or
gcc -W -Wall -pedantic -std=c99

The latter doesn't entirely conform to the C99 standard;
it might or might not be close enough for your purposes.
See <http://gcc.gnu.org/c99status.html>.
Wow, is there a reason that this is *still* not finished?

Partially because gcc depends on local libraries, which are not
automatically updated, but belong to the individual system. I
believe most things that can be completely handled within the
compiler have been dealt with.
(This is about a specific compiler, but I claim it's topical because
it's also about the status of the C99 standard.)

Most, but not all. The items that, as far as I can tell, still
require compiler work are:

variable-length arrays
listed as "Broken"
complex (and imaginary) support in <complex.h>
This isn't listed as a library issue; I don't know why.
extended identifiers
Missing
extended integer types in <stdint.h>
Listed as Missing
I'm not sure what this one means. C99 allows, but does not
require, extended integer types. See C99 6.2.5p4. I'm not aware
that gcc provides any extended integer types -- but if it does,
there might be a requirement for <stdint.hto use some of them.
IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
Broken
inline functions
Broken
additional predefined macro names
Missing
I don't know what this refers to; gcc 4.1.1 seems to support all the
names specified in C99 6.10.8. See below for more information.
standard pragmas
Missing
I haven't looked into this.

Here's a program that shows the values of all the required and
optional predefined macros from 6.10.8:

#include <stdio.h>
int main(void)
{

#ifdef __DATE__
puts("__DATE__ = \"" __DATE__ "\"");
#else
printf("__DATE__ is not defined");
#endif

#ifdef __FILE__
puts("__FILE__ = \"" __FILE__ "\"");
#else
printf("__FILE__ is not defined");
#endif

#ifdef __LINE__
printf("__LINE__ = %d\n", (int)__LINE__);
#else
printf("__LINE__ is not defined");
#endif

#ifdef __STDC__
printf("__STDC__ = %d\n", (int)__STDC__);
#else
printf("__STDC__ is not defined");
#endif

#ifdef __STDC_HOSTED__
printf("__STDC_HOSTED__ = %d\n", (int)__STDC_HOSTED__);
#else
printf("__STDC_HOSTED__ is not defined");
#endif

#ifdef __STDC_VERSION__
printf("__STDC_VERSION__ = %ld\n", (long)__STDC_VERSION__);
#else
printf("__STDC_VERSION__ is not defined");
#endif

#ifdef __TIME__
puts("__TIME__ = \"" __TIME__ "\"");
#else
printf("__TIME__ is not defined");
#endif

#ifdef __STDC_IEC_559__
printf("__STDC_IEC_559__ = %d\n", (int)__STDC_IEC_559__);
#else
printf("__STDC_IEC_559__ is not defined");
#endif

#ifdef __STDC_IEC_559_COMPLEX__
printf("__STDC_IEC_559_COMPLEX__ = %d\n", (int)__STDC_IEC_559_COMPLEX__);
#else
printf("__STDC_IEC_559_COMPLEX__ is not defined");
#endif

#ifdef __STDC_ISO_10646__
printf("__STDC_ISO_10646__ = %ld\n", (long)__STDC_ISO_10646__);
#else
printf("__STDC_ISO_10646__ is not defined");
#endif

return 0;
}

And here's the output under gcc 4.1.1:

__DATE__ = "Jan 22 2007"
__FILE__ = "macros.c"
__LINE__ = 18
__STDC__ = 1
__STDC_HOSTED__ = 1
__STDC_VERSION__ = 199901
__TIME__ = "14:35:02"
__STDC_IEC_559__ = 1
__STDC_IEC_559_COMPLEX__ = 1
__STDC_ISO_10646__ = 200009

Possibly the web page doesn't reflect the latest release, and/or
perhaps some of the macro values don't quite reflect reality.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 22 '07 #55
Andrew Gentile a écrit :
Jacob,
I just noticed your post. I have been using your compiler for
about a year. Excellent job. I have recommended it to many friends.
Thanks.

Andrew
Thanks you for this. Nice to see my work is good for someone!

jacob
Jan 22 '07 #56
On 22 Jan 2007 14:33:30 -0800, Keith Thompson <ks***@mib.orgwrote:
CBFalconer <cb********@yahoo.comwrites:
>Serve Laurijssen wrote:
"Keith Thompson" <ks***@mib.orgwrote in message
Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
....
>> gcc -W -Wall -pedantic -std=c99

The latter doesn't entirely conform to the C99 standard;
it might or might not be close enough for your purposes.
See <http://gcc.gnu.org/c99status.html>.
[long snip]
Possibly the web page doesn't reflect the latest release, and/or
perhaps some of the macro values don't quite reflect reality.
They have, oddly enough, one general list and one per major release. I
surely hope those ones are correct, e.g.
http://gcc.gnu.org/gcc-4.1/c99status.html

More on topic: maybe compiler vendors should add options to enable c99
*except* the parts they have enabled but not gotten right? For example:

-std=cdecember98

Only partly joking. There are C99 additions I want to use, but I don't want
to accidentally make myself dependent on compiler-specific features in some
other area.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!
Jan 23 '07 #57
"Serve Laurijssen" <se*@n.tkwrote in message
news:eo**********@news4.zwoll1.ov.home.nl...
"Mark McIntyre" <ma**********@spamcop.netwrote in message
news:do********************************@4ax.com...
>I think the point was more that jn hasn't displayed much interest in
or understanding of the difference between standards compliance, and
platform-specific extensions. My own experience is that drivers who
think red lights and indicating are optional tend to make bad
drivers.

that is only true if platform specific extensions could be compared to
driving through red light. platform specific extensions *are* allowed
so it doesnt make anybody a bad programmer when they use them.

I know a good programmer who uses gcc's extensions a lot. Is gcc bad
for introducing the features or the programmer or nobody?
Not at all. However, if GCC proponents came here and told people to use
their non-standard extensions without identifying them as such, they'd
be smacked down just like Mr. Navia is (on a regular basis).

The GCC people stick to their own newsgroups. On the rare occasions GCC
extensions are proposed by regulars here, they're clearly noted as such.
Mr. Navia has shown absolutely no inclination to follow accepted
netiquette or topicality, despite having been asked several dozen times.
_That_ is why he is disliked, not his extensions. He's welcome to
discuss them all he likes over in the newsgroup for LCC.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

Jan 24 '07 #58


On Jan 22, 4:02 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
napi wrote, On 22/01/07 04:12:
H. wrote:
I am a student taking a machine structures class in a university, which
includes learning C. I am looking for a good freeware or shareware
compiler which can be used in a "C only" mode. C++ isn't allowed in
assignments, and I would like the compiler to check for C syntax
instead of C++ syntax. Besides that, ease of use for a beginner and
basic debugging capabilities are important.
Suggestions are welcome.
Hi:
You can try AMPC (Axiomatic Multi-Platform C) compiler which supports
ANSI C (1989).
No it does not. According to your web site "AMPC covers a very large
subset of ANSI C (1989)." A large subset is *not* the language defined
by the standard, the language defined by the language is *all* of the
language defined by the standard. So if the OP finds that for his course
he is required to use feature X defined by the standard that you do not
currently support do you guarantee to add it to your compiler fast
enough not to cause him problems?
You are right. But, the only ANSI C (1989) library functions that AMPC
does
not support are longjmp(), setjmp(), signal(), and raise(). It
supports all others.

Napi

Jan 24 '07 #59
In article <11**********************@q2g2000cwa.googlegroups. com>,
napi <na**@axiomsol.comwrote:
>
On Jan 22, 4:02 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
>No it does not. According to your web site "AMPC covers a very large
subset of ANSI C (1989)." A large subset is *not* the language defined
by the standard, the language defined by the language is *all* of the
language defined by the standard. So if the OP finds that for his course
he is required to use feature X defined by the standard that you do not
currently support do you guarantee to add it to your compiler fast
enough not to cause him problems?

You are right. But, the only ANSI C (1989) library functions that AMPC
does
not support are longjmp(), setjmp(),
setjmp is a macro, not a function. It seems to me that it shouldn't be
too hard to invoke some compiler magic to compile setjmp/longjmp as a
fairly thin wrapper around try/throw.
signal(), and raise().
Why not those? They should be some of the easiest to implement,
especially since there's no requirement that an implementation be able
to actually generate signals asynchronously.

Here's a first pass at it to get you started.
(Not compiled or tested. The usual disclaimers apply, and then some.)
--------signal.h
#ifndef __SIGNAL_H
#define __SIGNAL_H

/*N869 7.14#1*/
typedef int sig_atomic_t;

/*Make some of the definitions a little bit easier to write*/
typedef void (*__sighandler_t)(int);

/*N869 7.14#3*/
extern __sighandler_t __sig_dfl;
#define SIG_DFL __sig_dfl;
extern __sighandler_t __sig_err;
#define SIG_ERR __sig_err;
extern __sighandler_t __sig_ign;
#define SIG_IGN __sig_ign;

#define SIGABRT 1
#define SIGFPE 2
#define SIGILL 3
#define SIGINT 4
#define SIGSEGV 5
#define SIGTERM 6
#define __MAX_SIGNAL 7

/*N869 7.14.1.1*/
__sighandler_t signal(int,__sighandler_t);

/*N869 7.14.2.1*/
int raise(int);

#endif /*__SIGNAL_H #include guard*/
--------

--------signal_implementation.c
#include <signal.h>
#include <stdlib.h>

void __sig_dfl(int sig)
{
if(sig==SIGTERM || sig==SIGINT)
{
/*termination request or interrupt are typically
not fatal errors
*/
exit(EXIT_SUCCESS);
}
else
{
/*All other signals indicate some fatal error condition*/
exit(EXIT_FAILURE);
}
}

void __sig_err(int sig)
{
/*We should never get here*/
abort();
}

void __sig_ign(int sig)
{
/*do nothing*/
}

static __sighandler_t handlers[]=
{
NULL, /*dummy*/
__sig_dfl, /*SIGABRT*/
__sig_dfl, /*SIGFPE*/
__sig_dfl, /*SIGILL*/
__sig_dfl, /*SIGINT*/
__sig_dfl, /*SIGSEGV*/
__sig_dfl /*SIGTERM*/
};

__sighandler_t signal(int sig,__sighandler_t newhandler)
{
__sighandler_t old_handler=handlers[sig];
handlers[sig]=newhandler;
return old_handler;
}

int raise(int sig)
{
handlers[sig]();
}
--------
Question for the language lawyers: Is this a correct C program?
--------
#include <signal.h>
int main(void)
{
SIG_DFL(SIGTERM);
return 0;
}
--------
I suspect not, but I wouldn't be willing to defend any answer without
further study.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
The ISO C Standard defines the truth in C. Therefore, it makes an excellent
weapon to use in a fight.
--Richard Heathfield in comp.lang.c
Jan 24 '07 #60
Dave Vandervies wrote:
In article <11**********************@q2g2000cwa.googlegroups. com>,
napi <na**@axiomsol.comwrote:

On Jan 22, 4:02 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:

No it does not. According to your web site "AMPC covers a very large
subset of ANSI C (1989)." A large subset is *not* the language defined
by the standard, the language defined by the language is *all* of the
language defined by the standard. So if the OP finds that for his course
he is required to use feature X defined by the standard that you do not
currently support do you guarantee to add it to your compiler fast
enough not to cause him problems?
You are right. But, the only ANSI C (1989) library functions that AMPC
does
not support are longjmp(), setjmp(),

setjmp is a macro, not a function. It seems to me that it shouldn't be
too hard to invoke some compiler magic to compile setjmp/longjmp as a
fairly thin wrapper around try/throw.
signal(), and raise().

Why not those? They should be some of the easiest to implement,
especially since there's no requirement that an implementation be able
to actually generate signals asynchronously.

Here's a first pass at it to get you started.
(Not compiled or tested. The usual disclaimers apply, and then some.)
[...]
--------signal_implementation.c
#include <signal.h>
#include <stdlib.h>

void __sig_dfl(int sig)
{
if(sig==SIGTERM || sig==SIGINT)
{
/*termination request or interrupt are typically
not fatal errors
*/
exit(EXIT_SUCCESS);
<Semi-OT>
If a process exits from SIGTERM or SIGINT, normally it is not
considered to have exited successfully. If you have access to a
Unix-style system (Linux is good enough), try something like 'cat &&
echo success', and then send cat a SIGINT signal, for a simple example.
Or run a tool exiting from SIGTERM as part of any build system; most
will halt afterwards.
</Semi-OT>

[...]
Question for the language lawyers: Is this a correct C program?
--------
#include <signal.h>
int main(void)
{
SIG_DFL(SIGTERM);
return 0;
}
--------
I suspect not, but I wouldn't be willing to defend any answer without
further study.
I suspect it isn't, either. I don't see anything preventing SIG_DFL
from being a null pointer, or a converted pointer to an incompatible
function, or a valid pointer to a non-function.

Jan 24 '07 #61
Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
On 22 Jan 2007 14:33:30 -0800, Keith Thompson <ks***@mib.orgwrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Serve Laurijssen wrote:
"Keith Thompson" <ks***@mib.orgwrote in message
Jorgen Grahn <gr********@snipabacken.dyndns.orgwrites:
...
>>> gcc -W -Wall -pedantic -std=c99

The latter doesn't entirely conform to the C99 standard;
it might or might not be close enough for your purposes.
See <http://gcc.gnu.org/c99status.html>.
[long snip]
>Possibly the web page doesn't reflect the latest release, and/or
perhaps some of the macro values don't quite reflect reality.

They have, oddly enough, one general list and one per major release. I
surely hope those ones are correct, e.g.
http://gcc.gnu.org/gcc-4.1/c99status.html
Well something is not quite synchronised since that document says:

EC 60559 is IEEE 754 floating point. This works if and only if the
hardware is perfectly compliant, but GCC does not define
__STDC_IEC_559__ or implement the associated standard pragmas.

but KT's gcc 4.1.1 output that you snipped had:

__STDC_IEC_559__ = 1

and that is also the result with 4.0.3.

--
Ben.
Jan 24 '07 #62

"Stephen Sprunk" <st*****@sprunk.orgwrote in message
news:45***********************@free.teranews.com.. .
Not at all. However, if GCC proponents came here and told people to use
their non-standard extensions without identifying them as such, they'd be
smacked down just like Mr. Navia is (on a regular basis).

The GCC people stick to their own newsgroups. On the rare occasions GCC
extensions are proposed by regulars here, they're clearly noted as such.
Mr. Navia has shown absolutely no inclination to follow accepted
netiquette or topicality, despite having been asked several dozen times.
_That_ is why he is disliked, not his extensions. He's welcome to discuss
them all he likes over in the newsgroup for LCC.
yes yes, still no reason to say "dont get his products because he is evil
man"
I'd expect people to appreciate when somebody helps the C community a lot by
providing a free windows C compiler with IDE, whether you like him or not.
But whatever, he sometimes kicks against some newsgroups standing rules so
he should buuuuuurn in hell
Jan 24 '07 #63
Serve Laurijssen a écrit :
But whatever, he sometimes kicks against some newsgroups standing rules so
he should buuuuuurn in hell


Yeah...

:-)
Jan 24 '07 #64
In article <ep**********@news3.zwoll1.ov.home.nl>,
Serve Laurijssen <se*@n.tkwrote:
>
"Stephen Sprunk" <st*****@sprunk.orgwrote in message
news:45***********************@free.teranews.com. ..
>Not at all. However, if GCC proponents came here and told people to use
their non-standard extensions without identifying them as such, they'd be
smacked down just like Mr. Navia is (on a regular basis).

The GCC people stick to their own newsgroups. On the rare occasions GCC
extensions are proposed by regulars here, they're clearly noted as such.
Mr. Navia has shown absolutely no inclination to follow accepted
netiquette or topicality, despite having been asked several dozen times.
_That_ is why he is disliked, not his extensions. He's welcome to discuss
them all he likes over in the newsgroup for LCC.

yes yes, still no reason to say "dont get his products because he is evil
man"
Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?

We're not disrecommending his compiler because we think he's evil; we're
disrecommending it because his conduct here raises serious questions about
its utility for those who want to write C and not C-with-navia-extensions.

>I'd expect people to appreciate when somebody helps the C community a lot by
providing a free windows C compiler with IDE, whether you like him or not.
But whatever, he sometimes kicks against some newsgroups standing rules so
he should buuuuuurn in hell
The disservice done by his insistence on treating his extensions as
if they were part of the language and misrepresenting and/or insulting
those who object to the way in which he does so (or disagree with him
on pretty much anything else) outweighs the service done by providing
a compiler.
Either he thinks that he, unlike anybody else who has ever extended
the language, is allowed to insist on acting as if navia-C were
interchangeable with C over the objections of those who point out that it
isn't, or he's just too stupid to recognize the difference; either way,
his contribution falls rather short of being welcome.
dave

[1] That's "right" as in "correct", not as in "opposite of left".
This becomes important when you try to internationalize this sentence.

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Without such written down and agreed it is quite normal for opinions to
differ. Many adults can work out such differences without resorting to
insults. --CBFalconer in comp.programming
Jan 24 '07 #65
Dave Vandervies a écrit :
In article <ep**********@news3.zwoll1.ov.home.nl>,
Serve Laurijssen <se*@n.tkwrote:
>>"Stephen Sprunk" <st*****@sprunk.orgwrote in message
news:45***********************@free.teranews.com ...
>>>Not at all. However, if GCC proponents came here and told people to use
their non-standard extensions without identifying them as such, they'd be
smacked down just like Mr. Navia is (on a regular basis).

The GCC people stick to their own newsgroups. On the rare occasions GCC
extensions are proposed by regulars here, they're clearly noted as such.
Mr. Navia has shown absolutely no inclination to follow accepted
netiquette or topicality, despite having been asked several dozen times.
_That_ is why he is disliked, not his extensions. He's welcome to discuss
them all he likes over in the newsgroup for LCC.

yes yes, still no reason to say "dont get his products because he is evil
man"


Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?
This is a lie. I have explained hundreds of times that my extensions
are 100% compatible with the standard, that does NOT forbid extensions.
This is a lie. I can't explain it yet another time since no matter what
I say this lies will go on.
We're not disrecommending his compiler because we think he's evil; we're
disrecommending it because his conduct here raises serious questions about
its utility for those who want to write C and not C-with-navia-extensions.
This is a lie. There is the -ansic flag that conforms to ansic without
any extensions. Another lie.
>
>>I'd expect people to appreciate when somebody helps the C community a lot by
providing a free windows C compiler with IDE, whether you like him or not.
But whatever, he sometimes kicks against some newsgroups standing rules so
he should buuuuuurn in hell


The disservice done by his insistence on treating his extensions as
if they were part of the language
This extensions are clearly signalled in the documentation and here in
the discussions as extensions. I have never said that the language is
like this,
and the reason for my proposing them here is precisely because they
are not part of the language. But I can say this 1000 times and this
people will go on lying.

and misrepresenting and/or insulting
those who object to the way in which he does so (or disagree with him
on pretty much anything else) outweighs the service done by providing
a compiler.
I try to avoid insults. Not like some others like
mcintyre that treats me of "idiot" in each discussion.

Either he thinks that he, unlike anybody else who has ever extended
the language, is allowed to insist on acting as if navia-C were
interchangeable with C over the objections of those who point out that it
isn't, or he's just too stupid to recognize the difference; either way,
his contribution falls rather short of being welcome.
Then, please you put me in your killfile and then finished ok?
Jan 24 '07 #66
Dave Vandervies wrote:
>
Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?
So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.

More porting problems have been caused by gratuitous use of gcc
extensions than just about anything else. Despite this, I don't see
people saying don't use gcc.

Please keep posts civil, personal insults don't belong here.
Either he thinks that he, unlike anybody else who has ever extended
the language, is allowed to insist on acting as if navia-C were
interchangeable with C over the objections of those who point out that it
isn't, or he's just too stupid to recognize the difference; either way,
his contribution falls rather short of being welcome.
Does he? Can you cite an example?

--
Ian Collins.
Jan 24 '07 #67
Ian Collins <ia******@hotmail.comwrites:
Dave Vandervies wrote:
>>
Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?
So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.
I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming
Jan 24 '07 #68
Ben Pfaff wrote:
Ian Collins <ia******@hotmail.comwrites:

>>Dave Vandervies wrote:
>>>Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?

So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.


I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.
Maybe I'm getting forgetful in my old age, but I thought Jacob qualifies
his extensions with something like "the lcc implementation of..." when
first mentioning them on a thread.

--
Ian Collins.
Jan 24 '07 #69
On Thu, 25 Jan 2007 11:01:56 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>Please keep posts civil, personal insults don't belong here.
I agree. You might want to mention that to JN, next time he starts
ranting at Keith or Richard.
(Dave V said)
>Either he thinks that he, unlike anybody else who has ever extended
the language, is allowed to insist on acting as if navia-C were
interchangeable with C over the objections of those who point out that it
isn't, or he's just too stupid to recognize the difference; either way,
his contribution falls rather short of being welcome.
Does he? Can you cite an example?
Pick virtually any thread of JN's and it will quite shortly
demonstrate this. The general model is to propose something offtopic,
be advised of this, and then drop into rant mode claiming it _is_
topical because he wants it to be, that C will die unless he's allowed
his say, that people arguing for topicality are bigots, and so forth.
At some point he'll enter into a flame war with several of the
regulars here, involving him suggesting they're too stupid and
hidebound to understand the complicated modern ideas he has, and them
being highly sarcastic in return.

If you've not spotted it I can noly assume you aren't following the
threads beyond the first post. :)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jan 24 '07 #70
On Wed, 24 Jan 2007 22:44:00 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>I try to avoid insults.
Really? I hadn't noticed.
>Not like some others like
mcintyre that treats me of "idiot" in each discussion.
Remember what Forrest Gump said.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jan 24 '07 #71
Mark McIntyre wrote:
On Thu, 25 Jan 2007 11:01:56 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:
>>Please keep posts civil, personal insults don't belong here.

I agree. You might want to mention that to JN, next time he starts
ranting at Keith or Richard.
I will!
>
>>(Dave V said)
>>>Either he thinks that he, unlike anybody else who has ever extended
the language, is allowed to insist on acting as if navia-C were
interchangeable with C over the objections of those who point out that it
isn't, or he's just too stupid to recognize the difference; either way,
his contribution falls rather short of being welcome.

Does he? Can you cite an example?

Pick virtually any thread of JN's and it will quite shortly
demonstrate this. The general model is to propose something offtopic,
be advised of this, and then drop into rant mode claiming it _is_
topical because he wants it to be, that C will die unless he's allowed
his say, that people arguing for topicality are bigots, and so forth.
At some point he'll enter into a flame war with several of the
regulars here, involving him suggesting they're too stupid and
hidebound to understand the complicated modern ideas he has, and them
being highly sarcastic in return.

If you've not spotted it I can noly assume you aren't following the
threads beyond the first post. :)
But it's the first post that matters, that's where the extension is
qualified, what follows often degenerates into a slanging match.

--
Ian Collins.
Jan 24 '07 #72
Ben Pfaff a écrit :
Ian Collins <ia******@hotmail.comwrites:

>>Dave Vandervies wrote:
>>>Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?

So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.


I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.
This is a lie. I have never shown my extensions as being
part oif the language.

The people of gcc do not discuss anything about C.

C is dead for them and it is maintained for compatibility
reasons, but all their effort is for C++.

The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.
Jan 25 '07 #73
Ian Collins a écrit :
Ben Pfaff wrote:
>>Ian Collins <ia******@hotmail.comwrites:
>>>Dave Vandervies wrote:
Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?
So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.


I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.


Maybe I'm getting forgetful in my old age, but I thought Jacob qualifies
his extensions with something like "the lcc implementation of..." when
first mentioning them on a thread.
I have always done that. In the documentation I have tried
to document each extension as such.

Jan 25 '07 #74
jacob navia wrote:
>
The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.
Take care, some of you extensions are heading that way :)
--
Ian Collins.
Jan 25 '07 #75
Ian Collins a écrit :
jacob navia wrote:
>>The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.


Take care, some of you extensions are heading that way :)
The whole thing is to see when you STOP.

In general the dividing line between C and C++ is
the object oriented approach. C is NOT "object oriented", and
as a NON object oriented language it has a bright future.

The object oriented hype has been forced into the
software construction process, even if it is not the
best approach in many cases. By making C a safer language
and improving the expressivity of the language an
alternative to the OO aproach emerges.

Another important point is that we have the experience of
C++, and for instance in the operator overloading approach
we can avoid pitfalls like allowing to overload the
"&&" or "||" operators... something every C++ book tries to
explain to novices: Do not do that.

Well, it is easier if the language does NOT allow the overloading
of "&&" or "||".
Jan 25 '07 #76
jacob navia wrote:
Ian Collins a écrit :
>jacob navia wrote:
>>The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.

Take care, some of you extensions are heading that way :)


The whole thing is to see when you STOP.
Some would argue that the C99 committee didn't and that's why the
standard hasn't gained a wider acceptance. Any extension to the
language has to be accepted by the (conservative) C community well
before it is considered for standardisation. Which in practice means
being added to gcc. Thus any extension that is part of C++ will never
be added to gcc's C compiler, because people can just use its C++ mode
and get what they want.

So you are probably flogging a dead horse when it comes to operator
overloading in C.

--
Ian Collins.
Jan 25 '07 #77
jacob navia wrote:
This is a lie. I have never shown my extensions as being
part oif the language.

The people of gcc do not discuss anything about C.

C is dead for them and it is maintained for compatibility
reasons, but all their effort is for C++.
Then why is C99 (slowly) being implemented in gcc at all?
The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.
Even if you refuse to count other lcc-based projects, I can think of
some others:
<http://www.ten15.org/(this one does contain a C++ mode, but it is
so severely lacking that I cannot call it a C++ compiler, and no
efforts to improve its C++ mode are made at this time)
<http://nwcc.sourceforge.net/>
<http://www.cs.vu.nl/ack/>

Jan 25 '07 #78

jacob navia wrote:
Ben Pfaff a écrit :
Ian Collins <ia******@hotmail.comwrites:

>Dave Vandervies wrote:

Would you get in a car driven by somebody who thought driving on the
right[1] side of the road was optional?
If not, why would you use a compiler written by somebody who thought
that following the definition of the language is optional?
So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.

I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.

This is a lie. I have never shown my extensions as being
part oif the language.

The people of gcc do not discuss anything about C.

C is dead for them and it is maintained for compatibility
reasons, but all their effort is for C++.

The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.
Don't be too quick in jumping to conclusions. There's also PellesC,
based on the same frontend as lcc-win32.

<http://www.smorgasbordet.com/pellesc/>

Jan 25 '07 #79
"santosh" <sa*********@gmail.comwrote:
jacob navia wrote:
The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.

Don't be too quick in jumping to conclusions. There's also PellesC,
based on the same frontend as lcc-win32.

<http://www.smorgasbordet.com/pellesc/>
Back end, surely?

Richard
Jan 25 '07 #80
santosh a écrit :
jacob navia wrote:
>>Ben Pfaff a écrit :
>>>Ian Collins <ia******@hotmail.comwrites:

Dave Vandervies wrote:
>Would you get in a car driven by somebody who thought driving on the
>right[1] side of the road was optional?
>If not, why would you use a compiler written by somebody who thought
>that following the definition of the language is optional?
>

So you'd say the same about the authors of gcc? Both compilers have
their standard mode (includes extensions) and ANSI modes.
I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.

This is a lie. I have never shown my extensions as being
part oif the language.

The people of gcc do not discuss anything about C.

C is dead for them and it is maintained for compatibility
reasons, but all their effort is for C++.

The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.


Don't be too quick in jumping to conclusions. There's also PellesC,
based on the same frontend as lcc-win32.

<http://www.smorgasbordet.com/pellesc/>
Surely not the same front end since I have rewritten completely
the front end for C99. Pelles C is strictly C89.

The back end is from lcc 4.1, and the back end of lcc-win32 is
completely different, all completely rewritten.

jacob
Jan 25 '07 #81
Richard Bos wrote:
"santosh" <sa*********@gmail.comwrote:
jacob navia wrote:
The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.
Don't be too quick in jumping to conclusions. There's also PellesC,
based on the same frontend as lcc-win32.

<http://www.smorgasbordet.com/pellesc/>

Back end, surely?
jacob will hopefully correct any mistakes, but as far as I know, lcc,
(as written by Fraser and Hanson), is both a front-end and back-end,
the latter for several targets. Apparently, jacob has significantly
modified the back-end for x86, and written a set of tools like code
editor, project manager and others to encapsulate the compile, assemble
and link process.

Jan 25 '07 #82
jacob navia wrote:
santosh a écrit :
jacob navia wrote:
<snip>
>The problem with me is that I develop the only C compiler
that is NOT a C++ compiler.

Don't be too quick in jumping to conclusions. There's also PellesC,
based on the same frontend as lcc-win32.

<http://www.smorgasbordet.com/pellesc/>

Surely not the same front end since I have rewritten completely
the front end for C99. Pelles C is strictly C89.

The back end is from lcc 4.1, and the back end of lcc-win32 is
completely different, all completely rewritten.
In that case I apologise to you and Richard Bos for the misinformation.
I'd been under the impression that you'd only modified the back-end.

Incidentally, the PellesC home page claims to have implemented "most"
of C99.

Jan 25 '07 #83
jacob navia wrote:
Ben Pfaff a écrit :
.... snip ...
>>
I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.

This is a lie. I have never shown my extensions as being
part oif the language.
Calling every minor disagreement or misconstruance a lie is not
gaining you any friends. Maybe you should set your spellchecker to
flag "lie".

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Jan 25 '07 #84
In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>jacob navia wrote:
>Ben Pfaff a écrit :
... snip ...
>>>
I don't see the authors of GCC posting here without properly
distinguishing between standard features and extensions. I have
seen Jacob do that numerous times.

This is a lie. I have never shown my extensions as being
part oif the language.

Calling every minor disagreement or misconstruance a lie is not
gaining you any friends. Maybe you should set your spellchecker to
flag "lie".
Who would want to be friends with a turd like you?

I think you seriously overestimate your importance.

Jan 25 '07 #85
santosh a écrit :
Incidentally, the PellesC home page claims to have implemented "most"
of C99.
Yes. I have checked some constructs and it implements several, probably
most as youy say.
Jan 25 '07 #86
On Sat, 20 Jan 2007 22:48:14 -0500, "Chris Saunders"
<ev**@mountaincable.netwrote:
>Sorry, but I insist on "top posting".
When I clear phlem, I insist on spitting. In Singapore I spit out my
phlem, was arrested, then caned. I told them sternly that "I insist
on spitting". They didn't care and caned me anyway as per their
*local customs, conventions, and law*.

*PLONK*

--
Dan Henry
Jan 26 '07 #87
In article <hv********************************@4ax.com>,
Dan Henry <us****@danlhenry.comwrote:
>On Sat, 20 Jan 2007 22:48:14 -0500, "Chris Saunders"
<ev**@mountaincable.netwrote:
>>Sorry, but I insist on "top posting".

When I clear phlem, I insist on spitting. In Singapore I spit out my
phlem, was arrested, then caned. I told them sternly that "I insist
on spitting". They didn't care and caned me anyway as per their
*local customs, conventions, and law*.
And you loved every minute of it.

Jan 26 '07 #88

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.