Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #937 > unrolled thread

Re: Learning to code by reading code (was: The way to read STL source code)

Back to article view | Back to comp.lang.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Learning to code by reading code (was: The way to read STL source code) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-18 19:00 -0500
    Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-18 22:34 -0600
    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
      Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-19 10:42 +0100
        Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-19 22:34 +0000
          Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 12:22 +0100
      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 03:39 -0500
    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
      Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-19 08:40 -0800
        Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-19 13:17 -0600
          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:32 -0800
            Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:09 -0800
                Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 15:11 +0100
                  Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 07:39 -0800
        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 04:14 -0500
          Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 11:14 +0100
            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:13 -0800
          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:49 -0800
            Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:18 -0800
                Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-20 13:53 +0000
                  Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:32 -0800
                    Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-21 16:16 +0100
                      Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:40 -0800
            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 17:36 -0500
              Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-21 00:45 +0100
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:35 -0500
                  Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:48 -0800
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:12 -0800
                    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:12 -0500
                      Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 04:30 -0800
                        Re: Learning to code by reading code Geoff <geoff@invalid.invalid> - 2012-02-22 10:45 -0800
                          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 01:12 -0800
                        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:34 -0500
                          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 05:46 -0800
                            Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:38 +0100
                              Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:40 +0100
                              Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 09:38 +0100
                            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-25 05:25 -0500
                              Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-25 12:50 +0100
                              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-25 06:13 -0800
                                Re: Learning to code by reading code Gareth Owen <gwowen@gmail.com> - 2012-02-26 07:20 +0000
              Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:23 +0000
                Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:43 +0000
                  Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:47 -0500
                    Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:09 +0000
                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:38 -0500
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:31 -0500
                  Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:05 +0000
                    Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-21 12:21 +0100
                    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:04 -0500
                  Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-21 11:01 +0000
                    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
                      Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-22 12:59 +0000
                        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:03 -0500
                          Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-24 14:20 +0000
              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:27 -0800
          Re: Learning to code by reading code Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 22:25 +0100
            Re: Learning to code by reading code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-26 08:47 +0000
              Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-26 10:55 +0000
          Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 08:59 +0100
            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
              Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 13:47 +0100
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 06:21 -0500
          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:08 -0800
    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
    Re: Learning to code by reading code Marco van de Voort <marcov@toad.stack.nl> - 2012-02-19 11:27 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#971 — Re: Learning to code by reading code

On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com...
> On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> >news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On
> > Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>


> > > But I use an imaginary machine [...]

[if I do insist on compilign to machine code]

> > How do you confirm correctness of both high-level and low-level code with an
> > imaginary machine?
>
> How do you "confirm correctness" by translating it into I86 assembler?
> to me "correctness" is a mathematical property.
>
> #io_x in his ot language
> #balle; non puoi dimostrare la correttezza matematica di una espressione
> #che ha diversi risultati dipendendo dalla macchina effettiva in cui gira...

english please

> And if its good enough for Knuth...
>
> > Is your confirmation of correctness imaginary also? ...
>
> code inspection, DbC, unit test
>
> .....
>
> > Then, I'd quess you won't get fired for producing faulty code either ...
> > So, that qualifies you as either a novice or hobbyist. (Yes, I suspect you
> > probably aren't ...) A professional would do so as a matter of course.
>
> no. I known plenty of professional progarmmers and vanishingly few of
> them look at the assembler. Most would laugh at the idea.
>
> #so they program what?

they program in C (or C++ or whatever)

> not a machine, a machine need a precise language
> #pheraps they program their imaginary machine != every machine in this planet

quarks. it's quarks all the way down

[toc] | [prev] | [next] | [standalone]

#974 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com...
> On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
>> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel 
>> messaggionews:2bc2a617-e283-44c7-9fd3-
>> How do you "confirm correctness" by translating it into I86 assembler?
>> to me "correctness" is a mathematical property.
>>
>> #io_x in his ot language
>> #balle; non puoi dimostrare la correttezza matematica di una espressione
>> #che ha diversi risultati dipendendo dalla macchina effettiva in cui 
>> gira...
>
> english please

As I understood it: "Nonsense; you can't demonstrate the mathematical 
correction of an expression that has different results depending on the 
machine in which it runs".

Although since that almost makes sense, it might not be quite right..


-- 
bartc  

[toc] | [prev] | [next] | [standalone]

#988 — Re: Learning to code by reading code

On Feb 20, 1:53 pm, "BartC" <b...@freeuk.com> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
>
> news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com...
>
> > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> >> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> >> messaggionews:2bc2a617-e283-44c7-9fd3-
> >> How do you "confirm correctness" by translating it into I86 assembler?
> >> to me "correctness" is a mathematical property.
>
> >> #io_x in his ot language
> >> #balle; non puoi dimostrare la correttezza matematica di una espressione
> >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui
> >> gira...
>
> > english please
>
> As I understood it: "Nonsense; you can't demonstrate the mathematical
> correction of an expression that has different results depending on the
> machine in which it runs".

and so? If you have a clear model of each machine then you perhaps
prove it would work on all of them. I really not sure what your point
is. The C abstract seems a reasonable thing to try and prove things
for. (Ok might be a bit messy)

> Although since that almost makes sense, it might not be quite right..

[toc] | [prev] | [next] | [standalone]

#995 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:539cbcaa-e2ae-40d3-adde-e347bf18d9c5@ge5g2000vbb.googlegroups.com...
On Feb 20, 1:53 pm, "BartC" <b...@freeuk.com> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
>
> news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com...
>
> > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> >> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> >> messaggionews:2bc2a617-e283-44c7-9fd3-
> >> How do you "confirm correctness" by translating it into I86 assembler?
> >> to me "correctness" is a mathematical property.
>
> >> #io_x in his ot language
> >> #balle; non puoi dimostrare la correttezza matematica di una espressione
> >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui
> >> gira...
>
> > english please
>
> As I understood it: "Nonsense; you can't demonstrate the mathematical
> correction of an expression that has different results depending on the
> machine in which it runs".

and so? If you have a clear model of each machine then you perhaps
prove it would work on all of them. I really not sure what your point
is. The C abstract seems a reasonable thing to try and prove things
for. (Ok might be a bit messy)

#you have to say just what a machine is...
#one has to program only one machine
#or the one machine is a subMachine of the machine
#and not a set of machines or cpus

#but
#if all cpu have register of 32 bits with usual 32 bit
#jump operation on code
#it would be possible programm all these cpu in the subcpu
#of 32 bit as it is one portable cpu, as just one machine

> Although since that almost makes sense, it might not be quite right..

[toc] | [prev] | [next] | [standalone]

#996 — Re: Learning to code by reading code

On Feb 21, 3:16 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:539cbcaa-e2ae-40d3-adde-e347bf18d9c5@ge5g2000vbb.googlegroups.com...
> On Feb 20, 1:53 pm, "BartC" <b...@freeuk.com> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> >news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com...
> > > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:

> > >> How do you "confirm correctness" by translating it into I86 assembler?
> > >> to me "correctness" is a mathematical property.
>
> > >> #io_x in his ot language
> > >> #balle; non puoi dimostrare la correttezza matematica di una espressione
> > >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui
> > >> gira...
>
> > > english please
>
> > As I understood it: "Nonsense; you can't demonstrate the mathematical
> > correction of an expression that has different results depending on the
> > machine in which it runs".
>
> and so? If you have a clear model of each machine then you perhaps
> prove it would work on all of them. I really not sure what your point
> is. The C abstract seems a reasonable thing to try and prove things
> for. (Ok might be a bit messy)

A better answer from me would have been "so don't do that. Use a
stable abstract machine to do do your verification of correctness on."

And I'm not sure an I86 qualifies as such a stable machine.

> #you have to say just what a machine is...

the C abstract machine

> #one has to program only one machine
> #or the one machine is a subMachine of the machine
> #and not a set of machines or cpus

well as long as all implementatons obey the semantics of the C
abstract machine we don't have a problem. In a sense this is what Rod
Pemberton is doing; he's inspecting each implementation to ensure it
complies with the C abstract machine semantics.

> #but
> #if all cpu have register of 32 bits with usual 32 bit
> #jump operation on code
> #it would be possible programm all these cpu in the subcpu
> #of 32 bit as it is one portable cpu, as just one machine

seems way to low level to me. Who cares if its a 32 bit machien or a
19 bit machine? You do know there are 64 bit machines around now?

and again "32 bit" gives way to much leeway for your sort of
verifiction. What if its a 32 ARM?

<snip>

[toc] | [prev] | [next] | [standalone]

#982 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com...
> On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> > [a Clike language] most likely inherited the basic
> > functionality that a programmer needs to know.
>
> exceptions, closures, continuations, modads,
>
> lost of stuff C doesn't provide.

Don't you mean: lots of stuff C doesn't need? ...

How many of the languages which have a language feature that is
"missing" from C are compiled to C or once were?

(The great majority of them do or did.  That includes C++ at one point in
time via Cfront.  Nearly all modern dynamicly typed languages do.)

> > How do you know your compiler is compliant with a specification,
> > or your compiler accurately implements what you expect your code
> > to do? Testing only? What if you missed something you could've
> > caught had you simply just read the assembly?
>
> in my experience compiler bugs are very rare

Well, you must not have much experience.  Or, you've just never noticed the
errors because 1) you've never studied or verified the assembly output and
2) the error was never "triggered".  I've found either compilation errors or
library coding errors with most of the C compilers I've used.  One compiler
optimized away code that shouldn't have been, but only for one intermediate
optimization level.  All optimization levels above or below the intermediate
level worked correctly.  Another had type conversion errors in the assembly
when a specific type was used with any other type.  In one library, an
erroneously coded function was supposed to return three states, but returned
only two.  Issues like these were not found in compilers where you'd expect
them, say SmallC, but in quality compilers, like GNU C, OpenWatcom, etc.
The problem with not looking at the assembly is that errors can exist for
exceptionally long time periods before being noticed.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#983 — Re: Learning to code by reading code

Op 20-Feb-12 23:36, Rod Pemberton schreef:
> "Nick Keighley"<nick_keighley_nospam@hotmail.com>  wrote in message
> news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com...
>> On Feb 20, 9:14 am, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
>> wrote:
> ...
>
>>> [a Clike language] most likely inherited the basic
>>> functionality that a programmer needs to know.
>>
>> exceptions, closures, continuations, modads,
>>
>> lost of stuff C doesn't provide.
>
> Don't you mean: lots of stuff C doesn't need? ...

The language itself doesn't need anything, the programmer however might 
appreciate some language features which makes him/her more productive.

But if you consider features not strictly necessary to make a 
programming language Turing complete as unnecessary, maybe BF is the 
language for you.

> How many of the languages which have a language feature that is
> "missing" from C are compiled to C or once were?

Even though it might be possible to compile those languages to C, the 
language constructs may still be very alien to C programmers. And the 
code these language constructs generate would never be written by a sane 
C programmer, simply because it is not practical if you have write it 
yourself.

> (The great majority of them do or did.  That includes C++ at one point in
> time via Cfront.  Nearly all modern dynamicly typed languages do.)

>>> How do you know your compiler is compliant with a specification,
>>> or your compiler accurately implements what you expect your code
>>> to do? Testing only? What if you missed something you could've
>>> caught had you simply just read the assembly?
>>
>> in my experience compiler bugs are very rare
>
> Well, you must not have much experience.  Or, you've just never noticed the
> errors because 1) you've never studied or verified the assembly output and
> 2) the error was never "triggered".  I've found either compilation errors or
> library coding errors with most of the C compilers I've used.  One compiler
> optimized away code that shouldn't have been, but only for one intermediate
> optimization level.  All optimization levels above or below the intermediate
> level worked correctly.  Another had type conversion errors in the assembly
> when a specific type was used with any other type.  In one library, an
> erroneously coded function was supposed to return three states, but returned
> only two.

If things don't work as expected I suspect the code being fed into the 
compiler first, only as a last resort I inspect the assembly output of 
the compiler. In the past twenty years I have run into maybe 3 or 4 
compiler bugs, and about the same number in the libraries that came with 
them (on mainstream compilers, the statistics are a lot worse for some 
oddball compilers). I consider that rare, especially compared to most 
other software products. Now I'm sure that there are more bug in the 
compiler than I have been bitten by, but inspecting every assembly 
instruction generated by the compiler just isn't practical for software 
products where the HLL code consists of several million lines.

> Issues like these were not found in compilers where you'd expect
> them, say SmallC, but in quality compilers, like GNU C, OpenWatcom, etc.
> The problem with not looking at the assembly is that errors can exist for
> exceptionally long time periods before being noticed.

Even if you analyze the assembly output, you still don't know if the 
code executes as intended. Many processors have lots of erratas and 
execute some instructions incorrectly in some corner cases. You might 
want to consider analyzing the processor design itself, just to be sure.

[toc] | [prev] | [next] | [standalone]

#989 — Re: Learning to code by reading code

"Dombo" <dombo@disposable.invalid> wrote in message
news:4f42daff$0$14714$5fc3050@news.tiscali.nl...
...

> The [C] language itself doesn't need anything, the
> programmer however might appreciate some language
> features which makes him/her more productive.
>

C is very feature rich.  You can do 97% of what needs to be done with C with
just the C language and stdio.h, if you exclude a handful of functions that
were placed in the 'wrong' include files.  If you don't like extra coding
you can use string.h.  There is no need for ctype.h whatsoever.  The
remainder of the C library adds more "productive enhancing" code than your
heart could ever desire ...  If you took a language completely devoid of
features, like BF which you've cited, then perhaps you have an argument.

> But if you consider features not strictly necessary to make a
> programming language Turing complete as unnecessary, maybe
> BF is the language for you.

1) My understanding is that no programming language can be implemented as
Turing complete due to architecture constraints such as fixed size integers
and limited memory.

2) BF is novel, but it is currently too simple to program with
effectiveness.  One of the serious issues it has is it's minimalism.
Various attempts have been made to enhance BF, such as PBrain and Toadskin.
Procedures is one of the most common thing added to the language.  PBrain
adds that functionality but uses integers to represent the procedure.  This
complicates the use of the procedures.  It also complicates the conversion
of BF with PBrain procedures to other languages like C, since a cell may
have a changing value, therefore call different procedures at different
times.  Toadskin adds the ability to group operators into named sequences,
which is procedure like and Forth-like.  IMO, BF's serious problem is that
it is lacking direct, basic support for integers and characters as ASCII.
Values must be constructed from increment or decrement loops.  I've not seen
variants of BF add the capability to express integers or characters
directly.  That ability combined with the ability to do procedures would
make
it roughly as powerful as a simple C compiler of yesteryear.  You can check
out Esolangs for more info on such languages:

http://esolangs.org/wiki/Main_Page

> > How many of the languages which have a language feature that is
> > "missing" from C are compiled to C or once were?
>
> Even though it might be possible to compile those languages to C, the
> language constructs may still be very alien to C programmers. And the
> code these language constructs generate would never be written by a sane
> C programmer, simply because it is not practical if you have write it
> yourself.

I would disagree with both claims.  One could claim that being able to do so
depends on skill level and work ethic.  No skill?  Lazy?

> If things don't work as expected I suspect the code being fed into the
> compiler first, only as a last resort I inspect the assembly output of
> the compiler.

Ah, but you do check assembly, in contrast to NK's claim that that is
laughable.

> In the past twenty years I have run into maybe 3 or 4
> compiler bugs, and about the same number in the libraries that came with
> them (on mainstream compilers, the statistics are a lot worse for some
> oddball compilers).

Again, you've confirm my experiences in contrast to NK's claims.

> Even if you analyze the assembly output, you still don't know if the
> code executes as intended.

Exactly.  You won't know the code executes as intended until it is executed,
which was why I asked this of NK:

RP> How do you confirm correctness of both high-level and
RP> low-level code with an imaginary machine?  Is your
RP> confirmation of correctness imaginary also? ...

To which, I got more than one absurd response that imaginary
confirmation of correctness was entirely valid ...


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#997 — Re: Learning to code by reading code

On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Dombo" <do...@disposable.invalid> wrote in message

<snip>

> > In the past twenty years I have run into maybe 3 or 4
> > compiler bugs, and about the same number in the libraries that came with
> > them (on mainstream compilers, the statistics are a lot worse for some
> > oddball compilers).
>
> Again, you've confirm my experiences in contrast to NK's claims.

3 or 4 in 20 years sounds about right to me (a little high). Sounds
pretty low to me.

NK claimed bugs in compilers were pretty unusual. Sounds like we
agree.

> > Even if you analyze the assembly output, you still don't know if the
> > code executes as intended.
>
> Exactly.  You won't know the code executes as intended until it is executed,

you can have a pretty good idea. And saring at megabytes of assembler
ain't gonna help you.

> which was why I asked this of NK:
>
> RP> How do you confirm correctness of both high-level and
> RP> low-level code with an imaginary machine?  Is your
> RP> confirmation of correctness imaginary also? ...

oh were you asking if I did unit tests? Yes various validations are
done ***on the HLL code***. Including inspection, unit test and system
test. Whats that got to do with asesmbly code?

> To which, I got more than one absurd response that imaginary
> confirmation of correctness was entirely valid ...

have you heard of DbC or code inspection?

[toc] | [prev] | [next] | [standalone]

#1003 — Re: Learning to code by reading code

On Feb 21, 4:48 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "Dombo" <do...@disposable.invalid> wrote in message

> > > In the past twenty years I have run into maybe 3 or 4
> > > compiler bugs, and about the same number in the libraries that came with
> > > them (on mainstream compilers, the statistics are a lot worse for some
> > > oddball compilers).
>
> > Again, you've confirm my experiences in contrast to NK's claims.
>
> 3 or 4 in 20 years sounds about right to me (a little high). Sounds
> pretty low to me.

say 2 in 20 years taht's 1 every 10 years. So I didn't find them all
myself, people I worked with did. Say the average team size is 5
that's 1 every 50 man years. So a programmer working alone would be
lucky to see one compiler bug in his entire carreer. I call that rare.

<snip>

[toc] | [prev] | [next] | [standalone]

#1013 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:54f1f977-d567-4001-b9b8-fa954b93e7a2@s7g2000vby.googlegroups.com...
> On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "Dombo" <do...@disposable.invalid> wrote in message

<snip>

> > > In the past twenty years I have run into maybe 3 or 4
> > > compiler bugs, and about the same number in the libraries
> > > that came with them (on mainstream compilers, the
> > > statistics are a lot worse for some oddball compilers).
>
> > Again, you've confirm my experiences in contrast to NK's claims.
>
> 3 or 4 in 20 years sounds about right to me (a little high). Sounds
> pretty low to me.

The problem is they are a source of error you haven't located, but should.

> NK claimed bugs in compilers were pretty unusual.
> Sounds like we agree.

Yes, I'd agree that you can agree with yourself and reference yourself in
the third person too ...

> > > Even if you analyze the assembly output, you still don't know
> > > if the code executes as intended.
>
> > Exactly. You won't know the code executes as intended
> > until it is executed,
>
> you can have a pretty good idea.

Since when is "a pretty good idea" equivalent to confirming correctness of
execution?

> And saring at megabytes of assembler
> ain't gonna help you.

Do you stare at megabytes of HLL code too?  That won't help you either ...

> > which was why I asked this of NK:
>
> > RP> How do you confirm correctness of both high-level and
> > RP> low-level code with an imaginary machine? Is your
> > RP> confirmation of correctness imaginary also? ...
>
> oh were you asking if I did unit tests? Yes various validations are
> done ***on the HLL code***. Including inspection, unit test and
> system test. Whats that got to do with asesmbly code?

Is the code executed as part of these tests?  I.e., confirmed, but not
confirmed on an "imaginary machine" ...

(PS.  Are you aware two letters in your various words have their locations
switched?  It's been quite a few times now ... asesmbly vs. assembly
... -ign vs. -ing ... etc)

> > To which, I got more than one absurd response that
> > imaginary confirmation of correctness was entirely valid ...
>
> have you heard of DbC or code inspection?

By DbC, you mean like MISRA C, Safer C, or static code analysis, dynamic
code analysis ... or something else?

Wikipedia's DbC page mentions preconditions.  I'd say that was the over 500
identical cut-n-pasted if() statements to determine if our data was in the
correct location of the 5Mloc program I once worked on ...  No we couldn't
procedurize that if().  That would've been too slow, supposedly.

Wait ... what?!?!  So, you believe in code inspection of the HLL code, but
*not* the emitted assembly?  Well, I just don't know what to say about that
contradiction ...  Are you playing Devil's advocate?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1014 — Re: Learning to code by reading code

On Feb 22, 11:12 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:54f1f977-d567-4001-b9b8-fa954b93e7a2@s7g2000vby.googlegroups.com..
> > On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > > "Dombo" <do...@disposable.invalid> wrote in message

> > > > In the past twenty years I have run into maybe 3 or 4
> > > > compiler bugs, and about the same number in the libraries
> > > > that came with them (on mainstream compilers, the
> > > > statistics are a lot worse for some oddball compilers).
>
> > > Again, you've confirm my experiences in contrast to NK's claims.
>
> > 3 or 4 in 20 years sounds about right to me (a little high). Sounds
> > pretty low to me.
[...]
> > NK claimed bugs in compilers were pretty unusual.
> > Sounds like we agree.
>
> Yes, I'd agree that you can agree with yourself and reference yourself in
> the third person too ...

I claimed compiler bugs were pretty rare. Someone came up with a
number (3 to 4 cases in 20 years). You said "you've confirm my
experiences". I pointed out that 3-4/20 years is a low rate and hence
that compiler bugs /are/ pretty unusual.

So we agree compiler bugs are fairly unusual?

Note I'm fairly careful about what I say. When I say "fairly unusual"
I don't mean "never happens".

<snip>

> > And [staring] at megabytes of assembler ain't gonna help you.
>
> Do you stare at megabytes of HLL code too?  That won't help you either ...

so what's the point of looking at the generated code? If the HLL
verifies then the machine code has been verified as a side effect.

> > > which was why I asked this of NK:
>
> > > RP> How do you confirm correctness of both high-level and
> > > RP> low-level code with an imaginary machine? Is your
> > > RP> confirmation of correctness imaginary also? ...
>
> > oh were you asking if I did unit tests? Yes various validations are
> > done ***on the HLL code***. Including inspection, unit test and
> > system test. Whats that got to do with asesmbly code?
>
> Is the code executed as part of these tests?  I.e., confirmed, but not
> confirmed on an "imaginary machine" ...

yes the code is executed. What do you think a unit test is? And I'll
point out again you misquoted me on "imaginary machines". Stop doing
this.

> (PS.  Are you aware two letters in your various words have their locations
> switched?  It's been quite a few times now ... asesmbly vs. assembly
> ... -ign vs. -ing ... etc)

yes I'm a rubbish typeist

> > > To which, I got more than one absurd response that
> > > imaginary confirmation of correctness was entirely valid ...
>
> > have you heard of DbC or code inspection?
>
> By DbC, you mean like MISRA C, Safer C, or static code analysis, dynamic
> code analysis ... or something else?

Design by Contract

> Wikipedia's DbC page mentions preconditions.

and post-conditions?

>  I'd say that was the over 500
> identical cut-n-pasted if() statements to determine if our data was in the
> correct location of the 5Mloc program I once worked on ...  No we couldn't
> procedurize that if().  That would've been too slow, supposedly.

no idea what this has to do with DbC

> Wait ... what?!?!  So, you believe in code inspection of the HLL code, but
> *not* the emitted assembly?  Well, I just don't know what to say about that
> contradiction ...  Are you playing Devil's advocate?

no. I see no contradiction. Machine code is validated as a side-effect
of HLL validation. I've /never/ seen anyone inspect the assembler
output of a compiler as a matter of course.

[toc] | [prev] | [next] | [standalone]

#1017 — Re: Learning to code by reading code

On Wed, 22 Feb 2012 04:30:54 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>no. I see no contradiction. Machine code is validated as a side-effect
>of HLL validation. I've /never/ seen anyone inspect the assembler
>output of a compiler as a matter of course.

I don't do it very often anymore but I did it a lot in an embedded
system using a Microtec Research C compiler for Z80/Z180. It emitted
some code that thrashed around with the HL and DE registers, swapping
them circularly for about 4 instructions. Email to them with sample
code got me a phone call from the compiler maintainer and the compiler
was fixed that afternoon. Routine? Far from it, but checking the
product of the compiler's translation can sometimes produce insights.

[toc] | [prev] | [next] | [standalone]

#1018 — Re: Learning to code by reading code

On Feb 22, 6:45 pm, Geoff <ge...@invalid.invalid> wrote:
> On Wed, 22 Feb 2012 04:30:54 -0800 (PST), Nick Keighley
> <nick_keighley_nos...@hotmail.com> wrote:

Rod Pemberton wrote:
>> [...] So, you [NK] believe in code inspection of the HLL code, but
>> *not* the emitted assembly?  Well, I just don't know what to say about that
>> contradiction [...]

> >no. I see no contradiction. Machine code is validated as a side-effect
> >of HLL validation. I've /never/ seen anyone inspect the assembler
> >output of a compiler as a matter of course.
>
> I don't do it very often anymore but I did it a lot in an embedded
> system using a Microtec Research C compiler for Z80/Z180. It emitted
> some code that thrashed around with the HL and DE registers, swapping
> them circularly for about 4 instructions. Email to them with sample
> code got me a phone call from the compiler maintainer and the compiler
> was fixed that afternoon. Routine? Far from it, but checking the
> product of the compiler's translation can sometimes produce insights.

it's a matter of balance. I've looked at assmembler in the past and if
i suspected a compiler bug (or had some other good reason) I'd look at
it again. But it certainly isn't an every-day activity for either
myself /or/ for anyone I've worked with in recent years.

I suspect Mr Pemberton is trolling a bit. And I bite.

[toc] | [prev] | [next] | [standalone]

#1021 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...
> On Feb 22, 11:12 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> [...]
> If the HLL verifies then the machine code has been verified as a side
effect.

a) "Verifies" how?
b) No.  That just means that whatever was "verified" didn't trigger or run
into the error.

> > Is the code executed as part of these tests? I.e., confirmed,
> > but not confirmed on an "imaginary machine" ...
>
> yes the code is executed. [...]
>
...

> And I'll point out again you misquoted me on "imaginary
> machines". Stop doing this.

Huh?  What are you talking about misquoted?  In response to me saying one
needs to check the assembly output, you said:

NK> I don't think so. When I come across a novel
NK> language feature I like to think how it would
NK> be implemented. But I use an imaginary machine
NK> (or these days, C!).

For which, I asked this about the "imaginary machine":

RP> How do you confirm correctness of both high-level
RP> and low-level code with an imaginary machine?  Is
RP> your confirmation of correctness imaginary also? ...

From which you progressly migrated into real world testing of code that was
supposedly being tested somehow on an imaginary machine ...  That seems to
be this of the thread.

> > Wikipedia's DbC page mentions preconditions.
>
> and post-conditions?

That too, but I was mentioning, sarcastically, a real-world repeated
identical if() statement as DbC "pre-conditions".  They clearly weren't
coded with the concepts of DbC.  They were there to ensure that "wrong data"
didn't enter the "wrong part" of the program and become corrupted or cause
other hazardous unknowns.

> I'd say that was the over 500 identical cut-n-pasted if()
> [...]
...

> Machine code is validated as a side-effect of HLL validation.

Well, definately not for an imaginary machine ...

And, just because a program currently works correctly with the input sets
you've tried, doesn't mean it will later with a different data set or
different combination of user selections.  We ran into that issue all the
time on the 5MLoc program.  We ran extremely large datasets and tested and
retested every feature to the point of repugnance.  All that means is the
bug hasn't been discovered.  That bug can be in compiler output, or it can
be in the programmer's expectations about what the compiler should be doing,
but isn't, doesn't, or didn't.  Without verifying the emitted assembly does
what you expect the HLL code to do, how do you know it is?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1022 — Re: Learning to code by reading code

On Feb 23, 12:34 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...> On Feb 22, 11:12 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>


> > [...]
> > If the HLL verifies then the machine code has been verified as a side
> > effect.
>
> a) "Verifies" how?

um... "verify" n. to confirm the correctness of.

If the HLL is correct the machine code is correct (barring unobserved
side effects). Do these happen a lot?

> b) No.  That just means that whatever was "verified" didn't trigger or run
> into the error.

doesn't this apply to both HLL and machine code?

> > > Is the code executed as part of these tests? I.e., confirmed,
> > > but not confirmed on an "imaginary machine" ...
>
> > yes the code is executed. [...]
>
> > And I'll point out again you misquoted me on "imaginary
> > machines". Stop doing this.
>
> Huh?  What are you talking about misquoted?  In response to me saying one
> needs to check the assembly output, you said:
>
> NK> I don't think so. When I come across a novel
> NK> language feature I like to think how it would
> NK> be implemented. But I use an imaginary machine
> NK> (or these days, C!).

this is as an aid to understanding a novel language feature. I imagine
how it might be implemented. This isn't part of a verification
strategy.

> For which, I asked this about the "imaginary machine":
>
> RP> How do you confirm correctness of both high-level
> RP> and low-level code with an imaginary machine?

I don't. Like I said, it is used as an aid to understanding. Mental
scaffolding.

> Is
> RP> your confirmation of correctness imaginary also? ...
>
> From which you progressly migrated into real world testing of code that was
> supposedly being tested somehow on an imaginary machine ...  That seems to
> be this of the thread.

I never said I tested on an imaginary machine. Though I have done host
testing as part of the verification of a program destined to run on a
different target.

<snip>

> > Machine code is validated as a side-effect of HLL validation.
>
> Well, definately not for an imaginary machine ...
>
> And, just because a program currently works correctly with the input sets
> you've tried, doesn't mean it will later with a different data set or
> different combination of user selections.

this applies to all forms of testing. Hence walkthrus, inspection, DbC
etc.
Unit Test is supposed to be a little more resistant to this affect as
there is a systematic attempt to check all boundary conditions etc.

The onlt "fool proof" alternative is formal methods.

> We ran into that issue all the
> time on the 5MLoc program.  We ran extremely large datasets and tested and
> retested every feature to the point of repugnance.  All that means is the
> bug hasn't been discovered.  That bug can be in compiler output, or it can
> be in the programmer's expectations about what the compiler should be doing,
> but isn't, doesn't, or didn't.  Without verifying the emitted assembly does
> what you expect the HLL code to do, how do you know it is?

what makes you think verifying machine code is any easier than
verifying HLL code? How do I validate a mega-byte of HLL by looking at
the machine code?

[toc] | [prev] | [next] | [standalone]

#1023 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...

>what makes you think verifying machine code is any easier than
>verifying HLL code? How do I validate a mega-byte of HLL by looking at
>the machine code?
i risk one answer
because my asm scale better than your hll
and it is easy to read?
depend how much difficult add the semantic of hlls languages
and how the algo are clear in the paper or in the mind of
who read

one thing i'm pretty sure it is all has to be read as
little instruction as a^=b or jump label

[toc] | [prev] | [next] | [standalone]

#1024 — Re: Learning to code by reading code

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:4f473d62$0$1386$4fafbaef@reader2.news.tin.it...
> one thing i'm pretty sure it is all has to be read as
> little instruction as a^=b or jump label

one thing i'm pretty sure is there would be a way to see until
little easy instruction as a^=b or jump label

[toc] | [prev] | [next] | [standalone]

#1025 — Re: Learning to code by reading code

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4f473d62$0$1386$4fafbaef@reader2.news.tin.it...
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
> news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...
>
>>what makes you think verifying machine code is any easier than
>>verifying HLL code? How do I validate a mega-byte of HLL by looking at
>>the machine code?
> i risk one answer
> because my asm scale better than your hll
> and it is easy to read?

for example the unsigned type

unsigned  a, b, c;
than i make operations on a, b, c,
and so program a *set of machine* [machine == CPU]
follow the C standard...

if a, b, c has a size as 32 bit
uint32_t  a, b, c;
and operation on them are well definited
and program ONE machine [the sub cpu of 32 bit]

in other words: if program is difficult for just *one* machine
what make to think it is not exponential difficult to
a set of machines?

the same of above can be done for pointer when someone see
pointers as numbers: all is easier
and somethime easier means can be done

> depend how much difficult add the semantic of hlls languages
> and how the algo are clear in the paper or in the mind of
> who read
>
> one thing i'm pretty sure it is all has to be read as
> little instruction as a^=b or jump label

one thing i'm pretty sure it is there would be
one way to see all HLL code traslation until
little easy instruction as a^=b or jump label
or  a|=b

[toc] | [prev] | [next] | [standalone]

#1027 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...
> On Feb 23, 12:34 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> >
news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...>
...

> If the HLL is correct the machine code is correct [...]

This assumes the HLL code and machine code are 100% identical.  That assumes
the compiler is 100% perfect in it's translation.  That also assumes the
libraries are 100% perfect in their implementation.  The HLL code can be
100% correct syntactically and the generated machine code can be wrong.

> > [...] whatever was "verified" didn't trigger or run
> > into the error.
>
> doesn't this apply to both HLL and machine code?

If you can interpret the HLL code and you can compile it to machine code
too, then yes.  Otherwise, no, it only applies to the machine code since the
HLL can't be fully "verified" except by compiling it to machine code.

> > > Machine code is validated as a side-effect of HLL validation.
>
> > [...]
> > And, just because a program currently works correctly with
> > the input sets you've tried, doesn't mean it will later with a
> > different data set or different combination of user selections.
>
> this applies to all forms of testing. [...]

If you don't take issues here, why do you do so above?!

> what makes you think verifying machine code is any easier
> than verifying HLL code?

I didn't say it is.

> How do I validate a mega-byte of HLL by looking at
> the machine code?

By compiling and studying the output for all the language elements, type
conversions, etc you use to understand if your compiler is emitting them
correctly, or that your understanding of what the HLL code does is correct
in terms of the assembly.  You don't have study the entire output of a large
program.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.misc

csiph-web