Are they initialisms, though? Do you read "FTFA" as "eff tee eff ay" or "from the f*king article" ? Most people I know do the latter, which means its not an initialism either.
Hm, why do you think we haven't evolved with perfect memory? Could there be a good reason?
Unless you believe in intelligent design, there may be no reason at all... As my old bio teacher used to intone, "evolution proceeds towards what works, not what's best."
Intelligent design has nothing to do with it. Your assertion is that we don't have capabilities like this because we haven't needed them enough yet? Isn't it possible that such things (like being able to go without oxygen for a long time) would involve too significant a cost for the rare cases it would be needed and therefore is not worth the tradeoff?
I don't want to sound conspiratorial, but the trajectory the plane took makes no sense to me. In an airshow you always stay in a designated zone on the other side of a runway from the crowd. The other planes earlier in the video were clearly in that zone. The plane that crashed was coming in at a very steep angle - probably more than 70 degrees - and from what I can tell in the video, he was moving *away* from the bleachers towards the acrobatic zone. You're not ever supposed to be over the crowd like that or take a trajectory that crosses above the crowd, even at substantial altitude. How did this happen?
The potential of crashes is indeed part of the point. But in general people prefer the thrill to be derived from those engaged in the pursuit risking their lives, not those in the audience. Messed up, but true.
It seems to be taken as a given in this document that Javascript is unusable.... But there is no explanation of why this is the case (except perhaps for google's business needs) - what exactly is the problem with it? Performance is quite good these days thanks in large part to google's chrome folks. Few languages are easier to use, but it is still quite powerful.
Actually, T-mobile will be in pretty decent shape if the merger with AT&T doesn't go through - they get $3 billion in such a circumstance. As for the iPhone, that's also wrong - until the Verizon iPhone came out, the carrier with the second largest number of iPhones was T-mobile (hacked and 3G less, but still paying T-mobile).
So, umm, yeah. Your two main premises are either completely wrong or seriously flawed.
It's a game of chicken, where Google says, ok, lay off my pals that are making Android phones, or you have to sue, us, too-- and you don't REALLY want to do that, do you?
Why on earth would anyone be forced to sue Google if they didn't want to?
+1. To say Google "needs" Firefox is just ludicrous.
Google benefits from Firefox. Google wants Firefox traffic. But since Firefox has always AFAIK set the default engine to google, google has no need to pay any effort wooing the firefox devs/users.
To put it another way, if you were going to provide a high-level string API for C and tell programmers "never ever manipulate strings on your own; use this library," then you might as well use NUL-terminated strings anyway, since the library will handle it, and programmers will never make a mistake. But again, that would be very un-C-like.
So once again, it comes down to this: NUL-terminated strings aren't the problem with C. C is the problem with C: the fact that it gives programmers a lot of power. You might argue that we should stop using C to write programs that don't need that speed or power. But there's no point arguing that C should have been a higher-level language, because then it wouldn't be C.
If you had a mistake-less library, you wouldn't want it nul-terminated. It makes certain simple operations like strlen() take more than constant time, for example. The better implementation for performance is length+data, every time.
Is it, or are you just used to dealing with NUL-terminated strings?
Nope, they are simpler. Re-read all of the questions I asked regarding design decisions that could be made around address+length formatted strings and tell me that they are just as simple. Now I think higher-level languages should be using lengths, because their libraries abstract the details (e.g., C++ or Java). But in a language where programmers fabricate their own strings, simplicity is best.
They are simpler IFF you never use the null value. Do you have any files on your system which have NUL bytes in them? Hint: yes. See for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574104 . I would actually argue that the additional complexity in the design of the address+length formatted strings would wind up resulting in simpler code because with a good system library implementing it, nobody would ever be tempted to just do it themselves. C might be a low level language, but that doesn't mean every wheel has to be reinvented over and over again.
As for your example of concatenating 3 strings: of course you can copy it yourself without a stringstream or StringBuffer or what have you. Just make yourself a string of the right size, then fill the byte ranges by hand.
string concat (string a, string b, string c) {
string ret = strnew( strlen(a)+strlen(b)+strlen(c) );
strfill(ret, 0, a);
strfill(ret, strlen(a), b);
strfill(ret, strlen(a)+strlen(b), c);
return ret; }
Dealing with NUL is significantly simpler than dealing with length fields, and there are significantly fewer sources for confusion.
Is it, or are you just used to dealing with NUL-terminated strings?
If you wanted the standard to use a variable-length length as you suggest, you would need to make sure that all the programmers correctly store and parse variable-length strings. Of course they could get it right, but there are lots of ways they could get it wrong.
That's what libraries are for:-)
Here's a question: How much memory do you allocate for a string of N bytes? The NUL-termination answer: N + 1. The answer for your mysql variable-length length scheme: N + (N < 128 ? 1 : N < 16384 ? 2 : N < 2097152 ? 3 :.....) -- yes there is a correct answer, but it is much more complicated for the everyday programmer to deal with.
Again I say: libc.
I think the state of programming is so bad now that people wouldn't test it. A major security bug in Blowfish was just found last month caused precisely because of a signed/unsigned char mismatch.
Heh, a fair point. But if string handling is done in a library by the developer of the OS, and they don't get it right, nobody's going to buy their OS. "Joe average" programmer doesn't have to do it at all, they just call the moral equivalent of strlen(), strdup(), strchr(), strbrk() etc.
What is so undesirable about making a string larger than a pointer?
Also, have a look at how mysql deals with varchars. There is no 255 byte limit - when length exceeds that value, you just go to 2 bytes of length, etc. Your arguments about what type of integer to use conveniently ignore conventions like network order. In short, it is not too hard to solve. Do you really think the state of programming was so bad back then that people wouldn't test 129 byte strings?
And no, the article didn't miss the "real security problems" caused by null termination. Where did you stop reading?
Slashdot Mirror
Not so much if you RTFA. Verizon seems much more interested in grabbing new slices of wireless spectrum from the Government.
Are they initialisms, though? Do you read "FTFA" as "eff tee eff ay" or "from the f*king article" ? Most people I know do the latter, which means its not an initialism either.
Hm, why do you think we haven't evolved with perfect memory? Could there be a good reason?
Unless you believe in intelligent design, there may be no reason at all ... As my old bio teacher used to intone, "evolution proceeds towards what works, not what's best."
Intelligent design has nothing to do with it. Your assertion is that we don't have capabilities like this because we haven't needed them enough yet? Isn't it possible that such things (like being able to go without oxygen for a long time) would involve too significant a cost for the rare cases it would be needed and therefore is not worth the tradeoff?
citation needed.
I don't want to sound conspiratorial, but the trajectory the plane took makes no sense to me. In an airshow you always stay in a designated zone on the other side of a runway from the crowd. The other planes earlier in the video were clearly in that zone. The plane that crashed was coming in at a very steep angle - probably more than 70 degrees - and from what I can tell in the video, he was moving *away* from the bleachers towards the acrobatic zone. You're not ever supposed to be over the crowd like that or take a trajectory that crosses above the crowd, even at substantial altitude. How did this happen?
The potential of crashes is indeed part of the point. But in general people prefer the thrill to be derived from those engaged in the pursuit risking their lives, not those in the audience. Messed up, but true.
It seems to be taken as a given in this document that Javascript is unusable.... But there is no explanation of why this is the case (except perhaps for google's business needs) - what exactly is the problem with it? Performance is quite good these days thanks in large part to google's chrome folks. Few languages are easier to use, but it is still quite powerful.
Doing a full reboot followed immediately by a suspend is nothing like this approach. What are you on about?
Actually, T-mobile will be in pretty decent shape if the merger with AT&T doesn't go through - they get $3 billion in such a circumstance. As for the iPhone, that's also wrong - until the Verizon iPhone came out, the carrier with the second largest number of iPhones was T-mobile (hacked and 3G less, but still paying T-mobile).
So, umm, yeah. Your two main premises are either completely wrong or seriously flawed.
A network tap doesn't involve the layers sitting on top of it.
Not really. IPX/SPX were really only designed for LANs. They don't deal with latency, lost packets, etc. anywhere near as gracefully as TCP/IP does.
clearly the main advantage of objects is subjective.
It's a game of chicken, where Google says, ok, lay off my pals that are making Android phones, or you have to sue, us, too-- and you don't REALLY want to do that, do you?
Why on earth would anyone be forced to sue Google if they didn't want to?
FTA: "I would have loved the opportunity to convey a few misunderstandings about me." Nothing to see here, move along.
The sandboxing on NaCl actually is relatively incredible. Only a modified subset of x86/amd64/arm is executed - potentially unsafe instructions are not. It's actually a lot like (para)virtualization. Read about it:
http://en.wikipedia.org/wiki/Google_Native_Client
http://code.google.com/chrome/nativeclient/faq.html#PreventBreakouts
Java and C#, which are considered 'fast enough'.
Not for games or video processing.
+1. To say Google "needs" Firefox is just ludicrous.
Google benefits from Firefox. Google wants Firefox traffic. But since Firefox has always AFAIK set the default engine to google, google has no need to pay any effort wooing the firefox devs/users.
If you had a mistake-less library, you wouldn't want it nul-terminated. It makes certain simple operations like strlen() take more than constant time, for example. The better implementation for performance is length+data, every time.
Nope, they are simpler. Re-read all of the questions I asked regarding design decisions that could be made around address+length formatted strings and tell me that they are just as simple. Now I think higher-level languages should be using lengths, because their libraries abstract the details (e.g., C++ or Java). But in a language where programmers fabricate their own strings, simplicity is best.
They are simpler IFF you never use the null value. Do you have any files on your system which have NUL bytes in them? Hint: yes. See for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574104 . I would actually argue that the additional complexity in the design of the address+length formatted strings would wind up resulting in simpler code because with a good system library implementing it, nobody would ever be tempted to just do it themselves. C might be a low level language, but that doesn't mean every wheel has to be reinvented over and over again.
As for your example of concatenating 3 strings: of course you can copy it yourself without a stringstream or StringBuffer or what have you. Just make yourself a string of the right size, then fill the byte ranges by hand.
string concat (string a, string b, string c) {
string ret = strnew( strlen(a)+strlen(b)+strlen(c) );
strfill(ret, 0, a);
strfill(ret, strlen(a), b);
strfill(ret, strlen(a)+strlen(b), c);
return ret;
}
What's so hard about that?
Is it, or are you just used to dealing with NUL-terminated strings?
That's what libraries are for :-)
Again I say: libc.
Heh, a fair point. But if string handling is done in a library by the developer of the OS, and they don't get it right, nobody's going to buy their OS. "Joe average" programmer doesn't have to do it at all, they just call the moral equivalent of strlen(), strdup(), strchr(), strbrk() etc.
Sigh... mysql's varchar is just one example of breaking the 255 byte "limit". There are limitless ways to do this. See for example http://en.wikipedia.org/wiki/Variable-length_quantity
What is so undesirable about making a string larger than a pointer?
Also, have a look at how mysql deals with varchars. There is no 255 byte limit - when length exceeds that value, you just go to 2 bytes of length, etc. Your arguments about what type of integer to use conveniently ignore conventions like network order. In short, it is not too hard to solve. Do you really think the state of programming was so bad back then that people wouldn't test 129 byte strings?
And no, the article didn't miss the "real security problems" caused by null termination. Where did you stop reading?
The misleading summary helps, too.
Okay, I'll bite. Which 20 year old unpatched kernel are you running? Or are you just talking about linux?
I see no 404. http://distributed.net/ try again.