[OT] lcc first experience

[Morris Dovey]

About a week ago, I downloaded Jacob's lcc package to my new (to me)
Win/XP box and gave it a test drive this morning. The application
program reads my web server's log file (currently about 35MB) and
reduces it to a bunch of lists, then outputs the log contents arranged
by each requestor's chronological list of hits. It's not really a
strenuous test, but there's plenty of opportunity to screw up multiple
levels of indirection, etc.

The program was originally written on a Linux system and compiled/linked
using the gcc toolchain.

With the "pedantic" option it warned (8 times) about "Assignment within
a conditional expression" but was otherwise friendly. The executable was
some larger than I recollected the gcc version had been, but shrank by
8KB when I used the -O (peephole optimizer) option. I think that puts
the size in the same ballpark with the gcc-compiled (with -O3) version.

The only other C compiler I have for my current environment is TurboC
V3.0 - an old friend, but not always convenient in current MS platforms.
Unless I discover a particular need to use TC3 (or discover some
horrible in lcc), I'll probably stick with lcc.

My application (written in standard-compliant C, of course <g>) ported
without any change and ran without any problem.

I read comment in another thread that prompted me to comment and say to
Jacob:

Merci/Thanks/Gracas/Gracias/Ashkurak/Spasibo!

 

[Tomás Ó hÉilidhe]

The executable was
some larger than I recollected the gcc version had been, but shrank by
8KB when I used the -O (peephole optimizer) option.

Did you strip the executable, i.e. take out all the superfluous shite
that isn't needed? When using gcc, here's what I do to get a lean
executable:

gcc hello.c -D NDEBUG -ansi -pedantic -S -O3 -o hello.exe

It gave me an executable of 397 bytes for the follow program:

#include <stdio.h>

int main(void)
{
puts("Hello World!");
return 0;
}

 

[Morris Dovey]

Did you strip the executable, i.e. take out all the superfluous shite
that isn't needed?

I don't remember, but I'll check when I'm next on that machine (it's 16
miles from here at my shop). I've liked using gcc on the Linux box - and
expect that I'll enjoy using lcc on this one.

 

[Antoninus Twink]

Did you strip the executable, i.e. take out all the superfluous shite
that isn't needed?

Yeah, gotta hate all that superfluous shite that does absolutely nothing
except let you debug your program.

 

[Keith Thompson]

About a week ago, I downloaded Jacob's lcc package to my new (to me)
Win/XP box and gave it a test drive this morning.

[...]

jacob's compiler is called "lcc-win". "lcc" is a different compiler
(the one on which lcc-win was based). It's an important distinction.

[...]

With the "pedantic" option it warned (8 times) about "Assignment
within a conditional expression" but was otherwise friendly.

Such a warning seems perfectly friendly to me. Would you prefer that
it didn't tell you that you might have mistyped "==" as "="?

[snip]

 

[jacob navia]

About a week ago, I downloaded Jacob's lcc package to my new (to me)
Win/XP box and gave it a test drive this morning. The application
program reads my web server's log file (currently about 35MB) and
reduces it to a bunch of lists, then outputs the log contents arranged
by each requestor's chronological list of hits. It's not really a
strenuous test, but there's plenty of opportunity to screw up multiple
levels of indirection, etc.

The program was originally written on a Linux system and compiled/linked
using the gcc toolchain.

With the "pedantic" option it warned (8 times) about "Assignment within
a conditional expression" but was otherwise friendly. The executable was
some larger than I recollected the gcc version had been, but shrank by
8KB when I used the -O (peephole optimizer) option. I think that puts
the size in the same ballpark with the gcc-compiled (with -O3) version.

The only other C compiler I have for my current environment is TurboC
V3.0 - an old friend, but not always convenient in current MS platforms.
Unless I discover a particular need to use TC3 (or discover some
horrible in lcc), I'll probably stick with lcc.

My application (written in standard-compliant C, of course <g>) ported
without any change and ran without any problem.

I read comment in another thread that prompted me to comment and say to
Jacob:

Merci/Thanks/Gracas/Gracias/Ashkurak/Spasibo!

Thank you. Really. It is nice to see that my effort is
good for users.

 

[Tomás Ó hÉilidhe]

Such a warning seems perfectly friendly to me.  Would you prefer that
it didn't tell you that you might have mistyped "==" as "="?

I love what gcc has to say about it:

warning: suggest parentheses around assignment used as truth value

I've actually taken its advice and started doing:

if ((i=5)) DoWhatever();

 

[Johannes Bauer]

gcc hello.c -D NDEBUG -ansi -pedantic -S -O3 -o hello.exe

Ehrm, the "-S" parameter creates assembly output - are you sure that the
compiled executable works?

Kind Regards,
Johannes

 

[Tomás Ó hÉilidhe]

Ehrm, the "-S" parameter creates assembly output - are you sure that the
compiled executable works?

Wups I meant a lowercase S. Also I use -Wall.

 

[Walter Roberson]

Try do declare a define something like:

unsigned char a = 0b1000000;

With lcc-win works...with other compilers (i.e. mingw32-gcc) no...you
must use hexadecimal 0xF0 or decimal 128.

Why this?

Because 0b is not standard C, and is an lcc-win extension ?

 

[vippstar]

Morris Dovey ha scritto:


Try do declare a define something like:

unsigned char a = 0b1000000;

With lcc-win works...with other compilers (i.e. mingw32-gcc) no...you
must use hexadecimal 0xF0 or decimal 128.

Why this?

Because 0b is not standard C. If you want a standard C solution, take
a loot at
<http://cprog.tomsweb.net/binconst.txt>
With that header you can define a as:
unsigned char a = B8(10000000);
Also, if it works in compliant mode, then it's a bug.

 

[Paul Hsieh]

I love what gcc has to say about it:

warning: suggest parentheses around assignment used as truth value

I've actually taken its advice and started doing:

if ((i=5)) DoWhatever();

Whenever I do that I usually write it as:

if (0 != (i = 5)) DoWhatever();

to make it absolutely crystal clear what I mean.

 

[dj3vande]

Maybe a more believable example
might help:

while (p = p->next) ...
vs.
while ( (p = p->next) ) ...
vs.
while ( (p = p->next) != NULL ) ...

For that particular case, I've found that
for(p=first; p; p=p->next)
usually makes more sense than using while, and has the bonus that I've
never seen a compiler complain about it.
(Depending on stylistic preferences, the second clause could also be
written as 'p != NULL' or 'NULL != p'.)


dave

 

[Bart]

Morris Dovey ha scritto:


Try do declare a define something like:

unsigned char a = 0b1000000;

With lcc-win works...with other compilers (i.e. mingw32-gcc) no...you
must use hexadecimal 0xF0 or decimal 128.

You mean 0x40 or decimal 64?

Why this?

0b-syntax doesn't exist in standard C.

This actually tells you an awful lot about C and C programmers.

Implementing binary literals must take all of 10 minutes in a
compiler, but has rarely been done and is not part of any standard.

And it's not that it's never used; it just that C programmers prefer
to use ugly macros to writing straight code. Otherwise I'm sure a way
of writing binary constants (computers are binary, and C is low-level)
would have been standardised long ago.

Or, C programmers say to use hexadecimal instead!

lcc-win32 appears to have this 'extension' (if it's even that because
it's so trivial to implement), the problem being that the code won't
then compile anywhere else.

 

[jacob navia]

You mean 0x40 or decimal 64?


0b-syntax doesn't exist in standard C.

This actually tells you an awful lot about C and C programmers.

Implementing binary literals must take all of 10 minutes in a
compiler, but has rarely been done and is not part of any standard.

Excuse me that is not correct. Took around 30 minutes...

And it's not that it's never used; it just that C programmers prefer
to use ugly macros to writing straight code. Otherwise I'm sure a way
of writing binary constants (computers are binary, and C is low-level)
would have been standardised long ago.

This is just a facvility to users. As Mr Dovey proved, it is
VERY easy to get it wrong! It is the best to do it automatically.

Or, C programmers say to use hexadecimal instead!

lcc-win32 appears to have this 'extension' (if it's even that because
it's so trivial to implement), the problem being that the code won't
then compile anywhere else.

I do not know why this is not used elsewhere.

 

[Keith Thompson]

[... concerning 0bXXXX... numeric literals ...]
I do not know why this is not used elsewhere.

How about 0qXXXX...?

<off-topic>

In all my days, I've only encountered one language that
supported literals in all the bases 2,4,8,16: XPL, by McKeeman,
Horning, and Wortman.

binary: "(1)0101010101" (to any length desired)
quartal: "(2)11111" ( " " " " )
octal: "(3)0525" ( " " " " )
hex: "(4)155" ( " " " " )

The (4) could be omitted at the start of a hex bit-string.

[...]

Ada supports all bases 2 through 16:

2#11001001# -- binary
3#12012# -- trinary (ternary?)
10#42# -- equivalent to just 42
16#1.23#e10 -- hexadecimal floating-point (1.13671875 * 16**10)

One advantage is uniformity; there's no special-case syntax for each
base. On the other hand,

And Perl supports C-style literals plus binary with the "0b..."
syntax.

</off-topic>

I don't suggest that C needs this much generality (even in Ada, I've
rarely if ever seen bases other than 2, 8, 10, and 16 outside test
cases). But IMHO binary constants using the 0b syntax would be a nice
addition, requiring only minor changes to the compiler and to the
runtime library. On the other hand, we've gotten along for decades
without them, and new features quite properly need to meet a high
burden before being standardized.

 

[Chris Torek]

Ada supports all bases 2 through 16:
2#11001001# -- binary
3#12012# -- trinary (ternary?)
10#42# -- equivalent to just 42
16#1.23#e10 -- hexadecimal floating-point (1.13671875 * 16**10)

One advantage is uniformity; there's no special-case syntax for each
base.

Indeed.

One could squeeze arbitrary integer bases into C (as it stands
today) using (eg) 0r, with the radix and number separated by another
punctuator that can be found in what is currently a valid "pp-number"
but not-valid integer, e.g., another r, or a decimal point, or
some such:

0r2r1101001
0r8.391

[a]nd Perl supports C-style literals plus binary with the "0b..."
syntax. ... (even in Ada, I've rarely if ever seen bases other
than 2, 8, 10, and 16 outside test cases). But IMHO binary constants
using the 0b syntax would be a nice addition ...

Not only have I wanted them, I have even implemented them (though
not in C). However:

... On the other hand, we've gotten along for decades
without them, and new features quite properly need to meet a high
burden before being standardized.

as it turns out, binary constants like this are actually quite
error-prone. I discovered it was better to go back to hexadecimal
constants in quite a few cases. The binary constants were mainly
useful in short binary numbers (where hex-vs-binary became pretty
much a matter of taste).

If C were to steal another feature from Ada, we could fix this,
*and* the equivalent problem with other large constants (in any
base), by adding "_" as an ignored digit separator. Then we could
write:

0b1101_0110_0010_1101_1000_0101_1110_0000_0001_1110_1111_0001_0011

or:

0xd62d_85e0_ef13

both of which are (I believe) superior to the equivalent versions
without underscores. I also find:

12_345_678_997

a little more "obvious" than:

12345678997

Note that C89's "pp-number" tokens leave enough leeway to add both
binary constants (with 0b) *and* group separators (with _). Perhaps
I should add them to gcc (with an appropriate "extension" warning),
and try to get them into C1x.

 

[Richard Bos]

Try do declare a define something like:

unsigned char a = 0b1000000;

With lcc-win works...with other compilers (i.e. mingw32-gcc) no...you
must use hexadecimal 0xF0 or decimal 128.

Why this?

Because the author of lcc-win-32 is a great adherent of the embrace-and-
extend philosophy; IOW, a disciple of Microsoft and GnuC.

Richard

 

[Dik T. Winter]

> In all my days, I've only encountered one language that
> supported literals in all the bases 2,4,8,16: XPL, by McKeeman,
> Horning, and Wortman.

Also Algol 68, which supports all bases <= 36, not only those four.

 

[Richard Tobin]

Also Algol 68, which supports all bases <= 36, not only those four.

As does Common Lisp.

-- Richard