Visual C++ Express Edition or lcc-win32?

[Nimmi Srivastav]

Apologies if my cross posting has offended anyone....

For a pure hobbyist C/C++ programmer, who wants to develop
applications to run on Windows, what would be a better choice to
install: Visual C++ Express 2005 Edition or lcc-win32? Does anyone
have any opinion to share?

Also, is there a C++ compiler akin to lcc-win32?

Thanks,
Nimmi

[Army1987]

On Mon, 03 Sep 2007 12:24:27 -0700, Keith Thompson wrote:

Army1987 <ar******@NOSPAM.itwrites:
[...]

>And in stdint.h you have (except for the comments):
#ifndef __stdint_h__
#define __stdint_h__

[SNIP]

>#define INT8_MIN -128
#define INT16_MIN -32768
#define INT32_MIN -2147483648

[SNIP]

You didn't enclose these in parentheses? C99 7.1.2 says:

Any definition of an object-like macro described in this clause
shall expand to code that is fully protected by parentheses where
necessary, so that it groups in an arbitrary expression as if it
were a single identifier.

I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions, but
unless you've proven that there isn't one, I'd recommend changing the
definitions.

Actually, looking at the syntax it seems that it is impossible to
write such an expression (I would have complained about that, too,
in my post if I had been able to write it), but figuring that out
takes much longer than adding a pair of parentheses, so I don't
think Jacob did that. Also, there could be some way of writing
such an expression which I have overlooked.

--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Army1987]

On Mon, 03 Sep 2007 21:29:23 +0100, Flash Gordon wrote:

Keith Thompson wrote, On 03/09/07 20:24:

>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions, but
unless you've proven that there isn't one, I'd recommend changing the
definitions. (I always fully parenthesize an object-like macro
definition unless it's already a primary expression.)

I can think of an instance where it makes a difference.

int x = 5 INT_MAN;

I would expect the above to be an error, but without the parenthesis it
is valid. What the C standard makes of it is another matter.

(You meant INT_MIN?)

Well, the standard doesn't forbid any program to compile (unless
they contain a #error directive), and the behavior of a program
with syntax errors or constraint violations is, IMO, undefined by
obmission.

--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Army1987]

On Mon, 03 Sep 2007 21:29:23 +0100, Flash Gordon wrote:

Keith Thompson wrote, On 03/09/07 20:24:

>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions, but
unless you've proven that there isn't one, I'd recommend changing the
definitions. (I always fully parenthesize an object-like macro
definition unless it's already a primary expression.)

I can think of an instance where it makes a difference.

int x = 5 INT_MAN;

I would expect the above to be an error, but without the parenthesis it
is valid. What the C standard makes of it is another matter.

(You meant INT_MIN?)

Well, the standard doesn't forbid any program to compile (unless
they contain a #error directive), and the behavior of a program
with syntax errors or constraint violations which happens to
compile is, IMO, undefined by obmission.

--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[John Smith]

Richard Heathfield wrote:

I don't know of any C++ compilers ostensibly written by self-serving
buffoons, but of course it's entirely possible that this is merely
ignorance on my part.

RH is clc's official Jacob Navia baiter -- JS, c.l.c 30 Jul 07

If that is true, I hereby resign the position. I'm
not interested in baiting Mr Navia. -- RH, c.l.c 30 Jul 07

I guess your're just not capable of knowing your own mind or
controlling your own behaviour.

JS

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>

... BOGUS ...

Proof.

Suppose there is a construct where -1 needs a parentheses.

In that case (-1) "..." != -1 "..."

This means that the expression "..." must have a binary operator
that binds more than unary minus to the constant 1.

Unary minus has precedence 15.

Simply because C doesn't have precedence. Read the standard.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

John Smith said:

Richard Heathfield wrote:

>I don't know of any C++ compilers ostensibly written by self-serving
buffoons, but of course it's entirely possible that this is merely
ignorance on my part.

RH is clc's official Jacob Navia baiter -- JS, c.l.c 30 Jul 07

If that is true, I hereby resign the position. I'm
not interested in baiting Mr Navia. -- RH, c.l.c 30 Jul 07

I guess your're just not capable of knowing your own mind or
controlling your own behaviour.

You guess wrong. Mr Navia is in my killfile, so even if I were
interested in baiting him, there wouldn't be any point. But that
doesn't mean I am no longer free to express my opinions.

If I truly wanted to bait Mr Navia, I would first buy shares in Nomex.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[BobR]

Erik Wikström wrote in message...

On 2007-09-04 08:28, Richard Bos wrote:

Dev-C++, then. Unlike either of the ones mentioned by the OP, it is both
free (in the sense of not having to pay for it) and free (in the sense
of not shackling you into its own preferred way of creating programs),
though not Frea (in the sense of chaining you to a Gnu licence, as gcc
does). It's a pretty small download, as well. And it does both C _and_
C++ (though not, AFAIK, C/C++).

In what way dos gcc chain you to GPL, it does not place any restrictions
on the code you write. And I'd just like to point out that Dev-C++ uses
the Mingw gcc.

Nit(FYI): Dev-C++ is an IDE.
You *can* download a package that includes MinGW (the windows
port of GCC (gcc is the 'C' compiler)), and uses that as it's
default. The IDE *can* be configured to use other compilers
(and you can use the GCC from other IDEs).

--
Bob R
POVrookie
- -
Dev-C++ IDE: http://www.bloodshed.net/
MinGW (GNU compiler): http://www.mingw.org/
MinGWStudio http://www.parinyasoft.com/
Code::Blocks http://www.codeblocks.org/

[John Smith]

jacob navia wrote:

Malcolm McLean wrote:

>>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr.. .

>>Nimmi Srivastav wrote:
I am the author of lcc-win32. This is a C compiler that implements
the latest standard C99 under windows. There is a 64 bit version
in the works, and there are 64 and 32 bits versions under linux
and AIX.

Price: Free download. Size: around 5MB. All this is written
in C. Generates very small programs.

If you don't mind me asking, how do you make money on it if you give
the compiler away for free? It doesn't sound like a hobby project.

The project is financed by the paying customers.

I'd be interested in knowing who are your commercial customers.
Would they be willing to comment on their experience with your
compiler?

JS

[mark]

On Sep 3, 12:55 pm, jacob navia <[e-mail]:

Keith Thompson wrote:

Army1987 <[e-mail]:
[...]

And in stdint.h you have (except for the comments):
#ifndef __stdint_h__
#define __stdint_h__

[SNIP]

#define INT8_MIN -128
#define INT16_MIN -32768
#define INT32_MIN -2147483648

[SNIP]

You didn't enclose these in parentheses? C99 7.1.2 says:

....

I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions,

You see?

....

It is not necessary...

Proof.

....

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

--
Mark Williams

[Bo Persson]

Chris Hills wrote:
:: In article <ln************@nuthaus.mib.org>, Keith Thompson
:: <ks***@mib.orgwrites
::: Chris Hills <ch***@phaedsys.orgwrites:
::: [...]
:::: Gcc is not ISO C99 compliant either. (And I think less so than
:::: the MS compilers these days.)
:::
::: Really? My impression, based entirely on what I've read here, is
::: that MS has expressed no interest in supporting C99. Do you have
::: better information?
::
:: PJP said (I think here) that MSVC was now C99 compliant as MS had
:: got religion in the last couple of years and don standards
:: compliant.

It's not C99 compliant. The only religion they follow is there own, so
the compiler fully implements the C++/CLI standard.

::
:: Actually MS is very actively doing a lot in the standards world
:: (usually via ECMA and ruffling a few feathers in ISO)

Setting standards is fun, implementing them not so much. :-)
Bo Persson

[jacob navia]

John Smith wrote:

jacob navia wrote:

>Malcolm McLean wrote:

>>>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr. ..

Nimmi Srivastav wrote:
I am the author of lcc-win32. This is a C compiler that implements
the latest standard C99 under windows. There is a 64 bit version
in the works, and there are 64 and 32 bits versions under linux
and AIX.

Price: Free download. Size: around 5MB. All this is written
in C. Generates very small programs.
If you don't mind me asking, how do you make money on it if you give
the compiler away for free? It doesn't sound like a hobby project.

The project is financed by the paying customers.

I'd be interested in knowing who are your commercial customers. Would
they be willing to comment on their experience with your compiler?

JS

This is actually the result of years of effort calling people,
making demos, traveling around, etc. Please understand that I can't
give this away like this.

If you want references I can give some, but not all. Mathworks is
still distributing my compiler system with their Matlab software.
It is in the distribution CD.

The SmartEiffel compiler uses lcc-win as its back-end.

[Harald van =?UTF-8?B?RMSzaw==?=]

Army1987 wrote:

On Mon, 03 Sep 2007 21:29:23 +0100, Flash Gordon wrote:

>Keith Thompson wrote, On 03/09/07 20:24:

>>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions, but
unless you've proven that there isn't one, I'd recommend changing the
definitions. (I always fully parenthesize an object-like macro
definition unless it's already a primary expression.)

I can think of an instance where it makes a difference.

int x = 5 INT_MAN;

I would expect the above to be an error, but without the parenthesis it
is valid. What the C standard makes of it is another matter.

(You meant INT_MIN?)

Well, the standard doesn't forbid any program to compile (unless
they contain a #error directive), and the behavior of a program
with syntax errors or constraint violations is, IMO, undefined by
obmission.

If a program has a syntax error or a constraint violation, a conforming
implementation is required to diagnose it, and unless there is very strange
compiler magic going on, that won't be possible with the given definition
of INT_MIN.

[Flash Gordon]

Army1987 wrote, On 04/09/07 11:38:

On Mon, 03 Sep 2007 21:29:23 +0100, Flash Gordon wrote:

>Keith Thompson wrote, On 03/09/07 20:24:

>>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions, but
unless you've proven that there isn't one, I'd recommend changing the
definitions. (I always fully parenthesize an object-like macro
definition unless it's already a primary expression.)

I can think of an instance where it makes a difference.

int x = 5 INT_MAN;

I would expect the above to be an error, but without the parenthesis it
is valid. What the C standard makes of it is another matter.

(You meant INT_MIN?)

Yes.

Well, the standard doesn't forbid any program to compile (unless
they contain a #error directive), and the behavior of a program
with syntax errors or constraint violations is, IMO, undefined by
obmission.

The question is whether it is required to produce a diagnostic or not.
With parenthesis a diagnostic is required, without one isn't. I know
that the compiler is still allowed to compile the program, I just would
not expect it to as a matter of quality.
--
Flash Gordon

[jacob navia]

CBFalconer wrote:

jacob navia wrote:
... snip ...

... BOGUS ...

>Proof.

Suppose there is a construct where -1 needs a parentheses.

In that case (-1) "..." != -1 "..."

This means that the expression "..." must have a binary operator
that binds more than unary minus to the constant 1.

Unary minus has precedence 15.

Simply because C doesn't have precedence. Read the standard.

From the standard you make apreceddence table.
Look at the refeerence cited in the text you snipped

[jacob navia]

mark wrote:

On Sep 3, 12:55 pm, jacob navia <[e-mail]:

>Keith Thompson wrote:

>>Army1987 <[e-mail]:
[...]
And in stdint.h you have (except for the comments):
#ifndef __stdint_h__
#define __stdint_h__
[SNIP]
#define INT8_MIN -128
#define INT16_MIN -32768
#define INT32_MIN -2147483648
[SNIP]
You didn't enclose these in parentheses? C99 7.1.2 says:

...

>>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions,

You see?

...

>It is not necessary...

Proof.

...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

--
Mark Williams

You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

[Harald van =?UTF-8?B?RMSzaw==?=]

jacob navia wrote:

mark wrote:

>...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

Then at this point your compiler intentionally does not conform to any
standard, something worth remembering.

[jacob navia]

Harald van Dijk wrote:

jacob navia wrote:

>mark wrote:

>>...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

Then at this point your compiler intentionally does not conform to any
standard, something worth remembering.

Of course.

Now go ahead:

"Jacob Navia said that he will never conform to any standard"

You can store that and quote this nonsense over and over.

It will be no different than the insults of your friend heathfield
(lower case)

[Army1987]

On Tue, 04 Sep 2007 20:45:09 +0200, jacob navia wrote:

CBFalconer wrote:

>jacob navia wrote:
... snip ...

... BOGUS ...

>>Proof.

Suppose there is a construct where -1 needs a parentheses.

In that case (-1) "..." != -1 "..."

This means that the expression "..." must have a binary operator
that binds more than unary minus to the constant 1.

-1[ptr]

>>Unary minus has precedence 15.

Simply because C doesn't have precedence. Read the standard.

From the standard you make apreceddence table.
Look at the refeerence cited in the text you snipped

You can't. Casts bind tighter than unary operators, unary
operators bind tighter than sizeof, and sizeof binds tighter than
casts. Incredible but true. This is useful to prevent
sizeof(int) -1 from being ambiguous, but it is very hard to
explain without the actual syntax.
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Sherm Pendley]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Dev-C++, then. Unlike either of the ones mentioned by the OP, it is both
free (in the sense of not having to pay for it) and free (in the sense
of not shackling you into its own preferred way of creating programs),
though not Frea (in the sense of chaining you to a Gnu licence, as gcc
does). It's a pretty small download, as well. And it does both C _and_
C++ (though not, AFAIK, C/C++).

The GPL is only relevant if your app includes some or all of the source
code of a GPL'd app, as-is or modified. In that case, you'd be obligated
to distribute your app under the GPL.

The GPL has *zero* impact on the output of a GPL'd app. Your app is not
somehow "infected" by the simple act of editing your own code with a GPL'd
IDE, or compiling it with a GPL'd compiler. The idea that it would (or
can) be is pure FUD.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Flash Gordon]

jacob navia wrote, On 04/09/07 19:46:

mark wrote:

>On Sep 3, 12:55 pm, jacob navia <[e-mail]:

>>Keith Thompson wrote:
Army1987 <[e-mail]:
[...]
And in stdint.h you have (except for the comments):
#ifndef __stdint_h__
#define __stdint_h__
[SNIP]
#define INT8_MIN -128
#define INT16_MIN -32768
#define INT32_MIN -2147483648
[SNIP]
You didn't enclose these in parentheses? C99 7.1.2 says:

...

>>>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions,
You see?

...

>>It is not necessary...

Proof.

...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

--
Mark Williams

Jacob, you should know to snip sigs.

You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

In that case your compiler is broken.
x decays to a pointer to int
x+1 is a pointer to int
-1[x+128] is therefore equivalent to *(-1 + (x+128))
Which gives us *(x+127)
Which is perfectly legal.
--
Flash Gordon

[Harald van =?UTF-8?B?RMSzaw==?=]

jacob navia wrote:

Harald van Dijk wrote:

>jacob navia wrote:

>>mark wrote:
...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================
You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

Then at this point your compiler intentionally does not conform to any
standard, something worth remembering.

Of course.

Now go ahead:

"Jacob Navia said that he will never conform to any standard"

I would be lying if I claimed that. You haven't said you won't ever
reconsider this. And I hope you do change your mind and fix your bug.

You can store that and quote this nonsense over and over.

It will be no different than the insults of your friend heathfield
(lower case)

Please do not include me in your fight with Richard Heathfield; I do not
wish to have any part in it.

[Flash Gordon]

jacob navia wrote, On 04/09/07 20:17:

Harald van Dijk wrote:

>jacob navia wrote:

>>mark wrote:
...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================
You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

Then at this point your compiler intentionally does not conform to any
standard, something worth remembering.

This was a valid point. The alternative being that you do not know how
arrays, pointers and array notation work in C.

Of course.

Now go ahead:

"Jacob Navia said that he will never conform to any standard"

You can store that and quote this nonsense over and over.

Or you could fix your compiler and then the complaint would not be valid.

It will be no different than the insults of your friend heathfield
(lower case)

Now you are being deliberately obnoxious to someone not involved in this
discussion.
--
Flash Gordon

[Harald van =?UTF-8?B?RMSzaw==?=]

Flash Gordon wrote:

jacob navia wrote, On 04/09/07 19:46:

>mark wrote:

>>On Sep 3, 12:55 pm, jacob navia <[e-mail]:
Keith Thompson wrote:
Army1987 <[e-mail]:
[...]
>And in stdint.h you have (except for the comments):
>#ifndef __stdint_h__
>#define __stdint_h__
[SNIP]
>#define INT8_MIN -128
>#define INT16_MIN -32768
>#define INT32_MIN -2147483648
[SNIP]
You didn't enclose these in parentheses? C99 7.1.2 says:
...
I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions,
You see?
...
It is not necessary...

Proof.
...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

--
Mark Williams

Jacob, you should know to snip sigs.

>You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

In that case your compiler is broken.
x decays to a pointer to int
x+1 is a pointer to int
-1[x+128] is therefore equivalent to *(-1 + (x+128))
Which gives us *(x+127)
Which is perfectly legal.

No, -1[x+128] is equivalent to -*(1 + (x+128)). There is no compiler bug,
only a header bug. If INT8_MIN is defined as -128, then INT8_MIN expands
to -128[x+128], meaning -(128[x+128]). The standard requires it to expand
to an equivalent of (-128)[x+128].

[Flash Gordon]

Harald van Dijk wrote, On 04/09/07 20:48:

Flash Gordon wrote:

>jacob navia wrote, On 04/09/07 19:46:

>>mark wrote:
On Sep 3, 12:55 pm, jacob navia <[e-mail]:
Keith Thompson wrote:
>Army1987 <[e-mail]:
>[...]
>>And in stdint.h you have (except for the comments):
>>#ifndef __stdint_h__
>>#define __stdint_h__
>[SNIP]
>>#define INT8_MIN -128
>>#define INT16_MIN -32768
>>#define INT32_MIN -2147483648
>[SNIP]
>You didn't enclose these in parentheses? C99 7.1.2 says:
...
>I haven't been able to construct an expression that would be evaluated
>differently with or without parentheses in your macro definitions,
You see?
...
It is not necessary...
>
Proof.
...

Counterexample:

======================
#include <stdint.h>
int x[256];

int foo()
{
INT8_MIN[x + 128] = 0;
}
=======================

--
Mark Williams

Jacob, you should know to snip sigs.

>>You write code like
-1[x+128]=0;

Well, it will not work in lcc-win32

In that case your compiler is broken.
x decays to a pointer to int
x+1 is a pointer to int
-1[x+128] is therefore equivalent to *(-1 + (x+128))
Which gives us *(x+127)
Which is perfectly legal.

No, -1[x+128] is equivalent to -*(1 + (x+128)). There is no compiler bug,
only a header bug. If INT8_MIN is defined as -128, then INT8_MIN expands
to -128[x+128], meaning -(128[x+128]). The standard requires it to expand
to an equivalent of (-128)[x+128].

Yes, I got my expansion wrong. My only excuse is that I would never
write code like that anyway ;-).

Jacob still has a bug to fix if he wants to claim to conform to any C
standard in any mode.
--
Flash Gordon

[jacob navia]

Flash Gordon wrote:

Jacob still has a bug to fix if he wants to claim to conform to any C
standard in any mode.

Well you win. I will add those parentheses!!!
What a discussion for 2 bytes more.

OK: I was WRONG, completely and utterly WRONG. There is
no other solution than to ADD those dammed parentheses!!!

:-)

Thanks for your help guys. But something still bothers me.

Chuck Falconer says (and then I think Flash Gordon proved) that
there can't be a table of precedences for operators
like that one in Harbison and Steele "C a reference manual".

Everybody confirms that? I mean H & S is *THE* reference
manual. How could they have done SUCH a huge mistake?

jacob

[Flash Gordon]

jacob navia wrote, On 04/09/07 21:12:

Flash Gordon wrote:

>Jacob still has a bug to fix if he wants to claim to conform to any C
standard in any mode.

Well you win. I will add those parentheses!!!
What a discussion for 2 bytes more.

OK: I was WRONG, completely and utterly WRONG. There is
no other solution than to ADD those dammed parentheses!!!

:-)

Well, you can still claim to be conforming to a C standard modulo bugs then.

Thanks for your help guys. But something still bothers me.

Chuck Falconer says (and then I think Flash Gordon proved) that

No, it wasn't me.

there can't be a table of precedences for operators
like that one in Harbison and Steele "C a reference manual".

Everybody confirms that? I mean H & S is *THE* reference
manual. How could they have done SUCH a huge mistake?

H&S is not *THE* reference manual, just a well respected reference
manual. It could have errors, but I've not looked deeply enough to see
if this is one or whether they cover it in the text.
--
Flash Gordon

[jacob navia]

Flash Gordon wrote:

jacob navia wrote, On 04/09/07 21:12:

>Flash Gordon wrote:

>>Jacob still has a bug to fix if he wants to claim to conform to any C
standard in any mode.

Well you win. I will add those parentheses!!!
What a discussion for 2 bytes more.

OK: I was WRONG, completely and utterly WRONG. There is
no other solution than to ADD those dammed parentheses!!!

:-)

Well, you can still claim to be conforming to a C standard modulo bugs
then.

>Thanks for your help guys. But something still bothers me.

Chuck Falconer says (and then I think Flash Gordon proved) that

No, it wasn't me.

>there can't be a table of precedences for operators
like that one in Harbison and Steele "C a reference manual".

Everybody confirms that? I mean H & S is *THE* reference
manual. How could they have done SUCH a huge mistake?

H&S is not *THE* reference manual, just a well respected reference
manual. It could have errors, but I've not looked deeply enough to see
if this is one or whether they cover it in the text.

It was Army1987. His proof was:

Casts bind tighter than unary operators, unary
operators bind tighter than sizeof, and sizeof binds tighter than
casts. Incredible but true. This is useful to prevent
sizeof(int) -1 from being ambiguous, but it is very hard to
explain without the actual syntax.

[CBFalconer]

Erik Wikström wrote:

>

.... snip ...

>
Personally I prefer Visual C++ 2005 Express since it is free, (in
the sense of not having to pay for it) and free (in the sense of
not shackling you into its own preferred way of creating programs).
And it has got the best debugger I've ever used (not that I have
used that many, but it beats gdb).

Please explain how gcc 'shackles you'. Or gdb.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
I am the author of lcc-win32. This is a C compiler that implements
the latest standard C99 under windows.

Less completely than gcc does.

.... snip ...

Price: Free download. Size: around 5MB. All this is written
in C. Generates very small programs.

Amazing claim. I find that code generated by gcc is significantly
smaller.

Also note that I (and all others) am perfectly free to download and
examine and/or modify the gcc code at any time. This does not
apply to lcc-win32.

I have removed the ridiculous cross-posts with the follow-up.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Mark McIntyre]

On Tue, 04 Sep 2007 22:12:48 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Everybody confirms that? I mean H & S is *THE* reference
manual. How could they have done SUCH a huge mistake?

You seem to have an enormous difficulty understanding the difference
between being infallible and being generally right.

This seems to extend right across your postings: you paint everything
in total black and white, especially the opinoins of others - if they
agree with you, they're geniuses and self-effacing; if they disagree
with you they're dunces and egomaniacs.

Remember, Caesar, thou art but a man.
--
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

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Keith Thompson wrote:

>Army1987 <ar******@NOSPAM.itwrites:
[...]

>>And in stdint.h you have (except for the comments):
#ifndef __stdint_h__
#define __stdint_h__

[SNIP]

>>#define INT8_MIN -128
#define INT16_MIN -32768
#define INT32_MIN -2147483648

[SNIP]
You didn't enclose these in parentheses? C99 7.1.2 says:
Any definition of an object-like macro described in this clause
shall expand to code that is fully protected by parentheses where
necessary, so that it groups in an arbitrary expression as if it
were a single identifier.

Where necessary.

>I haven't been able to construct an expression that would be evaluated
differently with or without parentheses in your macro definitions,

You see?

It is not necessary...

That may well be true, but my failure to come up with an example
certainly doesn't prove it.

>but
unless you've proven that there isn't one, I'd recommend changing the
definitions. (I always fully parenthesize an object-like macro
definition unless it's already a primary expression.)

Proof.

Suppose there is a construct where -1 needs a parentheses.

In that case (-1) "..." != -1 "..."

This means that the expression "..." must have a binary operator
that binds more than unary minus to the constant 1.

Unary minus has precedence 15.

But ALL operators at level 15 are UNARY operators. There are
NO binary operators at level 15.

Remains level 16, with . (point) function call ,
increment decrement, and indexing.

All those operations can't use a manifest constant like 1
or 447766.

Q.E.D

Reference: Harbison and Steele. "C, a reference manual"
See the table of precedences.

H&S (5th edition, right?) is an excellent book, but I'm not convinced
by any proof that's not based on the standard -- and you shouldn't be
either.

We've already seen in this thread an example where the lack of
parentheses can cause the compiler to fail to diagnose a syntax error.

I'm still not convinced that the definition without parentheses is
legal. I *am* convinced that just adding the parentheses would be a
heck of a lot easier than proving that they're not necessary.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Flash Gordon wrote:

>Jacob still has a bug to fix if he wants to claim to conform to any
C standard in any mode.

Well you win. I will add those parentheses!!!
What a discussion for 2 bytes more.

OK: I was WRONG, completely and utterly WRONG. There is
no other solution than to ADD those dammed parentheses!!!

:-)

Yes, you were wrong. Calmly admitting that would have been quite
sufficient, and everyone here would have respected you for it.
Shouting about it (all-caps and multiple parentheses) is not
necessary, and the smiley just doesn't make any sense; this is no
joke.

Good grief, man, you made a mistake, somebody pointed it out, and
you're (finally) going to correct it. Don't make such a big deal out
of it.

This wouldn't have been "What a discussion for 2 bytes more" if you
had been reasonable about it. You perpetuated this argument.

Could it be that you're more interested in arguing than in producing a
correct implementation?

Thanks for your help guys. But something still bothers me.

Chuck Falconer says (and then I think Flash Gordon proved) that
there can't be a table of precedences for operators
like that one in Harbison and Steele "C a reference manual".

Everybody confirms that? I mean H & S is *THE* reference
manual. How could they have done SUCH a huge mistake?

No, H&S is not "*THE* reference manual". The C standard is.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Keith Thompson wrote:

>
jacob navia <ja***@jacob.remcomp.frwrites:

Proof.

Suppose there is a construct where -1 needs a parentheses.

In that case (-1) "..." != -1 "..."

This means that the expression "..." must have a binary operator
that binds more than unary minus to the constant 1.

Unary minus has precedence 15.

But ALL operators at level 15 are UNARY operators. There are
NO binary operators at level 15.

Remains level 16, with . (point) function call ,
increment decrement, and indexing.

All those operations can't use a manifest constant like 1
or 447766.

Q.E.D

Reference: Harbison and Steele. "C, a reference manual"
See the table of precedences.

H&S (5th edition, right?) is an excellent book, but I'm not convinced
by any proof that's not based on the standard -- and you shouldn't be
either.

In the distant past, I seem to recall somebody
citing Harbison and Steele, attempting to correct me
because I had refered to the mem functions as string functions.

--
pete

[Ben Bacarisse]

Army1987 <ar******@NOSPAM.itwrites:

On Tue, 04 Sep 2007 20:45:09 +0200, jacob navia wrote:

<snip>

> From the standard you make apreceddence table.
Look at the refeerence cited in the text you snipped

You can't. Casts bind tighter than unary operators, unary
operators bind tighter than sizeof, and sizeof binds tighter than
casts. Incredible but true. This is useful to prevent
sizeof(int) -1 from being ambiguous, but it is very hard to
explain without the actual syntax.

I don't think that is the most helpful way to think of it.
'sizeof(int) -1' is not parsed by having sizeof 'bind' more tightly
than the cast because there is no cast. The grammar simply allows
sizeof(type-name) as a valid unary-expression.

Of course that, in part, is your argument (that there can be no
precedence table) so thinking about binding is confusing. True, up to
a point, but one *can* make the usual table provided that the form
sizeof(type-name) is removed altogether. The other form of sizeof
(where it really is an operator, with full operator rights) is fine.

sizeof(type-name) simply does not fit. sizeof, in this form, is not
really an operator. For example, the grammar forbids extra
parentheses so 'sizeof((int))' is illegal but 'sizeof((1))' is fine.
Also, operators usually operate on other expressions (at least that is
what the precedence table is about) but the apparent argument --
'(int)' in this case -- is not itself a valid expression, so I think
it is simply best to leave this version of sizeof out of the operator
table altogether.

The standard _says_ sizeof is an operator, so we must say it is one,
but in this form (with a parenthesized type following it) it is an
operator like no other. I prefer to think of sizeof as having two
forms: one where it *is* an operator and one where sizeof(type-name)
forms a unary-expression all by itself.

--
Ben.

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

>jacob navia wrote:

.... snip ...

>>

>>Unary minus has precedence 15.

Simply because C doesn't have precedence. Read the standard.

From the standard you make apreceddence table.
Look at the refeerence cited in the text you snipped

Why? I still maintain C doesn't have precedence. What you make
from it is up to you. As is the correctness of any 'deductions'
made in the process.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:

jacob navia <ja***@jacob.remcomp.frwrites:

>Flash Gordon wrote:

>>Jacob still has a bug to fix if he wants to claim to conform to any
C standard in any mode.

Well you win. I will add those parentheses!!!
What a discussion for 2 bytes more.

OK: I was WRONG, completely and utterly WRONG. There is
no other solution than to ADD those dammed parentheses!!!

:-)

Yes, you were wrong. Calmly admitting that would have been quite
sufficient, and everyone here would have respected you for it.
Shouting about it (all-caps and multiple parentheses) is not
necessary, and the smiley just doesn't make any sense; this is no
joke.

[...]

Whoops, I meant "multiple exclamation points".

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Harald van D?k said:

jacob navia wrote:

<snip>

>It will be no different than the insults of your friend heathfield
(lower case)

Please do not include me in your fight with Richard Heathfield; I do
not wish to have any part in it.

Neither do I.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Bos]

Sherm Pendley <sp******@dot-app.orgwrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Dev-C++, then. Unlike either of the ones mentioned by the OP, it is both
free (in the sense of not having to pay for it) and free (in the sense
of not shackling you into its own preferred way of creating programs),
though not Frea (in the sense of chaining you to a Gnu licence, as gcc
does). It's a pretty small download, as well. And it does both C _and_
C++ (though not, AFAIK, C/C++).

The GPL is only relevant if your app includes some or all of the source
code of a GPL'd app, as-is or modified.

Wrong. The GPL is relevant as long as lawyers exist to make a quick buck
out of FUD.

The GPL has *zero* impact on the output of a GPL'd app. Your app is not
somehow "infected" by the simple act of editing your own code with a GPL'd
IDE, or compiling it with a GPL'd compiler. The idea that it would (or
can) be is pure FUD.

And FUD is still - unfortunately - a relevant factor in business
decisions. Because if you want to sell your software, you cannot afford
to doubt whether it would be legal.
For example, I note that you do not mention linking in GPL'd libraries.

Richard

[jacob navia]

CBFalconer wrote:

jacob navia wrote:
... snip ...

>I am the author of lcc-win32. This is a C compiler that implements
the latest standard C99 under windows.

Less completely than gcc does.

... snip ...

>Price: Free download. Size: around 5MB. All this is written
in C. Generates very small programs.

Amazing claim. I find that code generated by gcc is significantly
smaller.

I have my data from (for example) a compilation of the
PARI mathematical calculator. lcc-win32 produces an executable
smaller than gcc:
d:\lcc\gp>pedump /summary gp.exe
gp.exe 781856 bytes, linked Wed Sep 05 10:01:02 2007
Size of code: 667136
Size of initialized data: 113664
Size of uninitialized data: 2048

For gcc the output is:
d:\lcc\gp>pedump /summary gpgcc.exe
gpgcc.exe 1582964 bytes, linked Wed Sep 05 10:03:10 2007
Size of code: 841216
Size of initialized data: 17408
Size of uninitialized data: 2048

I used for that the gcc-2.95.2 version

This can be different in other contexts. If you can show your
data I can verify it.

Also note that I (and all others) am perfectly free to download and
examine and/or modify the gcc code at any time. This does not
apply to lcc-win32.

So what? I never claimed source code availability

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-09-04 23:37, CBFalconer wrote:

Erik Wikström wrote:

>>

... snip ...

>>
Personally I prefer Visual C++ 2005 Express since it is free, (in
the sense of not having to pay for it) and free (in the sense of
not shackling you into its own preferred way of creating programs).
And it has got the best debugger I've ever used (not that I have
used that many, but it beats gdb).

Please explain how gcc 'shackles you'. Or gdb.

I've never claimed that gcc shackles you, in fact I know that it does
not. Further more I think it is a very good compiler and I'm perfectly
happy to used it.But I also think that the VC++ compiler is very good
and that the VC++ IDE is great, especially for a novice. The reason I
formulated my text as I did was to inform the user that VC++ does not
force you to use a certain way of creating programs, which Richar Bos'
post seemed to imply.

And if you read my post again you'll see that my only comment about gdb
was that I think the debugger in VC++ is better.

--
Erik Wikström

[Rob Kendrick]

On Wed, 05 Sep 2007 10:07:20 +0200, jacob navia wrote:

I used for that the gcc-2.95.2 version

I hope you use a similarly ancient version of your compiler when doing
comparisons. This is two major releases behind!

B.

[jacob navia]

Rob Kendrick wrote:

On Wed, 05 Sep 2007 10:07:20 +0200, jacob navia wrote:

>I used for that the gcc-2.95.2 version

I hope you use a similarly ancient version of your compiler when doing
comparisons. This is two major releases behind!

B.

Yes, but the problem is that those releases installed perfectly.

I tried again today:

1) Downloaded the "automatic installer" from sourceforge.
2) When started, it crashed during download of some file.
This is probably because I am using Vista 64 bits.
3) I restarted the software and this time went to the end.

Then... how do you start this?

No readme besides this in the doc directory
README.TXT
<quote>
Free Microsoft C Runtime and import library definitions

Maintained by MinGW Developers
Send bug reports and questions to Mi*********@lists.sourceforge.net
URL: http://www.mingw.org

A historical readme.txt exists and is distributed for your edification. The
references within may or may not be correct. Please do not rely on
them. See
http://www.mingw.org for a list of valid references.
<end quote>

Very clear.

OK. I added to my path c:\mingw\bin.

Then I tried to compile.

It told me

gcc installation error: can't find cc1

OK.

dir cc1.exe /s
C:\MinGW\libexec\gcc\mingw32\3.4.2\cc1.exe

OK. Added the cc1 directory to my path variable.
Now, when I try to compile it says to me:
../lib/gcc/mingw32/3.4.2/../../../../include/tgmath.h:72: error: syntax
error before "__fabs"
[snip around 500 lines of similar errors]

ore "__remainder"
../lib/gcc/mingw32/3.4.2/../../../../include/tgmath.h:303: error: syntax
error before "__remainder"
make: Error code 1

d:\lcc\gp>

Using older versions of gcc is BETTER for gcc in this case since newer
versions are ALWAYS BIGGER (and compile slower) than previous ones!!!

Obviously I am biased.

[Rob Kendrick]

On Wed, 05 Sep 2007 12:14:16 +0200, jacob navia wrote:

Rob Kendrick wrote:

>On Wed, 05 Sep 2007 10:07:20 +0200, jacob navia wrote:

>>I used for that the gcc-2.95.2 version

I hope you use a similarly ancient version of your compiler when doing
comparisons. This is two major releases behind!

Yes, but the problem is that those releases installed perfectly.

I tried again today:

1) Downloaded the "automatic installer" from sourceforge.
2) When started, it crashed during download of some file.
This is probably because I am using Vista 64 bits.
3) I restarted the software and this time went to the end.

I have no idea what problems Vista might bring to the party, but on the
one occation I've installed MinGW under Windows XP, it worked faultlessly.
Although I tend to cross-compile from Linux.

Very clear.

OK. I added to my path c:\mingw\bin.

Then I tried to compile.

It told me

gcc installation error: can't find cc1

<snip>

I've always used MinGW through its provided shell, rather than from the
cmd.exe prompt. This may have something to do with it - I simply followed
the instructions.

Using older versions of gcc is BETTER for gcc in this case since newer
versions are ALWAYS BIGGER (and compile slower) than previous ones!!!

Sorry - when did the size of a compiler's binary have an inverse effect on
its generated code?

Of course, it is slower than previous releases - but that's because it's
doing a lot more.

I will compile Lua 5.1.2, a non-trivial program written in ANSI C
which is a language interpreter. The version of GCC that I cross-compiled
from Linux from is mingw32-3.4.5.20060117.1.dfsg, so not even the latest
version.

24 rjek@trite:~/src/lua-5.1.2/src $ file lua
lua: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit
25 rjek@trite:~/src/lua-5.1.2/src $ ls -l lua
-rwxr-xr-x 1 rjek rjek 122368 2007-09-05 11:31 lua

I spent about 45 minutes trying to get lcc-win32 to build Lua, whose
authors are proud of its clean ANSI-C nature. It compiles, but will not
link, claiming it can't find almost all of the standard library functions
that Lua uses - except with additional underscores. So I gave up, and
thus have no useful comparison. Perhaps you could build it for me?

<http://www.lua.org/>

B.

[CBFalconer]

Richard Bos wrote:

Sherm Pendley <sp******@dot-app.orgwrote:

.... snip ...

>

>The GPL has *zero* impact on the output of a GPL'd app. Your app
is not somehow "infected" by the simple act of editing your own
code with a GPL'd IDE, or compiling it with a GPL'd compiler. The
idea that it would (or can) be is pure FUD.

And FUD is still - unfortunately - a relevant factor in business
decisions. Because if you want to sell your software, you cannot
afford to doubt whether it would be legal. For example, I note
that you do not mention linking in GPL'd libraries.

However most libraries, such as the c-library, are released under
the more liberal GPLL ? license, which allows use without releasing
source. The exceptions are such specialized things as my hashlib,
which remain under GPL. The only FUD is that which you are
raising.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

>jacob navia wrote:

.... snip ...

>>

>>Price: Free download. Size: around 5MB. All this is written
in C. Generates very small programs.

Amazing claim. I find that code generated by gcc is significantly
smaller.

I have my data from (for example) a compilation of the
PARI mathematical calculator. lcc-win32 produces an executable
smaller than gcc:
d:\lcc\gp>pedump /summary gp.exe
gp.exe 781856 bytes, linked Wed Sep 05 10:01:02 2007
Size of code: 667136
Size of initialized data: 113664
Size of uninitialized data: 2048

For gcc the output is:
d:\lcc\gp>pedump /summary gpgcc.exe
gpgcc.exe 1582964 bytes, linked Wed Sep 05 10:03:10 2007
Size of code: 841216
Size of initialized data: 17408
Size of uninitialized data: 2048

I used for that the gcc-2.95.2 version

This can be different in other contexts. If you can show your
data I can verify it.

Very faulty analysis, IMO. You need to look at the size of code
generated in the .o (or .obj) files for some particular source. As
it is you are confusing things with such items as debuggery
linkages, etc. Also, you should not be comparing against a 10 or
more year old gcc version. The optimization level also matters.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Spoon]

Jacob Navia wrote:

I used for that the gcc-2.95.2 version

Released October 24, 1999
http://gcc.gnu.org/releases.html

[jacob navia]

Rob Kendrick wrote:

I will compile Lua 5.1.2, a non-trivial program written in ANSI C
which is a language interpreter. The version of GCC that I cross-compiled
from Linux from is mingw32-3.4.5.20060117.1.dfsg, so not even the latest
version.

24 rjek@trite:~/src/lua-5.1.2/src $ file lua
lua: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit
25 rjek@trite:~/src/lua-5.1.2/src $ ls -l lua
-rwxr-xr-x 1 rjek rjek 122368 2007-09-05 11:31 lua

I spent about 45 minutes trying to get lcc-win32 to build Lua, whose
authors are proud of its clean ANSI-C nature. It compiles, but will not
link, claiming it can't find almost all of the standard library functions
that Lua uses - except with additional underscores. So I gave up, and
thus have no useful comparison. Perhaps you could build it for me?

<http://www.lua.org/>

B.

OK. I compiled that software and obtain an executable of this
characteristics:
C:\MinGW\lua\lua-5.1.2\src\lcc>pedump /summary lua.exe
lua.exe 145440 bytes, linked Wed Sep 05 16:40:08 2007
Size of code: 125952
Size of initialized data: 18432
Size of uninitialized data: 1024
Size of image: 155648
Console application. Debug information not present.
Dlls used: kernel32.dll crtdll.dll

The difference of 145440 - 122368 = 23072 bytes is due to the
static linking of the printf function. To prove this, I compile
this program with lcc-win32:

int main(void){printf("hello\n";}

and obtain an executable of 30240 bytes

When I compile

int main(void){puts("hello");}

I obtain an executable of 3104 bytes.

The difference of around 27K allows me to say that the executable
size of both compilers is around the same. Note that I did not say
that I am better than gcc. I just only said that my compiler generates
small executables. And here is the proof.

You have to give the -O (optimize) option to the compiler and the
-s (strip) option to the linker.

The gcc team, of several dozens specialist, supported by RedHat Corp,
IBM and other BIG names in the industry obtains surely a better compiler
than a single developer not supported by anyone!

I am ready to send you the exectables and the library to the address
you indicate to prove my assertions.

jacob

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>CBFalconer wrote:

>>jacob navia wrote:

... snip ...

>>>Price: Free download. Size: around 5MB. All this is written
in C. Generates very small programs.
Amazing claim. I find that code generated by gcc is significantly
smaller.

I have my data from (for example) a compilation of the
PARI mathematical calculator. lcc-win32 produces an executable
smaller than gcc:
d:\lcc\gp>pedump /summary gp.exe
gp.exe 781856 bytes, linked Wed Sep 05 10:01:02 2007
Size of code: 667136
Size of initialized data: 113664
Size of uninitialized data: 2048

For gcc the output is:
d:\lcc\gp>pedump /summary gpgcc.exe
gpgcc.exe 1582964 bytes, linked Wed Sep 05 10:03:10 2007
Size of code: 841216
Size of initialized data: 17408
Size of uninitialized data: 2048

I used for that the gcc-2.95.2 version

This can be different in other contexts. If you can show your
data I can verify it.

Very faulty analysis, IMO. You need to look at the size of code
generated in the .o (or .obj) files for some particular source. As
it is you are confusing things with such items as debuggery
linkages, etc. Also, you should not be comparing against a 10 or
more year old gcc version. The optimization level also matters.

I used -O2, but the tool pedump does NOT count the size of
the file but the actual size in sections of the executable.

[jacob navia]

Spoon wrote:

Jacob Navia wrote:

>I used for that the gcc-2.95.2 version

Released October 24, 1999
http://gcc.gnu.org/releases.html

For a comparison with a newer version of gcc see the compilation of the
lua system in this same thread. Messages by Rob Kendrick

[Mark McIntyre]

On Wed, 05 Sep 2007 10:07:20 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>d:\lcc\gp>pedump /summary gp.exe
gp.exe 781856 bytes, linked Wed Sep 05 10:01:02 2007
Size of code: 667136
Size of initialized data: 113664
Size of uninitialized data: 2048

For gcc the output is:
d:\lcc\gp>pedump /summary gpgcc.exe
gpgcc.exe 1582964 bytes, linked Wed Sep 05 10:03:10 2007
Size of code: 841216
Size of initialized data: 17408
Size of uninitialized data: 2048

I would be moderately unsurprised to discover that the difference here
was down to optimsation and linkage flags.
--
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