Pedants

[Walter Roberson]

Re: Pedants

In article <g3ik4r$q0s$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>Dear pedantic user

>What is a pedant?

>According to dictionary.com you are:

>1. a person who makes an excessive or inappropriate display of learning.
>2. a person who overemphasizes rules or minor details.
>3. a person who adheres rigidly to book knowledge without regard to
>common sense.

>I am very glad that this flag, done for people like you
>works as expected.

"They like me. They really like me!"
--
"There's no term to the work of a scientist." -- Walter Reisch

[Joachim Schmitz]

Re: Pedants

Richard Heathfield wrote:

Joachim Schmitz said:
>

>Richard Heathfield wrote:

>>Some simple rules when dealing with critics:
>>>
>>1. If they're criticising your C code, listen to them, make sure
>>they're right, and - if they are - fix the code.

>Guess you meant "make sure _whether_ they are right", otherwise you
>may need to introduce bugs just to make them being right 8-)

>
I presume you meant "be right", rather than "being right". :-)

Tribute to english not being my native language

>>2. Don't forget to thank them for educating them.

>guess you meant: "educating _you_"

>
I did, yes. Thanks.
>

>>

>>3. If you can't stand your code being criticised, don't write any.

>guess you mean: "don't _publish_ any"

>
No, I meant "don't write any". Because if you write some code, you'll
want to write some more (programming is very more-ish), and then
you'll write even more, and sooner or later you'll get to the point
where you think you're pretty good, and then some day you'll want to
show someone your stuff. And then they'll criticise it. And that
would be just awful, right?

However: the criticism starts only when you publish

>>Jacob Navia is not immune to criticism just because he doesn't know
>>how to handle it properly. One day, he will learn that criticism is
>>good and useful.

>hope dies last, doesn't it?

>
As Doctor Johnson said of a second marriage, "it is the triumph of
hope over experience".

Great 8-), guess I'll steal and use that sooner or later...

Bye, Jojo

[Malcolm McLean]

Re: Pedants

"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote in message n

Richard Heathfield wrote:

>Joachim Schmitz said:
>>
>>
>No, I meant "don't write any". Because if you write some code, you'll
>want to write some more (programming is very more-ish), and then
>you'll write even more, and sooner or later you'll get to the point
>where you think you're pretty good, and then some day you'll want to
>show someone your stuff. And then they'll criticise it. And that
>would be just awful, right?

However: the criticism starts only when you publish
>

However Jacob publishes only his binaries. I can't actually remember seeing
any C source by him. He's not one of those people who, like me, are
constantly providing little snippetts.

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

--
Free games and programming goodies.

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

[Richard]

Re: Pedants

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

"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote in message n

>Richard Heathfield wrote:

>>Joachim Schmitz said:
>>>
>>>
>>No, I meant "don't write any". Because if you write some code, you'll
>>want to write some more (programming is very more-ish), and then
>>you'll write even more, and sooner or later you'll get to the point
>>where you think you're pretty good, and then some day you'll want to
>>show someone your stuff. And then they'll criticise it. And that
>>would be just awful, right?

>However: the criticism starts only when you publish
>>

However Jacob publishes only his binaries. I can't actually remember
seeing any C source by him. He's not one of those people who, like me,
are constantly providing little snippetts.
>
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.

[santosh]

Re: Pedants

Malcolm McLean wrote:

"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote in message n

>Richard Heathfield wrote:

>>Joachim Schmitz said:
>>>
>>>
>>No, I meant "don't write any". Because if you write some code,
>>you'll want to write some more (programming is very more-ish), and
>>then you'll write even more, and sooner or later you'll get to the
>>point where you think you're pretty good, and then some day you'll
>>want to show someone your stuff. And then they'll criticise it. And
>>that would be just awful, right?

>However: the criticism starts only when you publish
>>

However Jacob publishes only his binaries. I can't actually remember
seeing any C source by him. He's not one of those people who, like me,
are constantly providing little snippetts.

However I recall him posting various minor snippets of code
occasionally, mainly from his standard library. In the past he used to
post code more often than he does these days.

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

We must first define what we mean by "quality of code", and this is not
a simple job, as the difference between the source of various versions
of functionally identical programs is largely a subjective matter,
IMHO.

If the binary happens to do correctly all that it is specified to do
under reasonable conditions, then we can say that the binary
is "working", but we still can't say anything much about the source
from examining the machine code. We can attempt a decompilation, but
the resulting source is hardly likely to be better than travesty of the
original source.

Still examining the binary versions of program under a debugger and
under various "stress" conditions, and taking comparative measurements
can enable is to state many objective statements about the machine
code. If the machine code for both the binaries was derived from the
same compiler under the same switches, then differences can be safely
attributed to the source from which it was compiled.

[Richard]

Re: Pedants

santosh <santosh.k83@gm ail.comwrites:

Malcolm McLean wrote:
>

>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote in message n

>>Richard Heathfield wrote:
>>>Joachim Schmitz said:
>>>>
>>>>
>>>No, I meant "don't write any". Because if you write some code,
>>>you'll want to write some more (programming is very more-ish), and
>>>then you'll write even more, and sooner or later you'll get to the
>>>point where you think you're pretty good, and then some day you'll
>>>want to show someone your stuff. And then they'll criticise it. And
>>>that would be just awful, right?
>>However: the criticism starts only when you publish
>>>

>However Jacob publishes only his binaries. I can't actually remember
>seeing any C source by him. He's not one of those people who, like me,
>are constantly providing little snippetts.

>
However I recall him posting various minor snippets of code
occasionally, mainly from his standard library. In the past he used to
post code more often than he does these days.
>

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

>
We must first define what we mean by "quality of code", and this is not
a simple job, as the difference between the source of various versions
of functionally identical programs is largely a subjective matter,
IMHO.
>
If the binary happens to do correctly all that it is specified to do
under reasonable conditions, then we can say that the binary
is "working", but we still can't say anything much about the source
from examining the machine code. We can attempt a decompilation, but
the resulting source is hardly likely to be better than travesty of the
original source.

Why do you insist on waffling on about the obvious Santosh? Clearly we
can not look at the source if only the binary is there.

>
Still examining the binary versions of program under a debugger and
under various "stress" conditions, and taking comparative measurements

What comparative measurements? Comparative against what?

can enable is to state many objective statements about the machine
code. If the machine code for both the binaries was derived from the
same compiler under the same switches, then differences can be safely
attributed to the source from which it was compiled.

So, in less words "if it works its good". The binary testing will tell
you next to nothing about type safety assuming the numbers in the tests
fall into compatible ranges for example.

I would be interested to see what you think you are comparing against here.

[Tor Rustad]

Re: Pedants

Malcolm McLean skrev:

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

Yup, black box testing can detect quite a number of defects. For C
compilers, Perennial & Plum Hall has validation test suits, mandatory
for UNIX 03 certification.


A C compiler, is like a batch program... I find lots of programs harder
to test than "batch" like programs. :)


Code review, in particular when done here, is also an interesting
experience, not to be recommended for certain category of "professionals" .


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.

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

[Serve Lau]

Re: Pedants


"Richard" <rgrdev@gmail.c omschreef in bericht
news:g3j9k7$f69 $5@registered.m otzarella.org.. .

santosh <santosh.k83@gm ail.comwrites:
>

>Malcolm McLean wrote:
>>

>>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote in message n
>>>Richard Heathfield wrote:
>>>>Joachim Schmitz said:
>>>>>
>>>>>
>>>>No, I meant "don't write any". Because if you write some code,
>>>>you'll want to write some more (programming is very more-ish), and
>>>>then you'll write even more, and sooner or later you'll get to the
>>>>point where you think you're pretty good, and then some day you'll
>>>>want to show someone your stuff. And then they'll criticise it. And
>>>>that would be just awful, right?
>>>However: the criticism starts only when you publish
>>>>
>>However Jacob publishes only his binaries. I can't actually remember
>>seeing any C source by him. He's not one of those people who, like me,
>>are constantly providing little snippetts.

>>
>However I recall him posting various minor snippets of code
>occasionally , mainly from his standard library. In the past he used to
>post code more often than he does these days.
>>

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

>>
>We must first define what we mean by "quality of code", and this is not
>a simple job, as the difference between the source of various versions
>of functionally identical programs is largely a subjective matter,
>IMHO.
>>
>If the binary happens to do correctly all that it is specified to do
>under reasonable conditions, then we can say that the binary
>is "working", but we still can't say anything much about the source
>from examining the machine code. We can attempt a decompilation, but
>the resulting source is hardly likely to be better than travesty of the
>original source.

>
Why do you insist on waffling on about the obvious Santosh? Clearly we
can not look at the source if only the binary is there.
>

>>
>Still examining the binary versions of program under a debugger and
>under various "stress" conditions, and taking comparative measurements

>
What comparative measurements? Comparative against what?
>

>can enable is to state many objective statements about the machine
>code. If the machine code for both the binaries was derived from the
>same compiler under the same switches, then differences can be safely
>attributed to the source from which it was compiled.

>
So, in less words "if it works its good". The binary testing will tell
you next to nothing about type safety assuming the numbers in the tests
fall into compatible ranges for example.

Take the case of the -pedantic flag not working with math.h. It doesnt say
anything about the quality of the code, it only says something about the
size of compiler system software and the lack of automated testing.

[Bartc]

Re: Pedants


"Tor Rustad" <tor_rustad@hot mail.comwrote in message
news:08qdneqrnd hmt8DVRVnzvQA@t elenor.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.

--
bartc

[santosh]

Re: Pedants

Bartc wrote:

>
"Tor Rustad" <tor_rustad@hot mail.comwrote in message
news:08qdneqrnd hmt8DVRVnzvQA@t elenor.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. 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.

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.
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.

[Tor Rustad]

Re: Pedants

Bartc skrev:

"Tor Rustad" <tor_rustad@hot mail.comwrote in message
news:08qdneqrnd hmt8DVRVnzvQA@t elenor.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.

Thompson has a classic paper on the subject, I would rank his compiler
hack among the top 10 of all time.

We simply trust major organizations to have sufficient QA to detect
injection of trojans. I believe there was a case some years ago, when
someone had injected a backdoor in the GNU GCC sources, which was
detected by the public.

Lots of people argue compilers should be banned from production systems,
but I can't agree with this. Test systems has less trust, and if someone
is able to modify the compiler there, and it is used to build production
programs, the attacker/insider can be able to get access to higher
privilege level, without being authorized for it.

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

[Tony Quinn]

Re: Pedants

In message <b9a7k.13364$E4 1.4308@text.new s.virginmedia.c om>, Bartc
<bc@freeuk.comw rites

>
>"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.

Have you read this?

http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

--
If one person has delusions, we call them psychotic. If, however, 1.5 billion
people have delusions we must apparently call them a religious group, and
respect their delusionary state.

[santosh]

Re: Pedants

Richard wrote:

santosh <santosh.k83@gm ail.comwrites:
>

>Malcolm McLean wrote:
>>

>>"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote in message
>>n
>>>Richard Heathfield wrote:
>>>>Joachim Schmitz said:
>>>>>
>>>>>
>>>>No, I meant "don't write any". Because if you write some code,
>>>>you'll want to write some more (programming is very more-ish), and
>>>>then you'll write even more, and sooner or later you'll get to the
>>>>point where you think you're pretty good, and then some day you'll
>>>>want to show someone your stuff. And then they'll criticise it.
>>>>And that would be just awful, right?
>>>However: the criticism starts only when you publish
>>>>
>>However Jacob publishes only his binaries. I can't actually remember
>>seeing any C source by him. He's not one of those people who, like
>>me, are constantly providing little snippetts.

>>
>However I recall him posting various minor snippets of code
>occasionally , mainly from his standard library. In the past he used
>to post code more often than he does these days.
>>

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

>>
>We must first define what we mean by "quality of code", and this is
>not a simple job, as the difference between the source of various
>versions of functionally identical programs is largely a subjective
>matter, IMHO.
>>
>If the binary happens to do correctly all that it is specified to do
>under reasonable conditions, then we can say that the binary
>is "working", but we still can't say anything much about the source
>from examining the machine code. We can attempt a decompilation, but
>the resulting source is hardly likely to be better than travesty of
>the original source.

>
Why do you insist on waffling on about the obvious Santosh? Clearly we
can not look at the source if only the binary is there.
>

>>
>Still examining the binary versions of program under a debugger and
>under various "stress" conditions, and taking comparative
>measurements

>
What comparative measurements? Comparative against what?
>

>can enable is to state many objective statements about the machine
>code. If the machine code for both the binaries was derived from the
>same compiler under the same switches, then differences can be safely
>attributed to the source from which it was compiled.

>
So, in less words "if it works its good". The binary testing will tell
you next to nothing about type safety assuming the numbers in the
tests fall into compatible ranges for example.
>
I would be interested to see what you think you are comparing against
here.

Take the case of two binary programs that are specified to do exactly
the same task and with identical interfaces. Further assume that both
were compiled by the same compiler program and with identical compiler
options (except for things like source file naming of course). We shall
also execute both the programs under as similar a condition as
possible.

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? If we
disassemble two functionally identical routines in both the programs
and we observe the following pseudo-assembler for program A:

LOAD r0, [BP + 8]
LOAD r1, 0
loop:
PUSH [r0 + r1]
CMP [SP], 0
JE ret
CALL _putchar
ADD SP, 1
INC r1
JUMP loop
ret:
ADD SP, 1
RET

and the following for program B:

PUSH stdout
PUSH [BP + 8]
CALL _fputs
ADD SP, 8
RET

What can you conclude about the source for the respective programs?

There are many other similar comparative measurements and examinations
of the binaries that can be done to suggest the possible nature of the
original source code, provided the conditions of translation and
execution were and are "similar enough."

[CBFalconer]

Re: Pedants

Malcolm McLean wrote:

>

.... snip ...

>
However Jacob publishes only his binaries. I can't actually
remember seeing any C source by him. He's not one of those people
who, like me, are constantly providing little snippetts.
>
Which leads us to a philosophical point. Can we tell the quality
of code purely from the binaries?

Well, his principal item is labelled as a 'C compiler', which has a
fairly strict published standard, casually known as the C99
standard. This gives us an easily applied criterion - simply
report all failures to comply with that C standard.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[santosh]

Re: Pedants

CBFalconer wrote:

Malcolm McLean wrote:

>>

... snip ...

>>
>However Jacob publishes only his binaries. I can't actually
>remember seeing any C source by him. He's not one of those people
>who, like me, are constantly providing little snippetts.
>>
>Which leads us to a philosophical point. Can we tell the quality
>of code purely from the binaries?

>
Well, his principal item is labelled as a 'C compiler', which has a
fairly strict published standard, casually known as the C99
standard. This gives us an easily applied criterion - simply
report all failures to comply with that C standard.

Bugs in the binary tell us about possible bugs in the source, which is
one indication of the "quality" of the source code, but beyond that one
needs to examine the disassembly of the program and examine it's
machine code and performance against a functionally identical,
identically compiled, "control" program, to say more about
the "quality" of the source code.