Re: Pedants

Richard wrote:

santosh <santosh.k83@xxxxxxxxx> writes:

Malcolm McLean wrote:

"Joachim Schmitz" <nospam.jojo@xxxxxxxxxxxxxxxxxx> wrote 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."

.

Relevant Pages

  • Re: ACKPACK
    ... The ACK produces generic binaries in ack.out format, ... that running on Linux using something like iBCS, but I doubt it's worth the ... > If it's a native compiler, does it do a.out or ELF? ...
    (comp.os.minix)
  • Re: optimized code
    ... > All depends on what exactly you are measuring, how you are comparing and ... > take advantage of the back-end optimizer which can do a better job than ... > produced by the C++ compiler, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Pedants
    ... So you have some compiler source, which you then presumably have to ... analyze the binaries, but perform internal and external code audits of sources. ... contains tons of closed source firmware, ...
    (comp.lang.c)
  • Re: Heisenbergsche Segfaults
    ... > Binaries, oder habe ich das jetzt falsch verstanden? ... Die Compiler werden einmal gebaut, ... Bei meinem ersten LFS-System wurde der gcc dreimal gebaut, ... Mir ist z.B. seit meinem ersten LFS noch nie die Bash ...
    (de.comp.os.unix.linux.misc)
  • Re: Pedants
    ... you'll want to write some more (programming is very more-ish), ... However Jacob publishes only his binaries. ... If the machine code for both the binaries was derived from the ... anything about the quality of the code, it only says something about the size of compiler system software and the lack of automated testing. ...
    (comp.lang.c)