473,756 Members | 1,810 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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 3819
In article <ql************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwro te:
>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.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...
Jorgen Grahn <gr********@sni pabacken.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.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...
>Jorgen Grahn <gr********@sni pabacken.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.orgw rote in message
>Jorgen Grahn <gr********@sni pabacken.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********@yah oo.comwrites:
Serve Laurijssen wrote:
"Keith Thompson" <ks***@mib.orgw rote in message
Jorgen Grahn <gr********@sni pabacken.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_HOS TED__);
#else
printf("__STDC_ HOSTED__ is not defined");
#endif

#ifdef __STDC_VERSION_ _
printf("__STDC_ VERSION__ = %ld\n", (long)__STDC_VE RSION__);
#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_1064 6__
printf("__STDC_ ISO_10646__ = %ld\n", (long)__STDC_IS O_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_1064 6__ = 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_Keit h) 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.orgw rote:
CBFalconer <cb********@yah oo.comwrites:
>Serve Laurijssen wrote:
"Keith Thompson" <ks***@mib.orgw rote in message
Jorgen Grahn <gr********@sni pabacken.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.dyn dns.org R'lyeh wgah'nagl fhtagn!
Jan 23 '07 #57
"Serve Laurijssen" <se*@n.tkwrot e in message
news:eo******** **@news4.zwoll1 .ov.home.nl...
"Mark McIntyre" <ma**********@s pamcop.netwrote in message
news:do******** *************** *********@4ax.c om...
>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.ukwro te:
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************ **********@q2g2 000cwa.googlegr oups.com>,
napi <na**@axiomsol. comwrote:
>
On Jan 22, 4:02 pm, Flash Gordon <s...@flash-gordon.me.ukwro te:
>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,__si ghandler_t);

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

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

--------signal_implemen tation.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_SUCCE SS);
}
else
{
/*All other signals indicate some fatal error condition*/
exit(EXIT_FAILU RE);
}
}

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,__sighandle r_t newhandler)
{
__sighandler_t old_handler=han dlers[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

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.