2 Jun
2007
2 Jun
'07
2:16 p.m.
From: "Dave Dunfield" <dave06a at
dunfield.com>
weird.
This simple code snippet invokes "undefined behaviour" because:
'N' is modified twice within a single sequence block.
'N' is referenced within a sequence block separately from a modification
occuring within the same sequence block.
One might expect:
N = 1
Save address of A[1]
++N
(address of A[1]) = 2
++N
Which gives you the result you expected, however a compiler is free to
perform the side effects occuring within a sequence block at any time it
wishes, as long as it observes the charactistics of the operator causing
the side effect. (ie: one instance of N++ cannot increment N before
retrieving it's value, although the other instance of N++ could have
incremented it).
Hi Dave
I'd expect it to evaluate the left side of the equation first before
determining the address. A[2]=1. Any other order would not make
sense. Algebraic equations do not read left to right. This causes
a sense of ambiguity but shouldn't. Where it wouldn't be clear
as to the result would be for the case:
A = (5*N++) + (6*N++)
But that only goes to show how poor this type of notation is for
defining sequence of execution. This is why I still think RPN notation
is much better for computer programming. This need not be a stack
language like Forth. It is concise. Events happen left to right. No special
rules. It isn't familar to what you learned in grade school but doesn't
take long to grasp.
Dwight
_________________________________________________________________
PC Magazine?s 2007 editors? choice for best Web mail?award-winning Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_mig…
N = 1;
A[N++] = N++;
I'd expect that to evaluate to a[1]=2 and n winds up being 3. But I'm
2 Jun
2 Jun
5:33 p.m.
On Sat, 2 Jun 2007, dwight elvey wrote:
Hi Dave
I'd expect it to evaluate the left side of the equation first before
determining the address. A[2]=1. Any other order would not make
sense.
It would to some compiler authors. (who sometimes have a different
reality than you and I do)
But that only goes to show how poor this type of
notation is for
defining sequence of execution. This is why I still think RPN notation
is much better for computer programming. This need not be a stack
language like Forth. It is concise. Events happen left to right. No special
rules. It isn't familar to what you learned in grade school but doesn't
take long to grasp.
Any completely defined language should produce the same results no matter
what is fed to the compilers. But, what about Y = X/0 ? In a simple
microcomputer implementation, howzbout
N = 32767; /*or 2147483647 (as used in MS-DOS file and partition size)*/
N = N + 1; ?
K&R was NOT a very rigid complete definition of the language. There were
many parts subject to choice or interpretation by the compiler author.
If you want to shoot yourself in the foot, C will provide you unlimited
large caliber ammunition.
Going back to the original post, . . .
in addition to real problems with compilers (such as mishandling of
scope), programmers will tend to claim bugs in the compiler whenever they
encounter different results than from their "baby duck" compiler.
Mine was FORTRAN, followed by APL, 1401 machine, 1401 SPS, BASIC, . . .
(and a real programmer can write a FORTRAN program in any language)
Without meaning to offend you, I'm going to guess that you started with
FORTH and then branched out. There does seem to be less potential for
ambiguity in a RPN language that has one operation per instruction.
(which is what makes machine language so fulfilling)
--
Grumpy Ol' Fred cisin at xenosoft.com
5:57 p.m.
Always a good for a little headscratching to keep the gray matter
twitching:
http://www.gimpel.com/html/bugs.htm
Cheers,
Chuck
7:09 p.m.
At 04:57 PM 6/2/2007, you wrote:
Always a good for a little headscratching to keep the
gray matter
twitching:
http://www.gimpel.com/html/bugs.htm
Still around! "PC-lint for C/C++ the longest continuously advertised
software tool in human history, was first introduced in 1985."
I remember buying it and C-terp in 1985...
- John
7:58 p.m.
On Sat, 2 Jun 2007, dwight elvey wrote:
> Hi Dave
Sorry - I haven't actually been following this thread ... I just happened
across the first message I responded to... and again on this one.
> I'd expect it to evaluate the left side of
the equation first before
> determining the address. A[2]=1. Any other order would not make
> sense.
Oh no - it is quite common for a compiler to evaluate the address first,
which gets stored in a holding register while the rest is evaluated ...
but this discussion is meaningless because the issue here is the occurance
of side effects. The application of side effects to multiply referenced
items within a single sequence block is not specified by the standard.
The side effect can happen as soon as the compiler emits code for the
operator in question, or it can be deferred to some later point in the
code emitted during that sequence block (and often is in the name of
optimization).
Theres also a wonderful "as if" clause which says that a compiler can
violate the standard as long as the results behave "as if" it had not
done so - An example of this might be a compiler deferring operation
from one sequence block into the next if it has
determined that doing
so will not affect the results. Since undefined operation is
by definition
undefined, the "as if" clause always applies - hence the compiler can emit
ode invoking undefined operation at the very end of our program if it
wanted (or not at all) - (one would hope that a diagnostic would also
be emitted :-) ...
It would to some compiler authors. (who sometimes
have a different
reality than you and I do)
:-)
(I'm a compiler writer)
> But that only goes to show how poor this type of
notation is for
> defining sequence of execution. This is why I still think RPN notation
> is much better for computer programming. This need not be a stack
> language like Forth. It is concise. Events happen left to right. No special
> rules. It isn't familar to what you learned in grade school but doesn't
> take long to grasp.
A long debated viewpoint - but I think a better solution would be to
emit diagnostics when such conditions are found - the problem is, although
it's simple to detect with simple variables, the use of pointers or
function calls with side-effects can make it impossible to detect such
situations. In this respect, C is like assembly - You have to know what
you are doing and avoid these traps. Perhaps the real solution is one
of education.
Any completely defined language should produce the
same results no matter
what is fed to the compilers. But, what about Y = X/0 ? In a simple
microcomputer implementation, howzbout
N = 32767; /*or 2147483647 (as used in MS-DOS file and partition size)*/
N = N + 1; ?
K&R was NOT a very rigid complete definition of the language. There were
many parts subject to choice or interpretation by the compiler author.
If you want to shoot yourself in the foot, C will provide you unlimited
large caliber ammunition.
Absolutely - even standardized C allows for may implementation dependant
aspects. This is a necessary evil due to the nature of a very widely
accomodating portable language.
Going back to the original post, . . .
in addition to real problems with compilers (such as mishandling of
scope), programmers will tend to claim bugs in the compiler whenever they
encounter different results than from their "baby duck" compiler.
Mine was FORTRAN, followed by APL, 1401 machine, 1401 SPS, BASIC, . . .
(and a real programmer can write a FORTRAN program in any language)
Without meaning to offend you, I'm going to guess that you started with
FORTH and then branched out. There does seem to be less potential for
ambiguity in a RPN language that has one operation per instruction.
(which is what makes machine language so fulfilling)
Any language of significant power allows you to hang yourself. The trick
is knowing how to handle the rope - my early computing history involved
more assembly language than anything else, and thinking from that
perspective, I have no problems understanding and avoiding these details.
It also helps that I know very precisely what code my compiler will generate
for various constructs. - and yeah, at times in "quick and dirties" I've
coded stuff invoking undefined behaviour knowing what to expect from my
own toolset (ducking).
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
8:14 p.m.
New subject: Aztec C
Dave Dunfield wrote:
Good I need a Free Compiler ... OH wait you may want $$$.
I like the left to right idea A + B -> C
It would to
some compiler authors. (who sometimes have a different
reality than you and I do)
:-)
(I'm a compiler writer) A long debated viewpoint - but I think a better
solution would be to
emit diagnostics when such conditions are found - the problem is, although
it's simple to detect with simple variables, the use of pointers or
function calls with side-effects can make it impossible to detect such
situations. In this respect, C is like assembly - You have to know what
you are doing and avoid these traps. Perhaps the real solution is one
of education.
But at least with the older C you could find your FEET to shoot.
For humor check here.
http://www.uwsg.iu.edu/usail/library/humor/shoot.foot.html
Absolutely - even standardized C allows for may
implementation dependant
aspects. This is a necessary evil due to the nature of a very widely
accomodating portable language.
Portable only if you assume BYTES are 8 bits (unsigned) now days.
Any language of significant power allows you to hang
yourself. The trick
is knowing how to handle the rope - my early computing history involved
more assembly language than anything else, and thinking from that
perspective, I have no problems understanding and avoiding these details.
It also helps that I know very precisely what code my compiler will generate
for various constructs. - and yeah, at times in "quick and dirties" I've
coded stuff invoking undefined behaviour knowing what to expect from my
own toolset (ducking).
So is the languages the problem or the hardware for clean coding?
And just what is reasonable memory size anyhow ...
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
.
9:45 p.m.
New subject: Aztec C
It would to some compiler authors. (who sometimes
have a different
reality than you and I do)
:-)
(I'm a compiler writer) I like the left to right idea A + B -> C
To each his own - I'm very fond of APL which works that way except
that it runs right to left.
I always wanted to implement the "comes from" operator in one of my
tools but never did...
A long debated
viewpoint - but I think a better solution would be to
emit diagnostics when such conditions are found - the problem is, although
it's simple to detect with simple variables, the use of pointers or
function calls with side-effects can make it impossible to detect such
situations. In this respect, C is like assembly - You have to know what
you are doing and avoid these traps. Perhaps the real solution is one
of education.
But at least with the older C you could find your FEET to shoot.
For humor check here.
http://www.uwsg.iu.edu/usail/library/humor/shoot.foot.html Absolutely -
even standardized C allows for may implementation dependant
aspects. This is a necessary evil due to the nature of a very widely
accomodating portable language.
Portable only if you assume BYTES are 8 bits (unsigned) now days. Any language
of significant power allows you to hang yourself. The trick
is knowing how to handle the rope - my early computing history involved
more assembly language than anything else, and thinking from that
perspective, I have no problems understanding and avoiding these details.
It also helps that I know very precisely what code my compiler will generate
for various constructs. - and yeah, at times in "quick and dirties" I've
coded stuff invoking undefined behaviour knowing what to expect from my
own toolset (ducking).
So is the languages the problem or the hardware for clean coding? And just what is reasonable memory size anyhow ...
How much fuel will you need for the trip?
(Kinda hard to answer without parameters isn't it).
An AVR1200 with 1K of program storage and NO RAM (only
the CPU registers as temp store) is excessive for some
tasks - an ARM9 with 1024MEG is limited for others (although
I personally can't think of many). I do a lot of my DOS code
in 64K "tiny" memory model (ImageDisk for example).
But we do digress from Vintage Computing...
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
9:21 p.m.
New subject: Aztec C
On Sat, 2 Jun 2007, Dave Dunfield wrote:
I like the arrow for assignment, instead of '=' (equality?). saves a lot
of time with beginning programmers from math backgrounds, for whom
N = 1
N = N + 1
would be an inductive proof that all numbers are equal, bringing about the
end of the universe as we know it.
but not very far.
Who could possibly need more than 640K? or even 64K?
Well, you could want lots of memory for data (think video),
but properly written code shouldn't be so bulky.
--
Grumpy Ol' Fred cisin at xenosoft.com
I like the
left to right idea A + B -> C
To each his own - I'm very fond of APL which works that way except
that it runs right to left. Many attempts have been made over the years to develop
languages which
force the programmer to be "good".
aka "padded rooms"
But programming is an art, and an art
cannot be synthisized. These efforts simply force unnecessary constraints
on the real artists, and provide another forum for the bad ones to prove
that they produce a mediocre work.
. . . and a system that won't let you do the wrong thing places excessive
limits on what right things you can do (such as disk I/O below the file
level)
And just what
is reasonable memory size anyhow ...
But we do digress from Vintage Computing...
3 Jun
3 Jun
2:19 p.m.
New subject: Aztec C
Fred Cisin wrote:
I always think that the key is a language which allows programmers to do
"everything" (for suitable values of everything, of course), but only allows
them to do any one thing one way only. One of the things which irritates about
C is that there's always a million different ways of expressing the most
simple of things; I like the language's power, but understanding someone
else's obfuscation can be a little annoying at times.
Incidentally I stumbled across brainf*ck as a language the other day. 8
instructions. Beautiful :-) (http://www.muppetlabs.com/~breadbox/bf)
But
programming is an art, and an art
cannot be synthisized. These efforts simply force unnecessary constraints
on the real artists, and provide another forum for the bad ones to prove
that they produce a mediocre work.
. . . and a system that won't let you do the wrong thing places excessive
limits on what right things you can do (such as disk I/O below the file
level) 
1:33 a.m.
New subject: Aztec C
Absolutely -
even standardized C allows for may implementation
dependant aspects. This is a necessary evil due to the nature of a
very widely accomodating portable language.
Portable only if you assume BYTES are
8 bits (unsigned) now days. So is the languages the problem or the hardware for
clean coding?
No, not really (though in some cases either can exacerbate problems).
The actual problem is people coding who don't really grok programming,
at best understanding "programming in COBOL for VM/CMS" or "programming
in gcc for Linux on i386" or whatever - and usually not even that.
And just what is reasonable memory size anyhow ...
...for what? :-)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1:50 a.m.
New subject: Aztec C
der Mouse wrote:
That's a concept which is lost on far too many people nowadays.
I got the job I'm currently in after an exchange that went something like:
"I see on your r?sum? that you can code in quite a few languages."
"I mostly list languages on there so I get picked up by the
keyword-searchers. The main thing is that I fundamentally understand
how to program a computer."
"When can you start?"
8-)
Peace... Sridhar
So is the
languages the problem or the hardware for clean coding?
No, not really (though in some cases either can exacerbate problems).
The actual problem is people coding who don't really grok programming,
at best understanding "programming in COBOL for VM/CMS" or "programming
in gcc for Linux on i386" or whatever - and usually not even that.
8:13 a.m.
New subject: Aztec C
Portable only
if you assume BYTES are 8 bits (unsigned) now days.
This is just a modern form of "all the world's a VAX". It's
approximately as necessary for "portable" code now as assuming you're
on a VAX was for "portable" code then - and for approximately the same
value of "portable" (not one I think really deserves the name, but
that's a different issue).
6254
days inactive
6255
days old
11 comments
9 participants
participants (9)
-
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
dave06a＠dunfield.com -
dkelvey＠hotmail.com -
jfoust＠threedee.com -
julesrichardsonuk＠yahoo.co.uk -
mouse＠Rodents.Montreal.QC.CA -
ploopster＠gmail.com