Comment Re:PHP? (Score 1) 213
sigh...
Whatever kid. You win. I have actual work to do.
sigh...
Whatever kid. You win. I have actual work to do.
In ways you cannot undersand, evidently. The distinction on C when comparing type-casted operands is precisely because casting is guaranteed to destroy precision - operands are effectively modified in the process. This has NOTHING to do with the way relational operators work: they behave in a sane way, like they do in every other language on Earth.
Now contrast that with the idiotic PHP decision of setting rules for relational operators leading to circular logic. I know the "this might fool the typical PHP developer" warning went over your head, but ponder on this: on my original PHP code snippet, where's the "loss of precision"?
Where's the casting?
Hell, where do you apply your "object has precedence" mantra on it?
I really can't believe that someone could not only defend this madness so vehemently, but also without really understanding what he/she is talking about. Try a new language, son. It will open your horizons.
PS: I'm a he, not a she.
Just like PHP!
Just like PHP, where comparison operators are transitive except in cases where precision is lost in type-casting of operands.
Yeah. I'm dying to know what the "loss of precision" is when comparing a float to an array to an object.
No, you know what? I don't. Go have fun with your toy websites.
Dude, you are the one who's flat out wrong. Not only C has transitive relationship operators, but the language specification actually states that value comparison operators must be transitive except in cases where precision is lost in type-casting of operands.
So, for example, this might fool the typical PHP developer...
int main(void) {
unsigned long a = 98765UL;
int b = -12345;
short c = 1;
if (a < b) printf("a < b!\n");
if (b < c) printf("b < c!\n");
if (c < a) printf("c < a!\n");
}
int main(void) {
unsigned long a = 98765UL;
int b = -12345;
short c = 1;
if (a < (long)b) printf("a < b!\n");
if (b < (int)c) printf("b < c!\n");
if (c < (short)a) printf("c < a!\n");
}
Compare this to the brainfuck that is PHP, where comparison rules are well stablished but still manage to produce this crap. I can't believe i'm actually discussing this.
No, it should not be complicated. It does not make sense - PHP is the only, and i mean only language i found with comparison rules that are non-transitive. And even worse, circular.
Because it's a language that others are likely to already understand. PHP is also written in C, which likely influenced the language.
So are Python, Perl, Ruby and Java, and you won't see anyone comparing them to C. That's a poor argument.
Oh, and by the way. Why do people insists on comparing PHP to C? Isn't PHP supposed to be a high-level, website oriented scripting language?
I ask because i've seen bugs about PHP segfaulting reliably rejected only because "this behavior is consistent with what lower level languages like C do". It's like watching an exploit slowly growing from its infancy.
I see. You're just confused by dynamic languages. Try the same operations in C, with the relevant casts, and note the results. Hey, look at that! Not quite so "nonsensical" now, is it?
Like I said, give that article a good fact-check. You'll regret ever recommending it.
"Dynamic languages" eh? Show me a "dynamic language" where i can do this (blatantly stolen from this site):
$ cat circular.php
<?php
$a = INF;
$b = array();
$c = (object)array();
var_dump($a < $b);
var_dump($b < $c);
var_dump($c < $a);
$ php circular.php
bool(true)
bool(true)
bool(true)
You're right though. Nonsense confuses me.
Really? Most, if not all of it, is stuff i've ran into in the past. The nonsensical comparison operator results and the so-called "arrays" pop into my mind right now...
get a life.. for real. Always easy to play MMQB, harder to actually *do* something.
I've worked with PHP and its assorted web frameworks enough times to completely relate to what that site tells.
That an amateur language like PHP holds 80% of the web marketshare seems insane until you actually realize that 80% of the web is hardly professionally developed either.
Ditto. Writing a custom malloc is insane for a sensitive security library like this... specially when it is done so carelessly.
The fact that OpenSSL won't even work using regular malloc() suggests that there're more issues waiting to pop up here.
Think it this way. Using the current memory management implementation on OpenSSL adding a test case for the exploit would not have triggered any issues. At all. Using a regular malloc() on any half-decent *nix system would've immediately triggered an alert when run through Valgrind or similar.
Reusing memory with a freelist on a sensitive library like OpenSSL is a problem waiting to happen.
Writing a custom malloc on a security sensitive product like this is a problem waiting to happen, specially when you do so carelessly. Freelists? No memory cleanup? Theo's right here.
It does, but it is more likely just sloppy programming / testing. Don't forget the custom malloc implementation (via freelists) OpenSSL uses which contributed to the issue and Theo de Raadt eloquently ranted about.
No amount of careful planning will ever replace dumb luck.