[OT] lcc first experience

[Walter Roberson]

I should
have said that many statements, or the statements in question have
side-effects.

I am having a bit of difficulty in coming up with computer languages
that do not have statements with side effects (this referring to your
context of saying that C is unusual in that, etc..) LISP might
qualify in that it is seriously debatable as to whether LISP has
statements at all. I have encountered some computer languages which
did not use the term 'statement' but which had something that had
exactly the same role. There are languages which officially have
nothing other than operators, or operators and comments
(befunge, mind-f*ck), though they certainly have side-effects.
There are procedural languages such as Prolog that might perhaps
properly said to have no 'statements', but I have yet to find
one of those which was so pure that it did not have I/O of -some-
sort, and thus side-effects.

With respect to the statement in question, which was of the form

if (assignment) DoWhatever;

then the assignment is an -expression-, not a statement, and
there are certainly if -statements- that have no side effects.

C *is* a bit unusual in allowing blatant side-effects in conditions
in 'if' statements. On the other hand, it is not unusual for
procedural languages to allow not-so-blatant side-effects in conditions,
by allowing the conditions to be expressed in in terms that include
a call to a function that has a side effect (perhaps inherent in
the structure of the program logic, perhaps merely some debugging code
that prints out an "I am here" or which dumps out some values.)

I mean you guys rag on Jacob all the time, but you just
so perfectly illustrate his point with this inane over the top
pedantry.

"you guys" is not me. I have never downloaded any of Jacob's software,
and I don't get involved in the conformance witch-hunts. If I happen
to notice him making a mis-statement about C that others haven't
already mentioned, and I have time and can be bothered, then I may
post a correction, just the same as I post questions or corrections
to others (e.g., you.)

It is true that I not infrequently point out that some aspect of Jacob's
postings are off-topic, but that is because his postings frequently -are-
off-topic. I point out topicallity to quite a number of people, if
I haven't noticed someone else indicating the same thing by that time.
I am not a "topicality hound", chiming in days later to say
"Off topic!" when others have already said the same thing.

I mean you don't give a crap at all about the point I was making or
what one I was responding to, but you go over the top with some
ridiculously lengthy response about some irrelevant detail when you
just as easily could have pointed out that casting an expression to
void removes its side effect (issue resolved in less than a
sentence). I accept corrections, not sermons.

If I had indeed "pointed out that casting an expression to void
removes its side effect", then I would have been speaking
incorrectly for expressions that contain side effects, such as
(void)x++
and I would have been speaking redundantly for expressions that contain
no side effects, such as
42

Casting an expression to void would remove any ability to use
the expression as an l-value; but if we were to substitute
the notion of l-valueness in place of side-effectiveness
into your original phrase about what all C statements have, I don't
think that would exactly work out either.


I do give "a crap" about the point you were making about C being
unusual because... unfortunately I haven't yet figured out yet what
the second half of that particular point was attempting to hint at.

But no, I "don't give a crap" about your point about seperating
the side-effect clearly from the condition; it is an element of
style that is important to you, but it is not important to me.
I have no Yeah or Nay to say about it, just as I avoid the
indentation wars and the wars about whether the { opening
a compound statement should go on the end of the line or on the next line
by itself or on the the next line followed by the first statement in
the compound. These matters are not important to the C programming
language. The closest that I can think of to C having anything
to say about them is where it prohibits an #include file from ending
in a backslashed newline, which fact has cramped my style by
an incalcuable amount.

[...] When Paul Heish [...]

Oh, for a second there I thought you were talking about me. I should
probably go on a long rant about how to spell my name properly.

I do apologize for misspelling your name. I usually copy and paste it
to be sure of getting it correct, but that particular time I relied upon
my memory.

And I
still haven't found the word "sentance" in my dictionary, but I'm sure
its there somewhere.

It's in www.urbandictionary.com

So did you have any comments about
source code clarity, useful strategies for warning removal,
intentional operation explicitness, or the value of horizontal code
size? How about just the lcc-win32 compiler?

Like another poster pointed out: none of those are topical for
this newsgroup.

 

[Keith Thompson]

... snip C translation ...

However:

VAR
boolean x;
...
IF x THEN ...
ELSE ...

works just fine. Pascal has a boolean type.

Yes. I rather thought I had implied that when I wrote that "Pascal
requires a condition to be of type boolean".

 

[jacob navia]

[...]
I mean you don't give a crap at all about the point I was making or
what one I was responding to, but you go over the top with some
ridiculously lengthy response about some irrelevant detail when you
just as easily could have pointed out that casting an expression to
void removes its side effect (issue resolved in less than a
sentence). I accept corrections, not sermons.
[...]

(void) printf("No side-effects here, nossir!\n");

Obvious side effect: the state of stdout is modified!
That is the only reason why printf exists: to modify the
state of stdout.

Trying to be clever you look dumb now...

 

[jacob navia]

[snip]

You
appear to be an expert critic who contributes his bile freely to this
group.

Critics are unwelcome by our over-guru who contributes his bile freely
to this group.

Get a life man!

 

[Nick Keighley]

C is an uncommon language in that it does not require a comparison
operator in its if statements [...]

I'm not sure about this. How about the following

Pascal, BCPL, Ada, Algol-60, python

 

[Nick Keighley]

On May 8, 3:11 pm, (e-mail address removed)-cnrc.gc.ca (Walter Roberson)
wrote:

you don't even manage to communicate for one line.


you find quoting from the standard objectionable?!


what are you on about?



and I'd call "being clear"

Oh, I am so sorry for getting that wrong. Must have confused
two posts. You can't blame for that though, just look at
the their size!

fine you don't like long posts. Some people try to be clear
and a one-liner isn't always good enough.

I believe he clearly demonstrated that he didn't even notice
his mistake - he didn't mean side effect, he meant "value"
or something like that. I might be wrong here, he might be
actually using "side effect" in some funny sense. If you care,
you could ask him. But we don't care, right? We have the standard
to quote, who cares what he meant!

so do you know waht he meant?

So you could state the obvious: he was obviously wrong. You
chose to demonstrate your writing skills instead (one would
think that even stating that is silly, since it's obvious,
but we have innocent newbies who need to be defended, so
"correcting a mistake" was of course needed).


Blah blah blah. You took one single thing, you ignored the
actual point (about if(0 != (foo = blah))). You didn't try
to *understand*. No idea what you were thinking, but it was
that - BS.

what was the actual point? If you think trying to
clarify things by quoting the C standard is BS
then I'm in favour of BS.

 

[Nick Keighley]

Really?  Which ones do?

FORTRAN, CORAL-66

 

[Antoninus Twink]

There are languages which officially have nothing other than
operators, or operators and comments (befunge, mind-f*ck), though they
certainly have side-effects.

I've never heard of mindfuck. Could you be thinking of brainfuck?

 

[Richard Tobin]

Really?  Which ones do?

[/QUOTE]

FORTRAN, CORAL-66

Fortran requires a "logical expression", which need not include a
comparison operator.

http://www.fortran.com/fortran/F77_std/rjcnf0001-sh-6.html#sh-6.4

-- Richard

 

[Walter Roberson]

We also have innocent experts to be defended. Walter Roberson is an expert
C programmer who contributes his expertise freely to this group.

Thanks for the kind words, but regretfully they aren't quite accurate.

There was a time when I was quite involved in ensuring that my
programs were as portable as practical, C89 base and POSIX.1-1990
used without shame if I was doing something we expected to port only
to Unix. I was an expert in that aspect, back then, and used to be
able to quote relevant parts of C89 more or less from memory -- but
I wasn't an expert in the more obscure nooks and crannies of C.

Then my job headed into directions that made tools such as perl
a more natural fit for my programming -- e.g., collection and
correlation of SNMP data from switches and routers and firewalls.
After a time, I realized that my C was getting rather rusty, and I
started hanging around here to keep my C skills in practice. I have
learned quite a bit about C by doing so, but my job does not involve
much C programming.

Eventually my job morphed again and I'm back to software development;
for a while maple was the best tool for my work. These days most
of my programming is in Matlab, which is suitable for project I am
working on. Matlab has a very large standard library and optional
toolboxes, and is used in an amazing variety of ways -- it is too big
for most people (including myself) to know *all* of. It is hard to
be a Matlab "expert" without a hefty science and engineering background.
But I do what I can to contribute to the Matlab community;
comp.soft-sys.matlab is where most of my postings are these days.

 

[Harald van Dijk]

If you ever actually try "-W -Wall -ansi -pedantic" on gcc, you will
discover that (barring possible errors) it doesn't embrace-and-extend.

This translation unit is accepted without any diagnostic by gcc -W -Wall -
ansi -pedantic:

int __attribute__((const)) zero(void) { return 0; }

Does that mean the code is valid C, that this is an error in GCC, or that
GCC does embrace-and-extend?

 

[jacob navia]

This translation unit is accepted without any diagnostic by gcc -W -Wall -
ansi -pedantic:

int __attribute__((const)) zero(void) { return 0; }

Does that mean the code is valid C, that this is an error in GCC, or that
GCC does embrace-and-extend?

Gcc can do anything, like MSVC.

If I add some extension, I will be flamed of course.

 

[Flash Gordon]

Harald van Dijk wrote, On 09/05/08 17:34:

This translation unit is accepted without any diagnostic by gcc -W -Wall -
ansi -pedantic:

int __attribute__((const)) zero(void) { return 0; }

Does that mean the code is valid C, that this is an error in GCC, or that
GCC does embrace-and-extend?

It is a legal extension. Legal in that the "problem bit" starts __.

I doubt that there are any C compilers that don't by default provide
extensions so I don't think it is valid to criticise any compiler writer
for extensions as long as it has a conforming mode that produces all
required diagnostics (the gcc example above does not require a diagnostics).

 

[jacob navia]

Harald van D?k said:


Implementations are permitted to provide extensions that do not affect the
behaviour of a strictly conforming program. The above code is not strictly
conforming.

Of course if implementations are called "lcc-win" you will start ranting
with no end.

It took me an enormous effort to implement my extensions without adding
any new keywords, making them 100% compatible with the C standard.

I was always told that "I am forced to emit a diagnostic at non
conforming code", that I am non standard etc etc. But obviously for
gcc you use other criteria!

gcc can do whatever it wants because it is GNU and linux, and that is
good.

lcc-win is windows and non GNU hence it is bad.

Period.

 

[jacob navia]

No, no, and no, as I suspect you already no.

Obviously if lcc-win would have something like that you would
rant with no end!

It took me a LOT of effort to implement ALL my extensions without
introducing ANY keywords, as the standard requires. But no way, I was
always branded as illegal, non standard, whatever.

When gcc does the same in a MUCH more intrusive way, then it is OK of
course, even if the -ansi flag is present!

When I have forgotten some function in my stdlib.h that shouldn't be
defined there there are rants without end, "lcc-win conforms to no
standard" etc etc.

When gcc does something much worse with the -ansi flag present nobody
says anything.

Great!

 

[jacob navia]

Of course! But if we didn't like you, we'd just ignore.

<vbg>

-

OK. Maybe I should see things that way.

Have a nice weekend.

 

[Harald van Dijk]

Harald van Dijk wrote, On 09/05/08 17:34:

This translation unit is accepted without any diagnostic by gcc -W
-Wall - ansi -pedantic:

int __attribute__((const)) zero(void) { return 0; }

Does that mean the code is valid C, that this is an error in GCC, or
that GCC does embrace-and-extend?

It is a legal extension. [...]

Yup, that's exactly it. So gcc clearly extends. The only way it can extend
without embracing-and-extending is by not embracing -- by not bothering to
try to conform to any standard. My point is that gcc does embrace-and-
extend. There's nothing wrong with that. It's extremely difficult to write
a conforming C compiler without extensions.

 

[Flash Gordon]

jacob navia wrote, On 09/05/08 18:56:

Of course if implementations are called "lcc-win" you will start ranting
with no end.

It took me an enormous effort to implement my extensions without adding
any new keywords, making them 100% compatible with the C standard.

Having no new keywords does not automatically make it conform to the
standard.

I was always told that "I am forced to emit a diagnostic at non
conforming code",

No that is not what you have been told. You have been told that in
conforming mode you have to produce the diagnostics that are required.

that I am non standard etc etc. But obviously for
gcc you use other criteria!

No, the same standard is applied, and this means that gcc does not
conform to C99 and without "-ansi -pedantic" (or equivilant) it does not
conform to any standard.

gcc can do whatever it wants because it is GNU and linux, and that is
good.

No, it is good because it provides (modulo bugs) a conforming mode.

lcc-win is windows and non GNU hence it is bad.

No, the bad part is that you take it as a personal attack when a
non-conformance is pointed out.

The not quite so bad part (but still not good) is that you have gone far
enough on C99 to no longer conform to C90 but not so far as to conform
to C99.

It is also bad that MS are not attempting going for C99 conformance and
that progress towards it on gcc has become glacial in its slowness, but
at least they both have modes conforming to earlier standards.

 

[Spiros Bousbouras]

My point is that gcc does embrace-and-
extend. There's nothing wrong with that. It's extremely difficult to write
a conforming C compiler without extensions.

Surely the amount of difficulty in writing a conforming
C compiler will be increased by adding extensions. Your
last sentence seems to suggest otherwise.

 

[Harald van Dijk]

Surely the amount of difficulty in writing a conforming C compiler will
be increased by adding extensions. Your last sentence seems to suggest
otherwise.

It will decrease if the cost of implement a few extensions is smaller than
the benefit. How will you implement the standard library headers
(particularly <stddef.h> and <tgmath.h>) without using extensions? It's
easier to just make the compiler accept a few non-standard constructs.