1 - You are using the term "conversion" as being something different than what I was calling "implicit casting". Your example of LHS and RHS types differing is exactly what my term "implicit casting" was referring to. Consider the following two statements: long foo = 1L; int bar = 2;...// Two similar statements: foo = bar;// 1 foo = (long)bar;// 2
If version 1 does something different from version 2, then your compiler is broken.
2 - As to your comment "given that there's no such thing as a Boolean type in C89" - I never said Boolean type. I said Boolean expression: For example "x y", or " !ptr "
3 - There are a few things the standard doesn't explicitly say that still makes an implementation be broken if it doesn't do it. For example, there's no guarantee that malloc() ever return anything other than NULL. Theoretically a C library could put in a stub that just says "return NULL" for malloc(), and be following the standard library rules, and yet it would still be broken and completely useless. Similarly, regardless of what the standard says, any compiler that treats a casting of a literal constant differently than the casting of a variable with the same value as that constant, is inherently broken. Any compiler that mangles a value when converting one-way and doesn't inverse the mangling as best it can when going the other, is also inherently broken. The only excuse for that is if the values are literally impossible to convert without lossage - like trying to take a value of 800 billion in a long, and stuff it into a short. Clearly that is not the case with the NULL pointer mapping.
So I will concede the point, with that caveat. It is possible to make a broken piece of shit compiler that technically conforms to the standard in the letter of the law but not the spirit of the law, and does what you say. It would not really be "C", though, in the same sense that Microsoft's "Posix" isn't really Posix despite hitting all the bullet points in the listed rules.
The blame for that lays partly with the compilers and partly with the standards committe for not nailing things down. There are too many places where something is left "implementation dependant" even though there is one way to do it that makes the most obvious logical sense to a programmer trying to use the language - like casting being two-way wherever possible, and implicit versus explicit casting having the same effect everywhere, and casting a constant having the same effect as casting a variable of the same type.
I just love the image of invaders trying to take over Great Britain, and all these recent "knights" made in the last 50 years being asked to defend the realm - Musicians, Artists, Actors, and now Bill Gates, all trying to walk in plate-mail and get up on a horse.
one cannot find in the ANSI C standard any requirement that null pointers be represented with all their bits zero.
In a single statement? No. In the logical combination of different parts? Probably - but I haven't paid $18.00 plus shipping and handling to get my copy of the actual standard. I only have FAQs and summaries to go on. Here is the logical path (where I outline the specific case where I can't find what the standard says):
1 - NULL is defined via a cast operation. Since it MUST be a macro of "(void*)0", that means the compiler cannot treat "NULL" and "(void*)0" differently. They must be the same in all cases. Therefore, if there is any mangling of the zero, turning it into something nonzero, it MUST be the cast operator that is doing so, such that if foo=zero, then (void*)foo results in the same mangling of the value as NULL does.
2 - So long as all the possible values of type Foo are expressable with a mapping into Bar (i.e. Bar is at least as big as Foo), then that means nothing gets lost from a casting of Foo into Bar, or in other words a circular casting chain of: (Foo)(Bar)(Foo)i results in the same 'i' as just (Foo)i does. (***This is what I need to see in the standard to look up - I need to see the section on castings***).
3 - Therefore, if an implementation maps (int)0 into some nonzero representation for NULL when casting it to (void*), then it must also do the opposite, and cast that same nonzero NULL representation back into zero again when casting from (void*) back to (int).
4 - boolean expressions automatically get casted back to int.
5 - therefore the expression: if( expr ) { } Will result in expr getting silently cast into an int (and if it cannot be cast like that, it's a syntax error, like if expr evaluated to a struct.) Therefore the expression: if( ! ptr ) { } results in a cast from pointer to int, assuming ptr is a pointer.
Therefore if ptr == NULL, then that casting into an int should reverse the value-mangling that happened when 0 was cast to (void*), and give you back a zero again. If it does not, then it is a broken implementation of the casting operator.
And if it casts back into an int, and unmangles it back to a zero when doing so, then, to unroll this discussion, a jump-if-zero or jump-if-not-zero could be used by the compiler to implement it.
In other words, like I said, the concept of an Ansi C NULL pointer is at a higher level than the archetecture, and at that level, NULL is a zero. Thus if the archetecture doesn't like calling it zero, then the compiler will have to do some "magic" to make it present the lie that its a zero to the programmer.
But null pointers are a concept at a higher level than the archetecture. Thus I don't buy the notion that a hardware archetecture would ever mandate that a null pointer must be FEFE:FFFFFFFF. C's Null pointers are a concept at the language level, not the hardware level - some pointer that, despite looking like a valid pointer to the hardware, still is by convention not going to be used for anything 'real'. There's never any reason you'd be unable to use zero for that on some archetecture.
The only case where a cast can cause bits of value 1 to be added to a value is when the value starts out negative and it's being lengthened to a larger number of bytes (for example, casting (short)-1 into a (long) will pad with 1 bits rather than 0 bits).
But under what circumstances will a value of zero be padded out with anything other than more zeros when casting it?
Actually, in ALL C implementations that follow the standard. The standard mandates that NULL be "(void*)0". Only pre-standards versions of K&R old-style C would be allowed to do it differently.
Farking mozilla buggy textarea typing! The jumbled text at the end is NOT what I actually typed. It jumped the cursor about in broken ways as I was typing. (hit backspace, and it goes somewhere totally random within the text instead of to the previous position. I didn't catch that it was doing this until after I posted.)
there is no way to be entirely certain that the flag values contained in the flag register are consistant with the value of ptr
Yes there is. The compiler will perform the assignment into ptr as the last step of the malloc line (it has to - the call has to be finished before it assigns its return value into ptr). Therefore the compiler will have the value of ptr in a register already as a side effect of that assignment. All it needs to do is optimize itself to do so using the same register that the JNZ instruction can operate on.
Compilers now-a-days are awesome tools. Trust them, don't try to out-think them most times.
Yes. I said so already. You're attempting to belittle me by responding to my post as if I made a point much stupider than the one I actually made. The person I was replying to was claiming that in both cases (!ptr) and (ptr!=NULL), such-and-such, and I was saying in both cases it would be this-and-that. Neither of us was claiming that the two casese would end up being different. Both of us knew the compiler would render them into the same result - we disagreed as to what that result would be.
I still don't care for them, because I know that what they are trying to do is not actually supported by the hardware, and is therefore inefficient. The hardware supports booleans that are zero versus nonzero, with instructions like jump if not zero and jump if zero, that all machine languages use. To force a boolean type down into just being 1 or 0 requires that the compiler insert extra code to mash the numbers down into only those two choices - the machine language equivilent of:
if( actual_value_behind the scenes )// is nonzero { value_the_high_level_program_sees = 1; }
Yeah, but what does that have to do with being able to pay off the commitments?
Nothing. It has to do with your implication that it can be done without screwing anyone over. My original claim is that trying to stop the system will make someone get screwed over no matter what because if you stop paying out now, the old people who already paid their dues get a raw deal, and if you try to grandfather the system out slowly by continuing to pay for them but not for the next generation, then the young people currently paying for it get the raw deal.
Then you came along and proposed fixing this problem by having the government pay out the owed benefits of its own pocket and trimming the fat elsewhere to pay for it. But what you don't seem to take into account is that regardless of whether the government pays for it out of the general pool of income tax like all the other government spending is payed for, or whether it continues to make it a seperate itemized category on your W-2's like they do now, the effect screws the young generation just as much either way. No matter which of those two methods is used, the young are paying for it and they won't be getting compensated for that later on like the previous generatiosn did.
So, as I said, stopping the system ensures some group gets unfairly screwed.
I cringe whenever I see code that says "if( x == true )", becuase I wonder, "but what if X = 2, or 3, or -1??, those values are not false, but this code will think they are.
Since the smallest addressable space is NOT a single bit, but rather is an entire byte, the whole notion of a boolean type that can only be zero or one is a bit of a lie. I much prefer to use a mapping that catches the entire value space, leaving no such thing as an "undefined" value. So, a boolean should be "zero = false, everything else = true", as opposed to "zero = false, one = true, everything else = a gotcha that varies depending on if the programmer wrote positive checks or negative ones."
I agree that you should write the more clear form, and damn the optimization. But I disagree that the second form is the more clear one. The first one reads as "if not pointer", which very consisely and completely conveys the meaning that is intended, which is "If this thing isn't really a pointer to anything."
The problem comes from the fact that some functions that return integers do so in a way that has the inverse of the intuitive boolean interpretation. (Zero means true). One example is strcmp(), I'd much rather see if( strcmp(s1,s2) == 0 ) than if( ! strcmp(s1,s2) ), since the boolean version has 100% inverted meaning from what it looks like. System calls (man page 2) typically have the same problem. It's not that the calls themselves are bad (they have good reasons to return zero for success - becuase they have more than one kind of failure), but that the people using them should never have gotten into the habit of using inverted boolean symbology to interpret them in their code.
If an integer doesn't behave like a boolean, then just treat it as an integer. Don't take advantage of the lose typing of C to treat it like a boolean that means the opposite of what it means.
Not true. Many CPUs have a unary jump-if-zero, or a jump-if-nonzero operation. Thus the comparasin step can be bypassed since you know you're comparing to zero.
However, any compiler worth anything should find that and optimize it very easily in the case where you're comparing to a constant that evaluates to zero.
Franklin was not a more minor founding father than the others in the US revolution, but he was a more minor one than Marx was within the revolutions his ideas spawned, and that's the comparasin that matters here. If the library stocks N books about the American revolution and N books about communism, even if the numbers are equal the marx section will still be larger than any individual ONE contributor to the American revolution. The American revolution "pie" has to be split many ways, between Franklin, Jefferson, Madison, Washington, Thomas Paine, John Adams, etc, etc, etc....
Marx gets more space individually simply because he was more alone in founding his political theories at a time when he didn't have many similarly minded contemporaries saying similar things.
No. The difference is that the ideas of the American revolution don't have a single author. Franklin wasn't the sole father of the revolution. Jefferson wasn't. Madison wasn't, etc. - they ALL had a hand in building the idea. Thus even if the library decides to commit an equal amount of space to both the American Revolution and to Marxism, that space committed to Marxism will contain titles constantly mentioning Marx, Marx, Marx, Marx all over the place. The books about the American Revolution will be divided among MANY prominent figures, of which Franklin is just one.
Therefore the evidence that there are less franklin books than marx books does NOT lead to the conclusion that there is a bias toward more leftist books being stocked. Sum the total of all communist books, be they marx or not, and sum the total of all the American revolution books, be they franklin or not.
The American Revolution literature, ironicly enough, has more examples of sharing and consensus between authors than the Communist ones.
Franklin was one person of several starting the movement that led to the American revolution. Marx was the SOLE person starting Marxism. It's even named after him. Therefore if you see a section of books about Marx, it's going to include BOTH books that are personal stuff about the man and books that are political books about the man's theories. Whereas if you see a section of books about Franklin, it's only going to contain the personal stuff about the man. Books about Franklin's politics are going to be merged into the general stuff about the American Revolution.
The library probably doesn't have more marx material than Franklin material, actually. It's just not as easy to organize it into one spot.
And that fits the definition of a pyramid scheme, exactly how? A pyramid scheme is something that even if it was running at ZERO overhead cost would still require a larger pool of donors with each tier to work.
That's a non sequitor. To claim that it needs more people participating each year because of overhead, it is insufficient to merely point out that an overhead exists. You would have to show the overhead is becoming bigger over time. Citing a single datapoint doesn't do that.
It's only a pyramid scheme if each successive tier must be larger than the previous one in order to work (hence the pyramid shape when you draw it out). Here it doesn't form a pyramid - more of a rectangle. You only need an equal number of people on the next tier for it to work, not a greater number.
(Thus what makes pyramid schemes wrong and what makes this wrong are slightly different. A pyramid scheme is wrong becuase it grows exponentially in just a few tiers and soon would need many more billion people than actually live on the whole planet to keep working.)
Regardless of whether you itemize it as a seperate social security line item on people's W2's, or you take it from out of the general pool of income tax (which is what you are doing if the government itself pays it out), the effect is exactly the same.
You're operating under the false premise that the people who paid into it got to pick between SS or an annuity. That's bullshit. Their choices were SS or jail. It's not like they opted-in and were too dumb to know what they were opting into, as you falsely portray.
Slashdot Mirror
A couple of points:
... // Two similar statements: // 1 // 2
1 - You are using the term "conversion" as being something different than what I was calling "implicit casting". Your example of LHS and RHS types differing is exactly what my term "implicit casting" was referring to. Consider the following two statements:
long foo = 1L;
int bar = 2;
foo = bar;
foo = (long)bar;
If version 1 does something different from version 2, then your compiler is broken.
2 - As to your comment "given that there's no such thing as a Boolean type in C89" - I never said Boolean type. I said Boolean expression: For example "x y", or " !ptr "
3 - There are a few things the standard doesn't explicitly say that still makes an implementation be broken if it doesn't do it. For example, there's no guarantee that malloc() ever return anything other than NULL. Theoretically a C library could put in a stub that just says "return NULL" for malloc(), and be following the standard library rules, and yet it would still be broken and completely useless. Similarly, regardless of what the standard says, any compiler that treats a casting of a literal constant differently than the casting of a variable with the same value as that constant, is inherently broken. Any compiler that mangles a value when converting one-way and doesn't inverse the mangling as best it can when going the other, is also inherently broken. The only excuse for that is if the values are literally impossible to convert without lossage - like trying to take a value of 800 billion in a long, and stuff it into a short. Clearly that is not the case with the NULL pointer mapping.
So I will concede the point, with that caveat. It is possible to make a broken piece of shit compiler that technically conforms to the standard in the letter of the law but not the spirit of the law, and does what you say. It would not really be "C", though, in the same sense that Microsoft's "Posix" isn't really Posix despite hitting all the bullet points in the listed rules.
The blame for that lays partly with the compilers and partly with the standards committe for not nailing things down. There are too many places where something is left "implementation dependant" even though there is one way to do it that makes the most obvious logical sense to a programmer trying to use the language - like casting being two-way wherever possible, and implicit versus explicit casting having the same effect everywhere, and casting a constant having the same effect as casting a variable of the same type.
I just love the image of invaders trying to take over Great Britain, and all these recent "knights" made in the last 50 years being asked to defend the realm - Musicians, Artists, Actors, and now Bill Gates, all trying to walk in plate-mail and get up on a horse.
one cannot find in the ANSI C standard any requirement that null pointers be represented with all their bits zero.
In a single statement? No. In the logical combination of different parts? Probably - but I haven't paid $18.00 plus shipping and handling to get my copy of the actual standard. I only have FAQs and summaries to go on. Here is the logical path (where I outline the specific case where I can't find what the standard says):
1 - NULL is defined via a cast operation. Since it MUST be a macro of "(void*)0", that means the compiler cannot treat "NULL" and "(void*)0" differently. They must be the same in all cases. Therefore, if there is any mangling of the zero, turning it into something nonzero, it MUST be the cast operator that is doing so, such that if foo=zero, then (void*)foo results in the same mangling of the value as NULL does.
2 - So long as all the possible values of type Foo are expressable with a mapping into Bar (i.e. Bar is at least as big as Foo), then that means nothing gets lost from a casting of Foo into Bar, or in other words a circular casting chain of: (Foo)(Bar)(Foo)i results in the same 'i' as just (Foo)i does. (***This is what I need to see in the standard to look up - I need to see the section on castings***).
3 - Therefore, if an implementation maps (int)0 into some nonzero representation for NULL when casting it to (void*), then it must also do the opposite, and cast that same nonzero NULL representation back into zero again when casting from (void*) back to (int).
4 - boolean expressions automatically get casted back to int.
5 - therefore the expression:
if( expr )
{
}
Will result in expr getting silently cast into an int (and if it cannot be cast like that, it's a syntax error, like if expr evaluated to a struct.)
Therefore the expression:
if( ! ptr )
{
}
results in a cast from pointer to int, assuming ptr is a pointer.
Therefore if ptr == NULL, then that casting into an int should reverse the value-mangling that happened when 0 was cast to (void*), and give you back a zero again. If it does not, then it is a broken implementation of the casting operator.
And if it casts back into an int, and unmangles it back to a zero when doing so, then, to unroll this discussion, a jump-if-zero or jump-if-not-zero could be used by the compiler to implement it.
In other words, like I said, the concept of an Ansi C NULL pointer is at a higher level than the archetecture, and at that level, NULL is a zero. Thus if the archetecture doesn't like calling it zero, then the compiler will have to do some "magic" to make it present the lie that its a zero to the programmer.
But null pointers are a concept at a higher level than the archetecture. Thus I don't buy the notion that a hardware archetecture would ever mandate that a null pointer must be FEFE:FFFFFFFF. C's Null pointers are a concept at the language level, not the hardware level - some pointer that, despite looking like a valid pointer to the hardware, still is by convention not going to be used for anything 'real'. There's never any reason you'd be unable to use zero for that on some archetecture.
How??
The only case where a cast can cause bits of value 1 to be added to a value is when the value starts out negative and it's being lengthened to a larger number of bytes (for example, casting (short)-1 into a (long) will pad with 1 bits rather than 0 bits).
But under what circumstances will a value of zero be padded out with anything other than more zeros when casting it?
in most C implementations.
Actually, in ALL C implementations that follow the standard. The standard mandates that NULL be "(void*)0". Only pre-standards versions of K&R old-style C would be allowed to do it differently.
Farking mozilla buggy textarea typing! The jumbled text at the end is NOT what I actually typed. It jumped the cursor about in broken ways as I was typing. (hit backspace, and it goes somewhere totally random within the text instead of to the previous position. I didn't catch that it was doing this until after I posted.)
there is no way to be entirely certain that the flag values contained in the flag register are consistant with the value of ptr
Yes there is. The compiler will perform the assignment into ptr as the last step of the malloc line (it has to - the call has to be finished before it assigns its return value into ptr). Therefore the compiler will have the value of ptr in a register already as a side effect of that assignment. All it needs to do is optimize itself to do so using the same register that the JNZ instruction can operate on.
Compilers now-a-days are awesome tools. Trust them, don't try to out-think them most times.
Yes. I said so already. You're attempting to belittle me by responding to my post as if I made a point much stupider than the one I actually made. The person I was replying to was claiming that in both cases (!ptr) and (ptr!=NULL), such-and-such, and I was saying in both cases it would be this-and-that. Neither of us was claiming that the two casese would end up being different. Both of us knew the compiler would render them into the same result - we disagreed as to what that result would be.
I still don't care for them, because I know that what they are trying to do is not actually supported by the hardware, and is therefore inefficient. The hardware supports booleans that are zero versus nonzero, with instructions like jump if not zero and jump if zero, that all machine languages use. To force a boolean type down into just being 1 or 0 requires that the compiler insert extra code to mash the numbers down into only those two choices - the machine language equivilent of:
// is nonzero
if( actual_value_behind the scenes )
{ value_the_high_level_program_sees = 1;
}
Yeah, but what does that have to do with being able to pay off the commitments?
Nothing. It has to do with your implication that it can be done without screwing anyone over. My original claim is that trying to stop the system will make someone get screwed over no matter what because if you stop paying out now, the old people who already paid their dues get a raw deal, and if you try to grandfather the system out slowly by continuing to pay for them but not for the next generation, then the young people currently paying for it get the raw deal.
Then you came along and proposed fixing this problem by having the government pay out the owed benefits of its own pocket and trimming the fat elsewhere to pay for it. But what you don't seem to take into account is that regardless of whether the government pays for it out of the general pool of income tax like all the other government spending is payed for, or whether it continues to make it a seperate itemized category on your W-2's like they do now, the effect screws the young generation just as much either way. No matter which of those two methods is used, the young are paying for it and they won't be getting compensated for that later on like the previous generatiosn did.
So, as I said, stopping the system ensures some group gets unfairly screwed.
The ISO standard says that an implementation is NOT free to do that.
Maybe in the days of K&R that was true.
I cringe whenever I see code that says "if( x == true )", becuase I wonder, "but what if X = 2, or 3, or -1??, those values are not false, but this code will think they are.
Since the smallest addressable space is NOT a single bit, but rather is an entire byte, the whole notion of a boolean type that can only be zero or one is a bit of a lie. I much prefer to use a mapping that catches the entire value space, leaving no such thing as an "undefined" value. So, a boolean should be "zero = false, everything else = true", as opposed to "zero = false, one = true, everything else = a gotcha that varies depending on if the programmer wrote positive checks or negative ones."
I agree that you should write the more clear form, and damn the optimization. But I disagree that the second form is the more clear one. The first one reads as "if not pointer", which very consisely and completely conveys the meaning that is intended, which is "If this thing isn't really a pointer to anything."
The problem comes from the fact that some functions that return integers do so in a way that has the inverse of the intuitive boolean interpretation. (Zero means true). One example is strcmp(), I'd much rather see if( strcmp(s1,s2) == 0 ) than if( ! strcmp(s1,s2) ), since the boolean version has 100% inverted meaning from what it looks like. System calls (man page 2) typically have the same problem. It's not that the calls themselves are bad (they have good reasons to return zero for success - becuase they have more than one kind of failure), but that the people using them should never have gotten into the habit of using inverted boolean symbology to interpret them in their code.
If an integer doesn't behave like a boolean, then just treat it as an integer. Don't take advantage of the lose typing of C to treat it like a boolean that means the opposite of what it means.
Not true. Many CPUs have a unary jump-if-zero, or a jump-if-nonzero operation. Thus the comparasin step can be bypassed since you know you're comparing to zero.
However, any compiler worth anything should find that and optimize it very easily in the case where you're comparing to a constant that evaluates to zero.
Franklin was not a more minor founding father than the others in the US revolution, but he was a more minor one than Marx was within the revolutions his ideas spawned, and that's the comparasin that matters here. If the library stocks N books about the American revolution and N books about communism, even if the numbers are equal the marx section will still be larger than any individual ONE contributor to the American revolution. The American revolution "pie" has to be split many ways, between Franklin, Jefferson, Madison, Washington, Thomas Paine, John Adams, etc, etc, etc....
Marx gets more space individually simply because he was more alone in founding his political theories at a time when he didn't have many similarly minded contemporaries saying similar things.
No. The difference is that the ideas of the American revolution don't have a single author. Franklin wasn't the sole father of the revolution. Jefferson wasn't. Madison wasn't, etc. - they ALL had a hand in building the idea. Thus even if the library decides to commit an equal amount of space to both the American Revolution and to Marxism, that space committed to Marxism will contain titles constantly mentioning Marx, Marx, Marx, Marx all over the place. The books about the American Revolution will be divided among MANY prominent figures, of which Franklin is just one.
Therefore the evidence that there are less franklin books than marx books does NOT lead to the conclusion that there is a bias toward more leftist books being stocked. Sum the total of all communist books, be they marx or not, and sum the total of all the American revolution books, be they franklin or not.
The American Revolution literature, ironicly enough, has more examples of sharing and consensus between authors than the Communist ones.
Franklin was one person of several starting the movement that led to the American revolution. Marx was the SOLE person starting Marxism. It's even named after him. Therefore if you see a section of books about Marx, it's going to include BOTH books that are personal stuff about the man and books that are political books about the man's theories. Whereas if you see a section of books about Franklin, it's only going to contain the personal stuff about the man. Books about Franklin's politics are going to be merged into the general stuff about the American Revolution.
The library probably doesn't have more marx material than Franklin material, actually. It's just not as easy to organize it into one spot.
the relative dearth of device drivers available for Linux (compared to what is available for Windows)
That's a false premise. Linux has more drivers. Windows only has more drivers when you limit your scope to talking only about Intel PC's.
assuming people get out what they put in.
That unstated assumption on your part was not an assumption I was sharing.
And that fits the definition of a pyramid scheme, exactly how? A pyramid scheme is something that even if it was running at ZERO overhead cost would still require a larger pool of donors with each tier to work.
That's a non sequitor. To claim that it needs more people participating each year because of overhead, it is insufficient to merely point out that an overhead exists. You would have to show the overhead is becoming bigger over time. Citing a single datapoint doesn't do that.
When you call what you do here "debate", you are lying.
It's only a pyramid scheme if each successive tier must be larger than the previous one in order to work (hence the pyramid shape when you draw it out). Here it doesn't form a pyramid - more of a rectangle. You only need an equal number of people on the next tier for it to work, not a greater number.
(Thus what makes pyramid schemes wrong and what makes this wrong are slightly different. A pyramid scheme is wrong becuase it grows exponentially in just a few tiers and soon would need many more billion people than actually live on the whole planet to keep working.)
Regardless of whether you itemize it as a seperate social security line item on people's W2's, or you take it from out of the general pool of income tax (which is what you are doing if the government itself pays it out), the effect is exactly the same.
You're operating under the false premise that the people who paid into it got to pick between SS or an annuity. That's bullshit. Their choices were SS or jail. It's not like they opted-in and were too dumb to know what they were opting into, as you falsely portray.