Warning to newbies

[Michael Foukarakis]

On 02/02/2010 11:15,spinoza1111wrote:
[snip]
A sensible "C standard" would have in fact defined a new C free of
these problems:
...
reaching the end of a non-void function without finding a return
statement, when the return value is used
But "reaching the end of a non-void function" and falling off the end
of the world is flat-earth thinking, the unnecessary preservation of
the mistakes of the past and the limitations of old machines. You
should have FORCED vendors to hire compiler developers to FIX this
problem by simply adding a machine language return statement behind
ALL such functions as a guard, or behind functions where the return is
missing. This isn't rocket science.
You've missed the point here, Baldrick. It's not that the function won't
return, but that because execution reaches the end of the function
without encountering a "return x" statement, the value that the function
returns is undefined. This is obviously a problem if the caller expects
to use the returned value.
And "undefined" simply means that the value seen by the caller will be
implementation-defined and therefore could be anything. I add this as
you don't appear to understand this simple point.

To say it's "implementation defined" and to claim this is a standard
is bullshit. If it's "implementation defined" then it's not a
standard.

Well done for sidestepping the major flaw that I pointed out, and
focussing on the second point.

"International standard for dildoes"! "Anything you like including
exploding ones!"

That is: standardization is for the safety and convenience of the
consumer/user, not for compiler vendors. Underwriter's Laboratories
certifies electrical products as safe, it does NOT say that "the
result is undefined", ...

Safe when used as directed. UL will doubtless specify the voltage range,
temperature range, humidity, and so on. To go outside these limits is
potentially *unsafe* and what actually happens is undefined. Get the
point now?

Even on the off-chance a troll does, it won't admit it.

 

[Chris M. Thomasson]

I remember that exchange. I wasn't as good a poet back then, but we
did successfully work together. This is what this newsgroup is for.
Unfortunately, such outcomes are rare. And that discussion was spammed
by the regs, who were enraged that Chris and I were actually working
together and solving a problem.

The problem was one of computer science, but Kiki, filled with
resentment if not hate, kept whining that it was off topic because C
Sharp could handle the problem with ease.

Yes, C# can indeed handle the problem. However, it's not exactly all that
"efficient" because it needs to do a full blown copy-on-write and use
garbage collection to ensure that everything works as expected. In other
words, I cannot operate on data-structures directly like I can using
assembly language. FWIW, this is exactly how Sun implemented
`AtomicStampedReference'.


C# and Java basically have to do something like the following pseudo-code:
___________________________________________________________________
bool CASX(value current,
value comparand,
value exchange)
{
value new_exchange = new value(exchange); // copy

for (;
{
value ref_current = current;

if (! COMPARE(ref_current, comparand)) return false;

if (CAS(current, ref_current, new_exchange)) return true;
}
}
___________________________________________________________________




This logic will most definitely work, but unfortunately a high amount of
"pressure" will be bearing down on the memory allocator and garbage
collector if I frequently execute it. This is why I was so disappointed to
find out that Sun implemented `AtomicStampedReference' this way.


I cannot think of any other technique to implement DWCAS in 100% pure C#
without resorting to COW. I thought of a possible optimization which
involved reusing allocated data-structures, but sadly this won't work due to
a fairly nasty race-condition called the ABA problem:


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


Well, I can solve all of this by resorting to using unsafe code in C#. But
that would make the C# code highly non-portable because I would have to
create an assembly language implementation of DWCAS for every architecture I
want to port to. I expect this for a language like C, but NOT for C#!!!


;^(...


[...]

 

[Nick Keighley]

This stuff makes me wonder sometimes if he's a Poe.

ok you got me.

Perl Object Environment, Power Over Ethernet or Problem of Evil?

It can't be Post Once Exactly, Product of Experts or Purity of
Essence.

And I like Propagation of Error and Greek Cycling Federation (it makes
more sense in greek presumably) as outliers.

 

[Michael Foukarakis]

ok you got me.

Perl Object Environment, Power Over Ethernet or Problem of Evil?

It can't be Post Once Exactly, Product of Experts or Purity of
Essence.

And I like Propagation of Error and Greek Cycling Federation (it makes
more sense in greek presumably) as outliers.

World Trade Organization makes more sense in greek actually. Contains
significantly more irony as well.

 

[santosh]

ok you got me.

Perl Object Environment, Power Over Ethernet or Problem of Evil?

It can't be Post Once Exactly, Product of Experts or Purity of
Essence.

And I like Propagation of Error and Greek Cycling Federation (it makes
more sense in greek presumably) as outliers.

I'm guessing that it's to do with Edgar Allen Poe.

 

[Michael Foukarakis]

I'm guessing that it's to do with Edgar Allen Poe.

Preposterous!

 

[santosh]

I'm guessing you're wrong. But my own guess as to what he means is
unprintable, so I won't print it.

Whoops! I admit I never thought of *that* angle. Best to drop this sub-
thread now

 

[Richard Tobin]

[...]
I'm guessing that it's to do with Edgar Allen Poe.[/QUOTE]

http://rationalwiki.com/wiki/Poe's_Law

-- Richard

 

[spinoza1111]

If anyone was in any doubt about you, this should clear it up.
I quote you here so that you cannot remove your disgusting
statements from the public record.

What's disgusting is what happens to people who take the risk of
posting interesting and creative material about C and related matters,
only to find themselves the target of abuse.

This character Harlan, in particular, has contributed nothing to this
discussion except abuse in which he takes his cue from the mob. He
seeks to expose others and to ascribe to them the weakness, impotence
and fear he feels in a ridiculous zero-sum exchange in which that
gives him masturbatory relief. Frankly, he deserves what he gets.

 

[Nick Keighley]

and incidently if you are ever near the London Science Museum then go
and vist Babbage's Engine. It's really cool.

A second machine was on display at the Computer History Museum at
Mountain View California. But that machine was privately owned so may
no longer be on display.

 

[Nick Keighley]

This stuff makes me wonder sometimes if he's a Poe.

[...]
I'm guessing that it's to do with Edgar Allen Poe.

http://rationalwiki.com/wiki/Poe's_Law

'ta

 

[Chris M. Thomasson]

news:20199eab-fa3a-435f-ab06-c3789b12d59b@x10g2000prk.googlegroups.com... [...]

This logic will most definitely work, but unfortunately a high amount of
"pressure" will be bearing down on the memory allocator and garbage
collector if I frequently execute it. This is why I was so disappointed to
find out that Sun implemented `AtomicStampedReference' this way.


I cannot think of any other technique to implement DWCAS in 100% pure C#
without resorting to COW. I thought of a possible optimization which
involved reusing allocated data-structures, but sadly this won't work due
to a fairly nasty race-condition called the ABA problem:

WOW! I must be a STUPID ASS RETARD or something!!


A fairly nice portable solution was staring me right in the damn face
Spinoza. I can simply implement one of my new inventions, a wait-free
word-based proxy garbage collector algorithm, in C#:


http://groups.google.com/group/comp.programming.threads/browse_frm/thread/a53f24de178b419f


This would completely solve ABA, and take a shi%load of pressure off the C#
garbage collector. This would even be useful in Java and it would
definitely, beyond a reasonable doubt, beat the living crap out of a
solution based on Sun's implementation of the `AtomicStampedReference'. The
solution would be in 100% pure C#, and therefore retain all of the benefits
of managed code. The funny/odd thing is that I am using a "garbage
collector" to help out a garbage collector; very interesting...


Now, I still will not be able to "instantly" reuse objects, however, the
fact that I can take a lot of pressure off the GC is very attractive.


;^)


[...]

 

[spinoza1111]

is there a programming language standard that /doesn't/ do this?

Now that is a good question.

I'd say that there's a distinction between a language standard that
allows implementations to make decisions while preserving semantics,
and a language standard that allows this while breaking semantics and
making it impossible to predict what source code will do.

 

[spinoza1111]

It's hard to see how there could be, for a language of any real power.

I think it is a fundamental error to imagine that there's any
necessary connection between "being able to do strange things" and
"computational power", and I say this as one who started out hacking
machine and assembly language, writing exceedingly tight and self-
altering code to squeeze every drop of performance out of an 8K
machine. Good algorithms, not hacking and rules violation, are the
source of computational power.

The only way to define a language completely is to nail it down
completely: everything is either required or forbidden.

We already know that a Turing machine cannot determine in general
whether another Turing machine will halt, or, more generally, be able
to predict what another Turing machine will do. But it is an urban
legend that C is more sophisticated because one can do exceedingly
stupid things in it.

What's the point of preserving a "feature" such as "a missing return
statement will cause an undefined situation in the caller"? It's duck
soup to require a would-be standard compiler to return the zero value
for the function type. This would cause fewer crashes, although it
wouldn't eliminate crashes. Far more importantly, it would avoid the
situation of code that seems to work but doesn't actually work.

Read "Fly by Wire: The Geese, the Glide, and the Miracle on the
Hudson", by William Langewiesche. It describes the no-fatality
ditching of an Airbus A320 in the Hudson last year. Langewiesche,
while crediting Captain Chesley Sullenberger's flying skills, also
emphasizes that the A320 was designed not to exceed in any way its
performance range: it was an "intelligent" "fly by wire" plane, and
its avionics made the difference between a rough landing that would
have caused fatalities and drownings, and the actual landing which was
as smooth as possible and caused an orderly evacuation.

It appears to me that C programmers are like pilots who hate the A3xxx
series because airplanes which don't let the pilot override control
systems are just boring and makes them feel like glorified bus
drivers. However, this is what people want when they fly. They don't
want Smilin' Jack bringing it in on guts alone.

The problem being that the software in these planes (and in
automobiles such as the Toyota) can't be written in a language like C
which does allow the programmer to code outside of sensible boundaries
for shits, giggles and "efficiency". Programmers need to be LESS
skilled and consider themselves clerks, and they need, in my view, to
be forced, especially in mission-critical systems, to be glorified
clerks, by requiring that they code in Java or C#, not C.

Which means like pilots, programmers will have to suck it up: boredom
and lower pay.

The Toyota "sticky accelerator" problem MAY have been caused by
software, and like the A3xx series, which is described by Langewiesche
as "fly by wire", the accelerator is "drive by wire". Floor mat
problems and mechanical stickiness don't seem to explain everything.

Now, the typical break room programmer conclusion here, which is that
"fly by wire, drive by wire, and Java all suck because there might be
a problem in the avionics, the car system, or the virtual machine" is
just wrong, because going back to mechanical avionics, carburetors and
C just adds the old problems back to a system which also contains the
new solutions, resulting in a mess.

 

[spinoza1111]

Well, I am not exactly sure how good the windmill would be at actually
programming the machine.

[...]

Ah, but that's not really the point...

The point is that the machine can execute a program without using any
electricity (e.g., a windmill).

James, check out the Antikythera Mechanism.

Okay, thanks for taking the time to set me straight Nick!

You are a great poster. You use people's names to remind yourself that
they are human beings, unlike the regs here. In the ten years I've
known Richard Heathfield, he's NEVER started or ended a sentence with
my name: he's probably homophobic and feels that might be "gay". But
in my experience in business, in writing emails, and in writing
proposals, that is how to get positive results.

Peter Seebach did introduce himself by saying "hi, I'm Peter Seebach"
to me, but interestingly he did not use my name and since then has
confined himself to referring to me as a "moron" and "insane" to third
party regs to whom he's sucking up; it's obvious to reasonably
literate and reasonably sane people from my sentence structure alone
that I'm neither a moron, nor insane. He has also refused to even read
emails in which I propose an offline (less bandwidth and time wasting
for others) discussion.

Note to self: Don't post after a sleepless night!

Keep up the great posts.

 

[spinoza1111]

On 02/02/2010 11:15,spinoza1111wrote:
[snip]
A sensible "C standard" would have in fact defined a new C free of
these problems:
...
reaching the end of a non-void function without finding a return
statement, when the return value is used
But "reaching the end of a non-void function" and falling off the end
of the world is flat-earth thinking, the unnecessary preservation of
the mistakes of the past and the limitations of old machines. You
should have FORCED vendors to hire compiler developers to FIX this
problem by simply adding a machine language return statement behind
ALL such functions as a guard, or behind functions where the return is
missing. This isn't rocket science.
You've missed the point here, Baldrick. It's not that the function won't
return, but that because execution reaches the end of the function
without encountering a "return x" statement, the value that the function
returns is undefined. This is obviously a problem if the caller expects
to use the returned value.
And "undefined" simply means that the value seen by the caller will be
implementation-defined and therefore could be anything. I add this as
you don't appear to understand this simple point.

To say it's "implementation defined" and to claim this is a standard
is bullshit. If it's "implementation defined" then it's not a
standard.

Well done for sidestepping the major flaw that I pointed out, and
focussing on the second point.

"International standard for dildoes"! "Anything you like including
exploding ones!"

That is: standardization is for the safety and convenience of the
consumer/user, not for compiler vendors. Underwriter's Laboratories
certifies electrical products as safe, it does NOT say that "the
result is undefined", ...

Safe when used as directed. UL will doubtless specify the voltage range,
temperature range, humidity, and so on. To go outside these limits is
potentially *unsafe* and what actually happens is undefined. Get the
point now?

No. Again, you need to read "Fly by Wire: The Geese, the Glide and the
Miracle on the Hudson" by William Langewiesche. The A320 Airbus does
not in normal operation allow the pilot to place the airplane outside
of parameters for which the airplane is known to fly safely.

Flying a jet with paying passengers (and even a Federal Express cargo
flight, according to a Federal pilot I've spoken to) is today like
programming in a safe form of Cobol (Cobol wasn't safe in modern
terms, although it was safer than Fortran and PL/I). This is in my
view as it should be.

Sure, you can take a laptop in the bathtub and kill your ass. And
Langewiesche describes a test/demo pilot who survived an A320 crash in
an airshow that killed children and persists in blaming the A320 who
did manage to overcome fly-by-wire (in a manner not permitted in
regular flight). Also, there is the mystery of an Air France A330
which crashed in June of last year to be resolved: Langewiesche, a
believer in fly by wire, has the honesty to concede that this MAY have
been a failure of fly by wire.

[Langewiesche has a lot of integrity and tells the truth at all costs:
he was almost beat up by NYC firemen when he reported that some of
them looted shops on 9-11.]

BUT: whilst underwriter's labs cannot prevent someone from sticking a
knife into a toaster that's plugged in an on, they can assure six-
sigma safety.

The programmer break room argument is that because safety is six sigma
(or in the case of Java or C Sharp, just much higher than C), and
because six sigma is close to but not equal to 100% safety there's no
reason to change.

This is macho bullshit, the purpose being avoiding a deskilling and
deprofessionalism which is inevitable. You see, IF fly by wire was the
cause of the Air France crash of 2009, or if drive by wire caused the
accelerator pedal jam on the Toyota, this could well mean that the
avionics or car software was written in C, and one of C's numerous
issues caused the problems.

 

[spinoza1111]

[...]

I remember that exchange. I wasn't as good a poet back then, but we
did successfully work together. This is what this newsgroup is for.
Unfortunately, such outcomes are rare. And that discussion was spammed
by the regs, who were enraged that Chris and I were actually working
together and solving a problem.
The problem was one of computer science, but Kiki, filled with
resentment if not hate, kept whining that it was off topic because C
Sharp could handle the problem with ease.

Yes, C# can indeed handle the problem. However, it's not exactly all that
"efficient" because it needs to do a full blown copy-on-write and use
garbage collection to ensure that everything works as expected. In other
words, I cannot operate on data-structures directly like I can using
assembly language. FWIW, this is exactly how Sun implemented
`AtomicStampedReference'.

C# and Java basically have to do something like the following pseudo-code:
___________________________________________________________________
bool CASX(value current,
          value comparand,
          value exchange)
{
    value new_exchange = new value(exchange); // copy

    for (;
    {
        value ref_current = current;

        if (! COMPARE(ref_current, comparand)) return false;

        if (CAS(current, ref_current, new_exchange)) return true;
    }}

___________________________________________________________________

This logic will most definitely work, but unfortunately a high amount of
"pressure" will be bearing down on the memory allocator and garbage
collector if I frequently execute it. This is why I was so disappointed to
find out that Sun implemented `AtomicStampedReference' this way.

I cannot think of any other technique to implement DWCAS in 100% pure C#
without resorting to COW. I thought of a possible optimization which
involved reusing allocated data-structures, but sadly this won't work due to
a fairly nasty race-condition called the ABA problem:

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

Well, I can solve all of this by resorting to using unsafe code in C#. But
that would make the C# code highly non-portable because I would have to
create an assembly language implementation of DWCAS for every architecture I
want to port to. I expect this for a language like C, but NOT for C#!!!

;^(...

[...]

Can't you just let Moore's Law handle "efficiency"?

Sure, not everything can be interpreted since this would multiply all
times by a constant or even a variable number of times because when
things are interpreted, something happens for each instruction. But as
I have shown, C sharp is compiled at the last minute and not
interpreted.

In my view, garbage collection is such a great thing that we shouldn't
be sad that it happens.

However, I have NEVER programmed OSen or embedded systems for real
money, although I've written a number of compilers. I understand that
absolute performance goals may apply. I do object to treating
performance speed as an unalloyed good when the customer doesn't ask
for it.

 

[spinoza1111]

I'm guessing that it's to do with Edgar Allen Poe.

....and note that the break room kiddies start babbling senselessly
when a real discussion with real conclusions (James', and Chris')
starts, because they're bored. And yet I'm the troll? What ev er.

 

[spinoza1111]

In <[email protected]>,

spinoza1111wrote:



No, it's reality. The C Standard leaves quite a number of decisions up
to the implementation. For exasmple, the values of the members of the
execution character set are implementation-defined. This fact, which
turns out not to matter to well-written code, reflects the reality
that there isn't a single universally-agreed best choice. The ISO C
Committee needs to ensure, and does ensure, that they don't
over-legislate and, in so doing, render C unimplementable on some

Great. Like we need a language that's "write once, bomb everywhere"?

You see, my dear boy, to NOT legislate IS to legislate in too many
cases.

 

[Chris M. Thomasson]

[...]

The problem being that the software in these planes (and in
automobiles such as the Toyota) can't be written in a language like C
which does allow the programmer to code outside of sensible boundaries
for shits, giggles and "efficiency". Programmers need to be LESS
skilled and consider themselves clerks, and they need, in my view, to
be forced, especially in mission-critical systems, to be glorified
clerks, by requiring that they code in Java or C#, not C.

What about C++ Edward?


http://www2.research.att.com/~bs/JSF-AV-rules.pdf


IMO, this is definitely an area that simply cannot tolerate any type of bug
whatsoever. I can see it know:


Pilot: For some reason the bomb bay doors just opened and the plane quickly
became much lighter...


HOLY SHI%!!!!


:^o