Pedants

[Malcolm McLean]

Re: Pedants

"santosh" <santosh.k83@gm ail.comwrote in message

>
Now if program A takes twice as long to perform some task as program B,
what does that suggest to us about their respective sources?
>

Often there is a tension between efficient and well-structured programming.

So what exactly does it suggest?

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Bob Nelson]

Re: Pedants

Richard wrote:

[..] This group is c.l.c. Not ISO C. Not C89. Just "c". And if others want
to help others with "general" C issues then good luck to them.

And since is it ``just c'', so it must be -- ``just C'', which by definition
is the C language as standardized by ISO/IEC. Any other variant is not
``just C'' but is platform-specific and not at all ``general C''.

I personally take an even more purist approach of what should be acceptable
in this newsgroup than what's now tolerated by even some of the so-called
``regulars'' of the current era. My preference (and realize it's only that)
would be to not qualify a response to an off-topic post with such wording
as:

``That's not REALLY a question about standard C.''

I would modify it as follows:

``That's not AT ALL a question about C.''

The intent is to emphasize that C is, without otherwise being modified, that
which is defined by ISO/IEC.

I find this well-known image appropriate when I see a posting about clearing
the screen, writing to the Windows registry, reading directories and other
such off-topic atrocities here in c.l.c:

http://www.ibiblio.org/Dave/Dr-Fun/d...df20000210.jpg

[santosh]

Re: Pedants

Malcolm McLean wrote:

"santosh" <santosh.k83@gm ail.comwrote in message

>>
>Now if program A takes twice as long to perform some task as program
>B, what does that suggest to us about their respective sources?
>>

Often there is a tension between efficient and well-structured
programming.
>
So what exactly does it suggest?

I see your point. Efficiency (both speed and resources consumed) is one
aspect of "quality of code". With quite a bit of assumptions, you can
also make other statements about the source code from inspecting the
disassembly. See my reply to Richard Riley. But the complexity of the
compiler makes it virtually impossible to say anything more than a few
bare observations about the source.

[Ian Collins]

Re: Pedants

Joachim Schmitz wrote:

Ben Bacarisse wrote:

>jacob navia <jacob@nospam.c omwrites:
>>

>>Dear pedantic user

>Dear Jacob
>>

>>What is a pedant?

>What is the -pedantic flag? As far as I can see you don't document
>the use of it. As such, you can hardly have faced an easier bug to
>fix -- just report "bad flag" and ignore it. Of course, if you
>intended it to do something then you have a bigger problem.
>>
>Rather than getting hot under the collar about it, I think the users
>of your compiler would be better served by a simple statement of
>intent: accepting the flag is either a simple bug (which you can fix
>in about a minute) or you do intend to offer some sort of more
>rigorous checking mode and you plan to get it working soon. Would it
>not have been simpler just to say which is the case?

>
Some simple rules when dealing with Jacob:
>
1. Don't attack Jacob, he takes it as personal offense
2. Don't criticize Jajob, he takes it as an attack, see 1.
3. Don't criticise any software Jacob developed, he takes it as personal
criticism, see 2.
4. Don't report bugs in software Jacob developed, he takes it as criticism,
see, 3.
>
In any case he'll feel personnally offended by any of the above mentioned
things. On top of that:
>
5. Better don't reply to anything Jacob writes, if there is the slightest
possibility that it might be interpreted in 2 ways, one of which may
possible offending, he'll for sure pick that interpretation and go balistic.
6. If you did reply to Jacob, don't fell offended, when he goes balistic and
calls you a liar for no good reason, this is his normal behavoir, just
ignore it, it's better for your health
7. Never ever expect Jacob ot appologize for any offense he did to you, so
far it never ever happened. Saves you from a disappointement , and is better
for your health.
>

You forgot

8. Even when proved wrong by example, we will never admit to being
wrong. See 1.

--
Ian Collins.

[jacob navia]

Re: Pedants

santosh wrote:

I see your point. Efficiency (both speed and resources consumed) is one
aspect of "quality of code".

Lcc-win is the smallest compiler system in the C world.
It is around 5 times faster than gcc in compilation
time, and in execution time it is approx 75-85% of the
speed of the gcc generated code.

This are facts. Easily measurable by anyone.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Re: Pedants

jacob navia said:

santosh wrote:

>I see your point. Efficiency (both speed and resources consumed) is one
>aspect of "quality of code".

>
Lcc-win is the smallest compiler system in the C world.
It is around 5 times faster than gcc in compilation
time, and in execution time it is approx 75-85% of the
speed of the gcc generated code.
>
This are facts. Easily measurable by anyone.

If the program doesn't have to work properly, I can easily write a compiler
system that is a thousand times smaller than yours and a thousand times
faster. There is more to quality than speed and size.

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

[jacob navia]

Re: Pedants

Richard Heathfield wrote:

jacob navia said:
>

>santosh wrote:

>>I see your point. Efficiency (both speed and resources consumed) is one
>>aspect of "quality of code".

>Lcc-win is the smallest compiler system in the C world.
>It is around 5 times faster than gcc in compilation
>time, and in execution time it is approx 75-85% of the
>speed of the gcc generated code.
>>
>This are facts. Easily measurable by anyone.

>
If the program doesn't have to work properly, I can easily write a compiler
system that is a thousand times smaller than yours and a thousand times
faster. There is more to quality than speed and size.
>

If you have nothing to say. Please do not say it here.

The "pedantic" flag is no longer supported, and if you invoke

lcc -pedantic pedantic.c

you get:

"Pedants are no longer supported!"

and the program exits!

:-)

Obviously the fact that lcc-win is much faster than gcc
or other compilers doesn't count. What counts is if it
supports c89 or maybe another more obsolete version of the language.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Tor Rustad]

Re: Pedants

santosh skrev:

Bartc wrote:
>

>"Tor Rustad" <tor_rustad@hot mail.comwrote in message
>news:08qdneqrn dhmt8DVRVnzvQA@ telenor.com...

>>Malcolm McLean skrev:
>>>
>>>Which leads us to a philosophical point. Can we tell the quality of
>>>code purely from the binaries?
>>From a security point of view, using a closed source compiler which
>>hasn't gone through external code review, is a potential security
>>risk -- as there can be a trojan horse injected in the compiled
>>programs.

>So you have some compiler source, which you then presumably have to
>compile with another binary, which must also be open source...
>>
>So where do you start? It seems that at some point you need to use a
>trusted binary.

>
No need. The BIOS could be open source and the hardware specs could also
be open source.

Well, in theory there might be no need, but in practice we don't (just)
analyze the binaries, but perform internal and external code audits of
sources. It is far easier to detect backdoors prior to compilation.

This is needed for trust-wordy systems.

Reviews are getting more important, and a number of OS'es has EAL 4
certifications these days, including SLES 10, RH 5, and soon Microsoft
have a number of such certificates too.

http://en.wikipedia.org/wiki/Evaluation_Assurance_Level

Nevertheless, software engineering has yet a long way to go, when it
comes to quality, good thing we ain't making tall buildings... :)

This way nothing inside the computer is beyond
understanding, but this is not commonly the case. An average PC
contains tons of closed source firmware, which *could* do subversive
things, even if the OS and applications were to be open source.

Well, there are a number of OS'es, which are open source, they don't
exactly have "tons" of binary blobs originating from closed source.

Also even if a program is open source, to be absolutely sure, you need
to check the complete source for the program and compile it yourself.

If the source is public, then code review can be done by many. Anyway,
by taking a peek at the source, it is normally not that hard to see how
well designed a program is.

The track record on number of bugs, also indicate what quality level a
program has. For example, that OpenBSD and the Linux kernel are high
quality, shows IMO on their track record.

Otherwise there is no guarantee that a binary of an "open source"
program that you download and use does not contain components in
additions to it's published source base.

That is not correct santosh, if the binaries was build on a trusted
system, the binaries could be digitally signed there too, and then
verified prior to installation on the target machine.

However, as long as the target machine lack any kind of HW verification
method, a Trojan horse or root kit, can invalidate this verification.


--
Tor <bwzcab@wvtqvm. vw | tr i-za-h a-z>

[Richard Heathfield]

Re: Pedants

jacob navia said:

Richard Heathfield wrote:

>jacob navia said:
>>

>>santosh wrote:
>>>I see your point. Efficiency (both speed and resources consumed) is
>>>one aspect of "quality of code".
>>Lcc-win is the smallest compiler system in the C world.
>>It is around 5 times faster than gcc in compilation
>>time, and in execution time it is approx 75-85% of the
>>speed of the gcc generated code.
>>>
>>This are facts. Easily measurable by anyone.

>>
>If the program doesn't have to work properly, I can easily write a
>compiler system that is a thousand times smaller than yours and a
>thousand times faster. There is more to quality than speed and size.
>>

>
If you have nothing to say. Please do not say it here.

Just because you don't understand me, that doesn't mean I have nothing to
say.

The "pedantic" flag is no longer supported, and if you invoke
>
lcc -pedantic pedantic.c
>
you get:
>
"Pedants are no longer supported!"

That's an implementation issue, and as such should be discussed in a
newsgroup where that implementation is topical, such as comp.compilers. lcc

and the program exits!

Fine, but hardly topical here.

:-)
>
Obviously the fact that lcc-win is much faster than gcc
or other compilers doesn't count.

Not in comp.lang.c, no, where we discuss the language, not implementations
thereof. If you want to race compilers, please do it in a newsgroup where
it's topical.

But for the record, no, if the compiler *doesn't work*, it doesn't matter
how fast it is - same as with any program.

What counts is if it
supports c89 or maybe another more obsolete version of the language.

No, what counts is that it is an implementation, and therefore needs to be
discussed in a group where it is topical, rather than here, where we
discuss the language itself, not implementations thereof. I do not expect
you to understand this because, on the many previous occasions that I have
explained it to you, you have demonstrated yourself to be incapable of
grasping the point. Nevertheless, I hope others will understand it and
take note.

But the bottom line is that a C compiler has to translate C programs
correctly. If it can't do that, it isn't really a C compiler. And you
don't get to decide what C is, any more than I do.

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

[Tor Rustad]

Re: Pedants

Bartc skrev:

"Richard Heathfield" <rjh@see.sig.in validwrote in message

[...]

>If the program doesn't have to work properly, I can easily write a
>compiler
>system that is a thousand times smaller than yours and a thousand times
>faster. There is more to quality than speed and size.

>
I think you're being too hard on this compiler (which I happen to use in
preference to half-a-dozen others).

No, Richard Heathfield is not too hard, if a compiler can't be trusted,
it shouldn't be used for anything serious.

First step is doing the job right, adding new features, will increase
the complexity, make testing harder and most likely increase the number
of defects.

How fast a C compiler runs, say very little about the correctness of the
translation.

--
Tor <bwzcab@wvtqvm. vw | tr i-za-h a-z>

[Bob Nelson]

Re: Pedants

jacob navia wrote:

Bob Nelson wrote:
>

>The intent is to emphasize that C is, without otherwise being modified,
>that which is defined by ISO/IEC.
>>
>I find this well-known image appropriate when I see a posting about
>clearing the screen, writing to the Windows registry, reading directories
>and other such off-topic atrocities here in c.l.c:

>
Yeah sure.
>
C is ISO C. Posix doesn't exist. Windows doesn't exist, the
Mac doesn't exist.

An examination of WG14/N1256 ``Committee Draft -- September 7, 2007''
ISO/IEC 9899:TC3, finds there is no mention (that I could find) of the
word ``computer'' in the document.

Therefore, although POSIX, Windows and the Mac do exist, they are not within
the scope of discussing the C language. The international standard deals
only with the behavior of an abstract machine.

Postings confined to matters involving translation unit(s) in ISO C are a
rich source of interesting material for this newsgroup. Subjects involving
POSIX, Windows and the Mac have appropriate venues elsewhere. The name of
the newsgroup says it all: comp.lang.c. This is a forum for the language C.

Mr. Navia: I know that you and Mr. Heathfield have, on more than one
occasion, had differences. You may take some small solace in knowing that I
believe that I may disagree with Mr. Heathfield concerning C99.

The standard for the C language is no longer C90 but is C99. Therefore, in
my opinion, any discussion in this newsgroup concerning C90 is only of
historic interest (much like that of K&R C or dmr's earlier
implementations ). While topical, they do not deal with current C as defined
by the international standard.

Thus the following little snippet, presuming a hosted implementation, of a
translation unit *is* C -- period (modulo a botch of my part when pasting
this):

#include <string.h>
#include <stdio.h>

int main(void)
{
char s[strlen("42") + 1]; // variable length array, standard conforming

strcpy(s, "42");

for(int i = 0; i < 2; ++i)
puts(s);

// the C language returns 0 upon reaching } [5.1.2.2.3]
}

Perhaps giving credence to arguments about the [lack of?] utilitarian value
of c.l.c., I don't care one iota about how widely used, popular or how many
implementations there are of C99 translators. Since C99 == C, that's
sufficient for me. Anything else is merely a QOI matter of little concern
when the focus is solely on the C language.

But to end this posting amicably, I admit to being a unapologetic purist and
probably an unrepentant pedant. If this draws the ire of both Mr. Navia and
Mr. Heathfield, then perhaps we have achieved peace in our time. :-)

[Richard Heathfield]

Re: Pedants

Bob Nelson said:

<lots of good stuff (or should I say 'other good stuff'?) snipped>

Postings confined to matters involving translation unit(s) in ISO C are a
rich source of interesting material for this newsgroup. Subjects
involving POSIX, Windows and the Mac have appropriate venues elsewhere.
The name of the newsgroup says it all: comp.lang.c. This is a forum for
the language C.

Right.

>
Mr. Navia: I know that you and Mr. Heathfield have, on more than one
occasion, had differences. You may take some small solace in knowing that
I believe that I may disagree with Mr. Heathfield concerning C99.

It's possible.

The standard for the C language is no longer C90 but is C99.

C99 is the de jure standard, but it won't become the de facto standard
until it is at least comparatively widely implemented (by which I mean
that it must be implemented on at least /almost/ as many mainstream
architectures as C90.

Therefore,
in my opinion, any discussion in this newsgroup concerning C90 is only of
historic interest (much like that of K&R C or dmr's earlier
implementations ). While topical, they do not deal with current C as
defined by the international standard.

I agree that C90 is topical, of course, and I agree that it doesn't deal
with "C as defined by the [current] international standard" - but it's of
more than historic interest until such time as C99 becomes the de facto
standard.

Thus the following little snippet, presuming a hosted implementation, of
a translation unit *is* C -- period (modulo a botch of my part when
pasting this):

<snip>

Yes, C99 is C! Believe it or not, I do agree with that.

<snip>

Perhaps giving credence to arguments about the [lack of?] utilitarian
value of c.l.c., I don't care one iota about how widely used, popular or
how many implementations there are of C99 translators.

That is perhaps the difference between us. I like a language I can actually
use. But your point is valid and well-made.

<snip>

But to end this posting amicably, I admit to being a unapologetic purist
and probably an unrepentant pedant. If this draws the ire of both Mr.
Navia and Mr. Heathfield, then perhaps we have achieved peace in our
time. :-)

It seems that peace in our time may have to wait a little. :-)

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

[Bob Nelson]

Re: Pedants

Richard Heathfield wrote:

Bob Nelson said:
>
[...]
>

>The standard for the C language is no longer C90 but is C99.

>
C99 is the de jure standard, but it won't become the de facto standard
until it is at least comparatively widely implemented (by which I mean
that it must be implemented on at least /almost/ as many mainstream
architectures as C90.

My daily commute on Stemmons Freeway in Carrollton, TX [USA] exposes me to
the reality of de jure vs. de facto standards. The city's traffic police
accept only the de jure standard with a pedantically (-Wall -Wextra)
enforced speed limit not to exceed 60.000000 MPH. Greater than that yields
some form of overflow and subsequent UB.

>[...]
>>
>Perhaps giving credence to arguments about the [lack of?] utilitarian
>value of c.l.c., I don't care one iota about how widely used, popular or
>how many implementations there are of C99 translators.

>
That is perhaps the difference between us. I like a language I can
actually use. But your point is valid and well-made.

Much appreciated, Richard. I was actually prepared for a response more along
the lines of ``Get thee to a monastery!''. :-)

I'll bow out for a while and get back to tweaking the ``abstract machine''
on the other side of my desk.

[Ben Bacarisse]

Re: Pedants

Richard<rgrdev@ gmail.comwrites :

"Malcolm McLean" <regniztar@btin ternet.comwrite s:

<snip>

>Which leads us to a philosophical point. Can we tell the quality of
>code purely from the binaries?

>
Yes.
>
Does it work and do the job it says it does?
>
Simple really.

That you think this is simple suggests (as I have thought before)
that we think about software in totally different ways.

A compiler is quite complex, but given a year (maybe even 6 months) of
careful study of the source code, test cases and debugging runs I
could probably get reasonably confident that a purported C compiler
did or did not do what it was supposed to do.

If the software has lots of bugs, then one can find them by random
testing, but given a very good (but still possibly faulty) compiler, I
don't think I could gain the same degree of confidence from a year's
testing. There is a real philosophical issue here: the static
comprehension of a program's text is easier than the enumeration of
its behaviour.

Even knowing what a program is supposed to do is far from simple. It
is particularly problematic in this case: I don't think there is any
statement of what the compiler (lcc-win32) should do, so how can one
even start? There are some basics one might assume, but then what? I
have asked for clarification and got none. I think Jacob prefers the
specification of what lcc-win32 does to be left vague. This makes it
very hard to know if it "does the job it says it does".

Case in point, is lcc-win32's treatment of:

#include <stdio.h>

void f(int n, int a[n][n])
{
printf("%d\n", a[2][2]);
}

int main(void)
{
int A[3][3] = {{1,2,3},{4,5,6 },{7,8,9}};
f(3, A);
}

"doing the job is says it does"? You get a diagnostic: "Warning
vla-b2.c: 11 assignment of pointer to array 3 of int to pointer to
array 4 of int" and the resulting binary prints "4198554". Where does
one go to find out what the above program should do under the compiler
in question? A C90 compiler is permitted to do almost anything it
likes with this code and a C99 one should print "9", I think, but we
don't know what sort of non-C99 lcc-win32 is.

I don't think it is fair to call anything like this a bug since there
is no claim to conformance.

--
Ben.

[Keith Thompson]

Re: Pedants

jacob navia <jacob@nospam.c omwrites:
[snip]

The "pedantic" flag is no longer supported,

[snip]

Then why the HELL didn't you just say that in response to the original
question? Sheesh.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"