Syntax for union parameter

R

Rick C. Hodgin

I still don't understand. How have I "chosen to code in a manner contrary
to the one that [I myself] prescribed"?

You suggested that perhaps MS agreed with you about specifying a
particular order of evaluation, and then decided to implement the
opposite order in their compiler "for whatever reason". James was
trying to ask you if you could think of a reason why /you/ might specify
one method then implement the opposite. If you can't imagine such a
reason for yourself, why do you think it is a realistic possibility for MS?

AH! Thank you.

One reason: Because it had been done a particular way previously when
Microsoft acquired some company (that wrote a better compiler), and they
then released it under the Microsoft name without taking out the few parts
they disagreed with (because they didn't deem them important enough
issues to slow down public sales).

Best regards,
Rick C. Hodgin
 
J

James Kuyper

AH! Thank you.

One reason: Because it had been done a particular way previously when
Microsoft acquired some company (that wrote a better compiler), and they
then released it under the Microsoft name without taking out the few parts
they disagreed with (because they didn't deem them important enough
issues to slow down public sales).

The history of Visual C++ that can be found at
<http://en.wikipedia.org/wiki/Visual_C++#History> is inconsistent
with that possibility - the last outside source mentioned in that
history was Lattice C, created by Lifeboat Associates, which was the
basis for Microsoft C 1.0, dating back to 1983. The thirty years that
have passed since then have been more than long enough for Microsoft to
review, and if desired, rewrite every single line of code in that compiler.

Even if such a reason did apply, it would just mean that, while
Microsoft might agree with you, Lifeboat Associates apparently did not,
and you describe their compiler as "better".

But it seems far more likely that, sometime during the last thirty
years, someone at Microsoft did, somewhere along the line, sit down and
think about this issue, and deliberately decided on the order that you
disapprove of, at least for this case. Whether that was a matter of
endorsing a decision previously made by Lifeboat Associates, or
reversing it, I have no idea.
 
R

Rick C. Hodgin

The history of Visual C++ that can be found at
<http://en.wikipedia.org/wiki/Visual_C++#History> is inconsistent
with that possibility - the last outside source mentioned in that
history was Lattice C, created by Lifeboat Associates, which was the
basis for Microsoft C 1.0, dating back to 1983. The thirty years that
have passed since then have been more than long enough for Microsoft to
review, and if desired, rewrite every single line of code in that compiler.

Well, first of all, it was a guess, a shot in the dark, a nothing-on-the-
line time-expiring half-court heave, to answer the question.

My retort to your retort:

Once released, legacy code was in place at that time ... since it was
undefined behavior in the standard, they went ahead and left it in there
despite the better voices whispering correct solutions into their collective
ears. In short: Money was talking, and the conscience sent walkin'.
Even if such a reason did apply, it would just mean that, while
Microsoft might agree with you, Lifeboat Associates apparently did
not, and you describe their compiler as "better".

"Better" being a relative term, better relative to Microsoft's prior
offering, not "better" in general or in the grand scope of things.
But it seems far more likely that, sometime during the last thirty
years, someone at Microsoft did, somewhere along the line, sit down and
think about this issue, and deliberately decided on the order that you
disapprove of, at least for this case. Whether that was a matter of
endorsing a decision previously made by Lifeboat Associates, or
reversing it, I have no idea.

Neither do I. So, we'll just leave it there: Neither of us know, both
of us are guessing, at least one of us is wrong. :)

Best regards,
Rick C. Hodgin
 
K

Kenny McCormack

Note: The fact is that C is not a "safe" language. And by safety, I mean
at least the following 3 things:

1) The behavior of any syntactically valid program is predictable and
consistent (across implementations).

I suspect that requirement is equivalent to the halting problem, and[/QUOTE]

I just want to point out that nowhere did I claim that C *should* be a safe
language. In fact, I stated just the opposite - that C is not and never
will be a safe language.

Therefore, all of your objections and explanations fall on stony ground.

P.S. I will point out that D was designed to be a "safe" versions of C -
with, among other things, condition 1) above satisfied. And, as I've said
at least once in this thread, if you want D, you know where to find it.
 
J

James Kuyper

On 02/07/2014 04:55 PM, Rick C. Hodgin wrote:
....
Once released, legacy code was in place at that time ... since it was
undefined behavior in the standard, they went ahead and left it in there
despite the better voices whispering correct solutions into their collective
ears. In short: Money was talking, and the conscience sent walkin'.

While a greed and a lack of conscience are well-established stereotypes
for Microsoft, many people with fully working consciences and a primary
desire to produce the best possible definition of what C should be,
reached decisions contrary to yours about whether it's a good idea to
fully specify the order of evaluation. Therefore, there's no need to
invoke those stereotypes; you need only invoke the same explanation for
Microsoft that you use to explain the rest of us, whatever that might
be. It will almost certainly includes some variant of "out-dated" or
"obsolete", those being among your favorite ways of dismissing contrary
opinions out-of-hand.
 
R

Rick C. Hodgin

While a greed and a lack of conscience are well-established stereotypes
for Microsoft, many people with fully working consciences and a primary
desire to produce the best possible definition of what C should be,
reached decisions contrary to yours about whether it's a good idea to
fully specify the order of evaluation. Therefore, there's no need to
invoke those stereotypes; you need only invoke the same explanation for
Microsoft that you use to explain the rest of us, whatever that might
be. It will almost certainly includes some variant of "out-dated" or
"obsolete", those being among your favorite ways of dismissing contrary
opinions out-of-hand.

It's not a stereotype. It's a guess: Legacy code made the decision on
what they should do, and so as to not lose sales... It's not unlikely.

Why do you continue to post to me, James? Wouldn't it be better to just
ignore me and my numerous flaws?

Best regards,
Rick C. Hodgin
 
R

Rick C. Hodgin

The comment about perl would make more sense if it were about APL. I
can't imagine why it was made about perl. In my experience, perl
programs are fairly easy to read. Understanding them is sometimes
trickier, but it's nowhere near to being in the same league with APL in
that regard.

I heard a similar one once. I'll try to get it right:

"If you get a million monkeys banging on a million keyboards,
eventually one of them will write a properly coded python
program. The rest will write in perl."

Best regards,
Rick C. Hodgin
 
J

James Kuyper

I heard a similar one once. I'll try to get it right:

"If you get a million monkeys banging on a million keyboards,
eventually one of them will write a properly coded python
program. The rest will write in perl."

Wow - like the comment I referred to earlier, that joke seems almost
completely unrelated to any of the actual, numerous, flaws in perl.
 
P

Phil Carmody

Noob said:
Kaz said:
Pop quiz.

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.

After the execution of a = a[i++], what should be the values in a[]?

Why?


I think a[0] contains 'U' and a[1] contains 'B'.


I know Kaz has been aiming for -1 flamebait ever since he caught
drepperitis years back, but apparently that's not enough, and he's
trying to scrape the -1 troll vote too nowadays.

I like what you fed him though.

Phil
--
What Alice Hill, President at Slashdot Media, writes:
Proven track record innovating and improving iconic websites
(Slashdot.org, ...) while protecting their voice and brand integrity
What Alice Hill means:
2013: Completely fucked up Slashdot, and ignored almost endless
negative feedback about her unwanted changes. 2014: Killed slashdot.
 
P

Phil Carmody

Keith Thompson said:
No, that's why traffic lights are always ordered red/yellow/green from
top to bottom (at least in the US).

Green is doped with blue. And a totally different luma.
There's no confusion.

Phil (anomalous dichromat)
--
What Alice Hill, President at Slashdot Media, writes:
Proven track record innovating and improving iconic websites
(Slashdot.org, ...) while protecting their voice and brand integrity
What Alice Hill means:
2013: Completely fucked up Slashdot, and ignored almost endless
negative feedback about her unwanted changes. 2014: Killed slashdot.
 
P

Phil Carmody

James Kuyper said:
Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.
After the execution of a = a[i++], what should be the values in a[]?
Why?

I think a[0] contains 'U' and a[1] contains 'B'.


:) UB3... :)

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3


Not in C.


You can't be sure of that, that's the beauty of it!

Phil
--
What Alice Hill, President at Slashdot Media, writes:
Proven track record innovating and improving iconic websites
(Slashdot.org, ...) while protecting their voice and brand integrity
What Alice Hill means:
2013: Completely fucked up Slashdot, and ignored almost endless
negative feedback about her unwanted changes. 2014: Killed slashdot.
 
J

James Kuyper

James Kuyper said:
On Wednesday, February 5, 2014 1:32:06 PM UTC-5, Noob wrote:
Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.
After the execution of a = a[i++], what should be the values in a[]?
Why?

I think a[0] contains 'U' and a[1] contains 'B'.

:) UB3... :)

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3


Not in C.


You can't be sure of that, that's the beauty of it!


That's what I meant - there are no incorrect answers to that question,
which is why his use of "the" and "always" was incorrect.
 
K

Kaz Kylheku

Until I switch from compiler A to compiler B ... then C becomes useless.

No; you see, only a standards-ignorant approach to C becomes problematic.

The unspecified evaluation order in C is dumb, but it's only one example
where specifications are important.

C has undefined, unspecified and implementation-defined behaviors in it left,
right and centre.

Other languages have undefined behavior, too, though maybe not as much.

For instance, Common Lisp is a language in which, generally, most of what you
learn by interacting with an implementation can be trusted to be descriptive of
the language. Yet there are pitfalls:

(setq foo 42) ;; foo has not been introduced as a variable

(setf (car '(a b)) 'c) ;; modification of a literal
I would argue that having C without standards has allowed the creation
of niche empires. A developer with a large code base dare not migrate
away from a toolset, lest they face so many bugs that it makes it
impossible to execute.

There hasn't been C without standardization since around middle 1980's.

Ignorance of standards is not the same as not having them, but the effects
are the same, I will give you that.
 
K

Kaz Kylheku

Seriously, James? Are we back to this (again). *SIGH* This will be my
last post to you on any issue relating to whether or not compiler authors
agree with me.

The scope here is "on this point." The GCC compiler authors agree with
me (on this point) because they wrote their compilers to operate as I
have indicated.

Can you cite something from the documentation of GCC to substantiate your
belief?

I do not believe that GCC has a well-defined order for a = a[i++] and
similar.
 
J

Jorgen Grahn

.
Also Java is 'controlled' by a single entity, if you
want your implementation of the spec to be called 'Java' you had better
make sure it passes certification.

Well, it's not as if there are lots of compilers which claim to
implement C but really don't. In the 1980s maybe, but not today.

(Disregarding the poor support for C99 in some compilers.)
The situation with C appears to be
different ... since when has anything 'designed by committee' ever been
coherent?

Hey, C wasn't designed by a committee! It was Dennis and his friends,
back around 1970. It's /maintained/ via a committee though.

/Jorgen
 
R

Robbie Brown

That's natural. C was designed in the 70s to be a low-level language
that is a bit more portable the B (which was nothing by the type-less
bit-shuffling language). Java was designed in the 90s to be as portable
as possible -- the VM is intended to remove any dependency on the
underlying hardware. A lot of the undefined things in C are there
to permit the compiler to be "cheap": shifts can do whatever the
hardware does, and the undefined evaluation order can save a register
here and there depending on the machine instruction set.


That may be true, but is there anything incoherent going on in this
case?

The idea that something can be 'standardized' and still allow
flexibility of implementation sounds like wanting your cake and eating
it to me ... the result, well I tried to count the number of times the
word 'undefined' appeared in n1256.pdf I got to 57 in first 100 pages
then decided to do something more productive.

Anyway, it's no surprise to me that people get so defensive about their
chosen language, it happens regardless of the language.
 
R

Rick C. Hodgin

...C wasn't designed by a committee! It was Dennis and his friends...

"Dennis and his friends" ... multiple people involved ... a specific
purpose in mind ... committee.

Best regards,
Rick C. Hodgin
 
R

Rick C. Hodgin

The standard says nothing about command line options, which is good,
because if it did, it would prohibit the use of compilers that are built
into an IDE, with the option list controlled by menu choices, rather
than a command line. This is a prime example of the advantages of
avoiding unnecessary specificity in a standard.

Oh for crying out loud, James ... the point is not the mechanical
implementation of the option, but rather that the option exists.

How can you be like this? It's truly boggling.
Also, keep in mind that standard allows such optimizations; but
in no way does it mandate them. Therefore, an implementation is free
to provide exactly the features you describe, while remaining fully
conforming regardless of which option you choose. Many do provide a
feature similar to that, except that the interface is reversed: certain
minimum optimizations, some of which may require excersizing the
implementation's right to rearrange the order of evaluation, are on by
default. A special option is required to turn them off, not on. It's
done that way because it matches the preferences of most of the users,
who prefer turn off the default optimizations only when they want to
make the behavior more predictable (for instance, for tracking down bugs).

A standard should define how things operate in all cases. It should
define specific behavior that can be relied upon no matter the platform,
no matter the implementation, no matter the circumstances. And in all
cases, for all times, and in every situation, every last one of those
standards should be allowed to be violated through specific options
which purposefully, by design, enable or disable certain features.
These options should be determined by specific hardware advantages, or
limitations, thereby requiring or lending themselves naturally toward
their ends.

The fact that C leaves things up in the air is absolutely mind blowing
to me. How could a computer language be so poorly written? It is
absolutely essential that nothing be left to chance or personal desires
for implementation. The standard should define it all, and then anyone
who wants to deviate is free also to do so.

Best regards,
Rick C. Hodgin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,077
Messages
2,570,566
Members
47,202
Latest member
misc.

Latest Threads

Top