8-bit Atari had this neat mode, Graphics 8, which was a very high resolution monochrome mode. With the fun exception that 2 neighboring lit pixels were white, but a single pixel with no horizontal neighbors was reddish or greenish depending on position. Some games exploited it cleverly, for example Amaroute was mostly normal monochrome but the fence around the game area was red.
This is not about putting you in ice and letting you freeze to death. It's cryogenics: dumping enough LN2 fast enough to freeze the cells without exploding their walls (as ice water doesn't get to form macroscopic ice crystal structure), and essentially stopping your organism cold in its tracks. AFAIK there are no decay processes at LN2 temperatures, and the little amount of chemical reactions that still occur should not affect the outcome.
Theoretically, recovering the organism to its standard 36.6C should suffice to restore it; it is done with single-cell organisms successfully. But we don't have a technology to heat up a body of human volume fast enough and uniformly enough to achieve that. With freezing, it doesn't matter if one part of the body goes to 80K and another to 110K in 3 seconds. It does matter if your brain goes to 30C on the edges or to 50C in the center though. There's also a bunch of other unknowns but as long as we can't bring a mass of 70 or so kg of mostly water in irregular shape from 70K to 310K in 0.1s with precision of +-3K throughout the whole volume, they are moot.
There's also the other approach, neatly described in Transmetropolitan: far-future freezing. First off, you don't freeze the whole body, just the head. The body is buried. Second, you keep it long enough that nanotechnology gets developed that can rebuild an organism from scratch. A thousand years is not out of question. Next, the freezing damage gets repaired by nanobots, any damage so heavy that can't be rebuilt from existing tissue structure or DNA, gets rebuilt using "generic" data for "that genotype of a human". The rest of the body is rebuilt or regrown as a clone. Next you wake up and promptly die from culture shock. After which you are revived again and remain alienated from the society forever.
Oh, and all your fortune and savings were lost in the Great Depression and following Revolution of 2642.
Oh, but why? I guess I might be arrested for investigation, but since I have absolutely no connection, I should be released, shouldn't I?
Also, I'm willing to cooperate with the Law Enforcement completely, I just want due reimbursement for my hard work. Safety is safety, but I can't be deprived of my hard-earned money, can I? I mean, I'm not withholding any information, they can have it the minute $10mln is deposited in my account! I can even give them an invoice for it, and I will definitely pay the due tax!
I still believe a cell is performing a small set of relatively simple processes that affect the rest of the organism, except in a very complicated manner - they need to maintain, repair and power self primarily, on top of affecting others.
It would mean that we should be able to approximate a cell quite accurately with relatively simple model that is nothing like a cell internally but performs the same functions. Treat the cell as a black box, and replace it with a black box that behaves the same, but differs internally.
Still, to do that adequately, we need a 100% working (internally) model of a cell, which we can then begin to simplify in a way that doesn't affect the I/O.
The companies that depend on the programming theoreticians who know a hundred algorithms but no syntax to implement them, and know PROLOG better than C, tend to go under with the first problem in the market.
The companies that depend on a solid programming skill are more successful.
I worked at one of the latter kind. The unofficial guidelines were:
- make it so bulletproof that if 80% of the system goes down, the remaining 20% should still do its work just fine. Example: operating for a week from memory cache only is perfectly acceptable if the database went down and takes too long to be replaced. (so first check if new data can be obtained, only then expire the old). - write it in a way that makes understanding the code take less than write the documentation for it. Then don't write the developer documentation. Just user-side one, and only the needed content, no fluff. - make it so that it could run for years without maintenance, then run it without maintenance. When the need arises, a new developer will spend extra 2 hours researching the system before applying the (sometimes 5-minute) fix. It's still cheaper than to keep someone maintaining it over the whole period. - a system that does 90% of the job for 20% of the cost is better than one that does 100% of the job for 100% of the cost. A reboot once a week is cheaper than 6 days of developer's work eliminating all the leaks.
There were some side-effects. Some subsystems were written in 3 different variants independently, and coexisted, with no preference which is the right one. Some stuff was simply easier to write from scratch.
The funniest one was a lost portal. I mean, the company maintained some 200 different services, portals and so on. News, hobbies, some very generic, some very specific like a shop with projects of houses or an artists service. And one day someone asks on the company-wide "offtopic" list, which business unit "owns" [some URL]. It seems the service under that link is a strict duplicate of functionality of one of our more prestigious services, only much poorer in content and not updated in some 5 years (although the fora kept by the users and moderated by moderators who are a kingdom by themselves, are alive, with users asking their questions and other users answering.) Nobody admits, some research takes place - yes, there is the code base, not touched in well over 5 years, there are the tables in the database, yes, it is one of our services, fully functional, new articles can be posted at any time, generic and targetted ads get rotated, the mailing list accepts new subscribers even if no new newsletters are created, and the user database sees some 5 new users every week. And someone recalls... it was rewritten from scratch 5 years ago, the new version went online under a new address, and is our new flagship product, and the old one was to be scrapped a month later, except someone forgot to scrape it. And so, a forgotten ghost portal existed somewhere in the monstrosity, and worked for 5 years with nobody in the company ever noticing its existence.
Also, Slashdot just put this footnote on the bottom of the page: Kludge, n.: An ill-assorted collection of poorly-matching parts, forming a distressing whole. -- Jackson Granholm, "Datamation"
This is a possible solution but not a convenient one. It can store settings of one page at a time, not site-wide. The site in question was a portal with millions of pages. If you want it site-wide requires rewriting every single link on the site to include the data. Either server-side (you lose caching benefit) or client-side (some pretty clever javascript not to break stuff and not to skip anything. Links take many forms, A HREF, Submit, image maps, javascript redirects, meta redirects, all would have to be included). You must depend on the user bookmarking the data. A visit from outside would create the generic version of the page. On IE you'd be limited to some 200 printable characters of data (256 minus the actual URL). That's for a site with thousands if not millions of pages, hundreds of services with their own unique settings. Also, the user-side cache would go mostly unused; submitting data usually gets a fresh reply from the server. Server-side caches would have a difficult task too, and have to be heavily modified - pass generic content to people submitting their settings only while passing the actual form data (same looks) to the underlying dynamic scripts.
It's doable. In case of simple apps like Othello, it may be easier and better than cookies. But in case of huge portals it would be a pain in the ass beyond your worst nightmares.
Yes - we would be perfectly satisfied to plant the cookie in the user's browser and never see it back again. Making it readable by user-side javascript only would be perfectly satisfactory.
The only reason we need the cookie back is to prevent us from overwriting it with a new, blank one, but it could be done client-side too (deny the new cookie if old one is already present), except this is not how cookies behave - it would require extending the standard.)
It is not a very common case when two users behind one NAT access the same website around the same time. Thus treating the NAT wall as the origin address usually yields the good results.
There is still the way of dragging the session along in the GET method data all over the site. It's about as bad as all the rest (primarily all links must submit() ).
Server-side variables are primarily more work for the server, which has to re-run the script instead of informing the content didn't change and can be retrieved from the browser cache (and modified client-side according to the cookie).
Ask yourself; what can be accomplished with a cookie that can't be accomplished using alternative mechanisms.
Semi-permanently modifying the page to the user's desires without server-side intervention.
Yes, it can be done server-side, using IP tracking, login and so on. But they require actual CGI to run and generate content, instead of the HTTP layer spitting out "Cache HIT" on page content and static Javascript.
Users hate registration, and IP tracking is useless with dynamic IP (there are ISPs that change it once a hour). But even then, you just have to do server-side work that would be better done client-side simply because servers cost. I've been working with a big IT/Portal/News company that had a big farm of servers that was at 80-90% of its load at all times. If not cookies combined with tons of static content kept client-side in browser caches and in a squid layer protecting the farm, refreshing the content of each page maybe once in 15 minutes vs ~1000 hits/second, we'd have to maintain about 2-3 times as many servers. And that would move us from "quite profitable" to "generating losses".
Polls. On sites with thousands of clicks per second. The cookie is fast and dirty method of determining whether given user has already voted in the poll or not. To keep the results honest, the site keeps a database of IP numbers and ignores repeated votes of bots that ignore cookies or users who delete them, but for 99.9% of visitors the cookie is a perfectly adequate method and allows zero server-side intervention to distinguish between the content to be displayed (questions/results) and preliminary allowing of the vote.
I would like to recommend to you an interesting article.
The subject is a result of my study "Location, timer settings and defusing codes of explosive devices located in various public buildings of the City of Schenectady".
I'm convinced you would be very interested in the information contained therein. I am willing to sell you a copy of said article, but considering its literary and informational value, I estimate it to be worth $10mln.
Simultaneously I would like to state I have no connection with manufacturers of these devices nor people who planted them. This is merely an scientific work of an informative study that should be of interest to all citizens of the city.
I strongly disagree. In fact, you likely use local pointer variables in small functions all the time. Whenever you pass a string as an argument to a function (even if it's a wrapper class like std::string)
Agreed, I overlooked the cases where you don't use explicite 'int *x' but pointers hidden behind "" or std::string.
If your pointer is on stack or heap, you'll have to fetch it into a register to dereference it regardless of whether the language is checking or unchecking (because there's no way to do double indirection in a single instruction). The only overhead for checking implementation are the checks themselves.
Yes, but including identifying, finding and fetching the limits.
Because you just loaded a chunk of code or data at runtime? Think loading and binding a.so/DLL file and calling its data structures from the parent program.
I understand that symbols will have to be resolved when loading a shared library. But this happens regardless of checked/unchecked nature of the language used by the library or the calling code. So, I repeat the question: can you name a single language implementation with array bound checking that uses some kind of symbol lookup to determine when it needs to do the checks?
Sure it does, but checking requires separate lookups or at the very least fetching extra metadata.
As for languages... how is it done in Perl? As I understand it, it is compiled to C as an intermediate step, which doesn't support it natively, so it makes the checks way longer than a few ASM instructions...
About everything that can do both eval() and the checking, will work in a similar way.
If you're checking an array index, why convert it to pointer and then check range of that pointer? It's much easier to just check the index against length - and that's one unsigned comparison, if your arrays are always 0-based.
Pointer in range: - obtain pointer - obtain bottom - obtain top - compare bottom - compare top. - dereference.
Array in bounds: - obtain index - obtain pointer - obtain length - compare length - add index to pointer for dereferencing. - dereference.
Same complexity, the extra steps just occur elsewhere. Of course in the array case, the addition is unskippable in case of non-checking.
It's not the most optimistic case. Compilers for checked languages are often smart enough to figure out when bounds do not need to be checked, because there's no way an index can be out of bounds at this point (e.g. it was checked earlier and not changed since; or we're in a loop with counter from 0 to array length).
Agreed, but Murphy Never Sleeps. You may argue the situation is better than I painted it, but you can't argue my points are completely moot.
In any case, my point was that it's definitely not 20x that you've originally implied. I'm not arguing that there is no perf hit from checks at all (that is obviously false), just that it's not as big.
I concede... in case of optimized compilers. If you take the Perl's example... sure it's not just the checking. There are the soft types, there is a lot of other stuff, but for my case it was about 30x slower than C. I'm pretty sure Java doesn't get it in 9 CPU instructions either.
How large is the overhead? Well, I only know Win32 exceptions closely, and for those the record is really just two pointers, one of which is the handler function (which gets called on any exception, and handles all cleanup inside itself), and the second is a pointer to the next record. Setting that up is 3 instructions - two PUSH to create the record on the stack, and one MOV to store its pointer in a predefined thread-local variable where the OS can find it. Tearing it down is 2 instructions (POP old pointer and MOV it to thread-local).
err... push-pop count doesn't match for me, what am I missing?
But MSIE -IS- (or was until quite recently?) the generic Win32 ActiveX "Web Browser" control plus a wrapper GUI application (or if you prefer, a web browser application with the ActiveX "Web Browser" control at its core).
Who is to say the listing doesn't include all exploits that affect said one single generic ActiveX control from whichever wrapper/browser it was called under a common class "ActiveX" and lists MSIE only for exploits that are MSIE-specific?
I saw a Secuina list similar to today's the other day. It listed counts per browser and per browser subsystem. MSIE was the worst, with ActiveX exploits comprising some 80% of its count. The count [MSIE (whole)] and [MSIE(whole) minus (MSIE->ActiveX)] looked strikingly similar to this article's [MSIE + ActiveX] and [MSIE alone] respectively, here.
I'm not skipping anything. If both x and p in your examples are locals that are mapped to registers directly (quite likely for a small function), then it will be something like:
mov eax, [ebx]
If both variables are true locals on the stack, it would be something like:
You rarely need to use local pointer variables in small self-contained functions. Usually they will be on the stack or somewhere in the memory unless you just fetched one for current use and are reusing it a line below. [non-checking 3] Anyway, in a checking language variant you may need to fetch the pointer before you start retrieving its data or checking its validity. So, one likely MOV. [1]
I do not understand this at all. Why would I need to determine this kind of thing at runtime, and why in particular does it have to be done via some lookup table? Can you point out at any compiled language that actually does that?
Because you just loaded a chunk of code or data at runtime? Think loading and binding a.so/DLL file and calling its data structures from the parent program. Of course, in an optimistic and very common variant the compiler will do that for you at compile time. [2]
In most languages today you only have one border to retrieve, as the other one is 0 (and you already have pointer to start). If you have a pointer to array in a register already (in a loop over said array, you will), retrieving length is one MOV. If you're checking for NULL... If you protect separate chunks of allocated space, you need both ends. If you use an array, you have the pointer to beginning and the index, you had to get both from somewhere earlier. You don't need to check for negative index but you still have to add it to the pointer for dereference if you retrieved length, or for comparison if you retrieved end pointer. [2]
Compare with current index value, conditional jump. 2-4 instructions. That's precisely 2 instructions (CMP/JGE), I've no idea where you get 4 here.
Ok, [2].
If both array and index are in registers (again, highly likely in a loop over array), retrieving a value and storing in a register is a single MOV. Storing in memory is one more. - so we agree here. [2]
So, the pessimistic count is 9 instructions in the branch that ends successfully vs pessimistic 3 and optimistic 1 in non-checking language. That is still assuming you didn't run short on registers and don't need to juggle some stuff out to stack - instead of 1 register we're using how many? 3? 4? And that may hurt our performance once again because we need to overwrite some unrelated variable stored in a register now and fetch it back again later, while it could have survived the whole operation in an unused register untouched.
Not really. This branch would just call a function that throws the exception, so it's a single CALL.
Abusing the stack by a CALL you never intend to return from to store the address of where it happened on the stack for later use? Okay... hackish but acceptable. Anyway, exception usually gathers some more info about where and why it happened to know how much has to be removed from stack from the context that just died. That info would have to be stored prior to the jump. I don't know exactly how much data is needed to collect all the leftover garbage resulting from interruption (in non-garbage-collecting language), but as I understand it, it's no trivial matter.
The problem is defining -what- is your civil right and what is just a fancy. Is owning a dog a civil right? Is marriage a legal right? Noting that it's an entirely artificial legal construct which doesn't change anything physically.
How wrong would it be to separate "marriage" being a simple declaration of pairing a couple from "mutual commonwealth" which would introduce all the economic/legal effects of current marriage without declaring the two people anything else than bound by an economic contract? In this case, "mutual commonwealth" would introduce entirely nondiscriminatory legal way to have gay couples share a bank account, visit one another in hospital, pay taxes together, without affecting the religious feelings of the straight; a separation of the country from the church. And then, gays who still want to be wed, could seek a religion that would allow that just fine, and be recognized to be wed in light of this religion, completely separately from material and legal commonwealth and completely separately from the christian concept of marriage.
In this way, you'd give them a -civil- right to all the benefits of a marriage without the marriage itself, while cutting them off from -religious- concept of marriage which is neither subject nor interest of the law, other than freedom of faith with as discriminatory and as unfair concepts concerning abstract constructs of the faith as they only desire, except with no real discriminatory impact on the physical world and the actual laws.
On top of that, as much as freedom to believe whatever you wish should be protected, "offending religious feelings" should be dealt with Canonical law of said religion, to the extent allowed by common law, that is they could declare you condemned to hell and exclude you from religious community, but couldn't sue you for money.
In other words, I should be able to tell you you will go to hell because you are black, but I can't deny you work for that. And you can laugh at me saying hell doesn't exist, or go to my bishop to excommunicate me for not loving my black brother, but you can't sue me for damages resulting from discrimination.
You're skipping important parts like obtaining the pointer value from wherever it's found, storing the result where it will be used ( {*p;} alone is pretty much useless, you usually need some {x = *p;} - you could claim it's dereference plus assignment, I claim it's the smallest piece of code that makes sense).
As for checking for overflow, 1) look up which array this is - if it's local or statically linked, it could be done by preprocessor, but if it's dynamically linked, you need a lookup table. Symbol to pointer lookup - some 1-2 instructions. 2) Find and retrieve its border conditions (increment pointers, store values in registers), 4 or so instructions. 4) Compare with current index value, conditional jump. 2-4 instructions. 5) branch A - check ok. Retrieve/store the value. 1-2 instructions. Done. 6) branch B - handle the exception. Probably preparing the exception data alone will take some 10 instructions (where, which exception, all the metadata), then comes the generic code of the exception.
Of course the optimistic case reduces the amount of instructions executed to 3-5 or so, but the actual code will be much longer than that, except just single branches of it will be executed, and the pesimistic case will have 20 or more instructions to run through.
Nevertheless, even if little code gets executed on normal run, the exceptional condition will increase the size of the program including the whole 'failure' branch for every possible fault condition and while CPU usage will climb just a little, RAM and diskspace requirements skyrocket.
ActiveX is listed separately? Yay, that explains why MSIE fares so well.
MSIE is a rather simple GUI built around the ActiveX HTML Browser control ("Trident" engine). So the exploits that affect all browsers that use it (IE, FF+IE Frame, Netscape, Maxthon, and a bunch of others) are simply listed as ActiveX exploits.Only exploits that are dependent on MSIE GUI layer are counted as MSIE ones.
It's like they counted only XUL interface exploits for Firefox, treating Gecko rendering engine as a separate system with its own list, not affecting Firefox.
They wake up slowly. If they've been dreaming about getting threatened, they might bite whoever woke them up before reorienting in the situation.
They are very patient but they snap rapidly. An abused rottweiler will withstand the abuse quietly for a long time, then finally snap and attack seemingly without warning and all overdue aggression, while other dog would growl and warn long before.
They have a pretty sensitive psyche. It's easy to make a murderer dog out of one, and then getting it back to normal is nearly impossible.
But that is just a basic knowledge every rottweiler owner should have. It's way easier to learn than what is needed for driver's license and way less dangerous than driving a car too. But there is some basic level of responsibility and knowledge required... and some lack it, which hurts all.
When it's one on one, the choices are pretty clear cut.
It becomes more mulled when it's unbalanced: major freedoms of few for minor securities of many, or minor freedoms of many for major securities of few.
The dog owners are a minority. The dogs are for them an important part of their lives. The people who are afraid of dangerous breeds are a majority. This is a mere anxiety for them, usually baseless too, only in rare cases reasonable.
Now is it fair to take an important part of lives of few to satisfy minor anxieties of many?
I feel a lot of scum being abusive and rude to women, threatening to rape them as well.
I have two rottweilers. They are spoilt rotten sweet couch potatoes. If a thief broke into our house they would LICK him to death. They've been brought up with a lot of love and they don't have a clue what aggression is. But despite that they are OMG ROTTWEILERS TAKE THESE MURDERER DOGS AWAY FROM ME!
Maybe we should tackle the actual problem, not the overgeneralization?
I could see it as a 'system' language as in 'write applications in it'.
Not scripts, not embedded functionalities, not CGI, and no, not servers. Just a typical "double click to start" applications that you install on your desktop computer, which serve a thousand various purposes. The kind of stuff you write in Delphi or Visual C++. Fast and easy to write, fast and easy to run. Not too far from the OS to require squeezing through 50 abstraction layers, not too raw to bother with kernel routine calls to do basic stuff. Not too abstract and high level to slow it down to a crawl like Ruby, not too low-level to be overly dangerous like C.
It's placed somewhere between C and C++ on the "level highness" scale, doing some things that were long overdue in C++ natively, but not compromising performance for stuff like advanced inheritance, exception handling and such.
Slashdot Mirror
I wonder if they do Artifacting well enough.
8-bit Atari had this neat mode, Graphics 8, which was a very high resolution monochrome mode. With the fun exception that 2 neighboring lit pixels were white, but a single pixel with no horizontal neighbors was reddish or greenish depending on position. Some games exploited it cleverly, for example Amaroute was mostly normal monochrome but the fence around the game area was red.
This is not about putting you in ice and letting you freeze to death. It's cryogenics: dumping enough LN2 fast enough to freeze the cells without exploding their walls (as ice water doesn't get to form macroscopic ice crystal structure), and essentially stopping your organism cold in its tracks. AFAIK there are no decay processes at LN2 temperatures, and the little amount of chemical reactions that still occur should not affect the outcome.
Theoretically, recovering the organism to its standard 36.6C should suffice to restore it; it is done with single-cell organisms successfully. But we don't have a technology to heat up a body of human volume fast enough and uniformly enough to achieve that. With freezing, it doesn't matter if one part of the body goes to 80K and another to 110K in 3 seconds. It does matter if your brain goes to 30C on the edges or to 50C in the center though. There's also a bunch of other unknowns but as long as we can't bring a mass of 70 or so kg of mostly water in irregular shape from 70K to 310K in 0.1s with precision of +-3K throughout the whole volume, they are moot.
There's also the other approach, neatly described in Transmetropolitan: far-future freezing.
First off, you don't freeze the whole body, just the head. The body is buried.
Second, you keep it long enough that nanotechnology gets developed that can rebuild an organism from scratch. A thousand years is not out of question.
Next, the freezing damage gets repaired by nanobots, any damage so heavy that can't be rebuilt from existing tissue structure or DNA, gets rebuilt using "generic" data for "that genotype of a human". The rest of the body is rebuilt or regrown as a clone.
Next you wake up and promptly die from culture shock. After which you are revived again and remain alienated from the society forever.
Oh, and all your fortune and savings were lost in the Great Depression and following Revolution of 2642.
Buy a campaign of competitor's product using this technology to advertize it.
Massive profit.
Oh, but why?
I guess I might be arrested for investigation, but since I have absolutely no connection, I should be released, shouldn't I?
Also, I'm willing to cooperate with the Law Enforcement completely, I just want due reimbursement for my hard work. Safety is safety, but I can't be deprived of my hard-earned money, can I? I mean, I'm not withholding any information, they can have it the minute $10mln is deposited in my account! I can even give them an invoice for it, and I will definitely pay the due tax!
I still believe a cell is performing a small set of relatively simple processes that affect the rest of the organism, except in a very complicated manner - they need to maintain, repair and power self primarily, on top of affecting others.
It would mean that we should be able to approximate a cell quite accurately with relatively simple model that is nothing like a cell internally but performs the same functions. Treat the cell as a black box, and replace it with a black box that behaves the same, but differs internally.
Still, to do that adequately, we need a 100% working (internally) model of a cell, which we can then begin to simplify in a way that doesn't affect the I/O.
The companies that depend on the programming theoreticians who know a hundred algorithms but no syntax to implement them, and know PROLOG better than C, tend to go under with the first problem in the market.
The companies that depend on a solid programming skill are more successful.
I worked at one of the latter kind. The unofficial guidelines were:
- make it so bulletproof that if 80% of the system goes down, the remaining 20% should still do its work just fine. Example: operating for a week from memory cache only is perfectly acceptable if the database went down and takes too long to be replaced. (so first check if new data can be obtained, only then expire the old).
- write it in a way that makes understanding the code take less than write the documentation for it. Then don't write the developer documentation. Just user-side one, and only the needed content, no fluff.
- make it so that it could run for years without maintenance, then run it without maintenance. When the need arises, a new developer will spend extra 2 hours researching the system before applying the (sometimes 5-minute) fix. It's still cheaper than to keep someone maintaining it over the whole period.
- a system that does 90% of the job for 20% of the cost is better than one that does 100% of the job for 100% of the cost. A reboot once a week is cheaper than 6 days of developer's work eliminating all the leaks.
There were some side-effects. Some subsystems were written in 3 different variants independently, and coexisted, with no preference which is the right one. Some stuff was simply easier to write from scratch.
The funniest one was a lost portal. I mean, the company maintained some 200 different services, portals and so on. News, hobbies, some very generic, some very specific like a shop with projects of houses or an artists service. And one day someone asks on the company-wide "offtopic" list, which business unit "owns" [some URL]. It seems the service under that link is a strict duplicate of functionality of one of our more prestigious services, only much poorer in content and not updated in some 5 years (although the fora kept by the users and moderated by moderators who are a kingdom by themselves, are alive, with users asking their questions and other users answering.) Nobody admits, some research takes place - yes, there is the code base, not touched in well over 5 years, there are the tables in the database, yes, it is one of our services, fully functional, new articles can be posted at any time, generic and targetted ads get rotated, the mailing list accepts new subscribers even if no new newsletters are created, and the user database sees some 5 new users every week. And someone recalls... it was rewritten from scratch 5 years ago, the new version went online under a new address, and is our new flagship product, and the old one was to be scrapped a month later, except someone forgot to scrape it. And so, a forgotten ghost portal existed somewhere in the monstrosity, and worked for 5 years with nobody in the company ever noticing its existence.
Also, Slashdot just put this footnote on the bottom of the page:
Kludge, n.: An ill-assorted collection of poorly-matching parts, forming a distressing whole.
-- Jackson Granholm, "Datamation"
This is a possible solution but not a convenient one.
It can store settings of one page at a time, not site-wide. The site in question was a portal with millions of pages.
If you want it site-wide requires rewriting every single link on the site to include the data. Either server-side (you lose caching benefit) or client-side (some pretty clever javascript not to break stuff and not to skip anything. Links take many forms, A HREF, Submit, image maps, javascript redirects, meta redirects, all would have to be included).
You must depend on the user bookmarking the data. A visit from outside would create the generic version of the page.
On IE you'd be limited to some 200 printable characters of data (256 minus the actual URL). That's for a site with thousands if not millions of pages, hundreds of services with their own unique settings.
Also, the user-side cache would go mostly unused; submitting data usually gets a fresh reply from the server. Server-side caches would have a difficult task too, and have to be heavily modified - pass generic content to people submitting their settings only while passing the actual form data (same looks) to the underlying dynamic scripts.
It's doable. In case of simple apps like Othello, it may be easier and better than cookies. But in case of huge portals it would be a pain in the ass beyond your worst nightmares.
Yes - we would be perfectly satisfied to plant the cookie in the user's browser and never see it back again. Making it readable by user-side javascript only would be perfectly satisfactory.
The only reason we need the cookie back is to prevent us from overwriting it with a new, blank one, but it could be done client-side too (deny the new cookie if old one is already present), except this is not how cookies behave - it would require extending the standard.)
It is not a very common case when two users behind one NAT access the same website around the same time. Thus treating the NAT wall as the origin address usually yields the good results.
There is still the way of dragging the session along in the GET method data all over the site. It's about as bad as all the rest (primarily all links must submit() ).
Server-side variables are primarily more work for the server, which has to re-run the script instead of informing the content didn't change and can be retrieved from the browser cache (and modified client-side according to the cookie).
Ask yourself; what can be accomplished with a cookie that can't be accomplished using alternative mechanisms.
Semi-permanently modifying the page to the user's desires without server-side intervention.
Yes, it can be done server-side, using IP tracking, login and so on. But they require actual CGI to run and generate content, instead of the HTTP layer spitting out "Cache HIT" on page content and static Javascript.
Users hate registration, and IP tracking is useless with dynamic IP (there are ISPs that change it once a hour). But even then, you just have to do server-side work that would be better done client-side simply because servers cost. I've been working with a big IT/Portal/News company that had a big farm of servers that was at 80-90% of its load at all times. If not cookies combined with tons of static content kept client-side in browser caches and in a squid layer protecting the farm, refreshing the content of each page maybe once in 15 minutes vs ~1000 hits/second, we'd have to maintain about 2-3 times as many servers. And that would move us from "quite profitable" to "generating losses".
Polls.
On sites with thousands of clicks per second.
The cookie is fast and dirty method of determining whether given user has already voted in the poll or not.
To keep the results honest, the site keeps a database of IP numbers and ignores repeated votes of bots that ignore cookies or users who delete them, but for 99.9% of visitors the cookie is a perfectly adequate method and allows zero server-side intervention to distinguish between the content to be displayed (questions/results) and preliminary allowing of the vote.
Bill available for free:
every citizen must pay special tax of $1000
Bill available for a fee of $200:
Exempt from paying the tax are...
Dear City Council of Schenectady
I would like to recommend to you an interesting article.
The subject is a result of my study "Location, timer settings and defusing codes of explosive devices located in various public buildings of the City of Schenectady".
I'm convinced you would be very interested in the information contained therein. I am willing to sell you a copy of said article, but considering its literary and informational value, I estimate it to be worth $10mln.
Simultaneously I would like to state I have no connection with manufacturers of these devices nor people who planted them. This is merely an scientific work of an informative study that should be of interest to all citizens of the city.
Faithfully, yours, ...
I strongly disagree. In fact, you likely use local pointer variables in small functions all the time. Whenever you pass a string as an argument to a function (even if it's a wrapper class like std::string)
Agreed, I overlooked the cases where you don't use explicite 'int *x' but pointers hidden behind "" or std::string.
If your pointer is on stack or heap, you'll have to fetch it into a register to dereference it regardless of whether the language is checking or unchecking (because there's no way to do double indirection in a single instruction). The only overhead for checking implementation are the checks themselves.
Yes, but including identifying, finding and fetching the limits.
Because you just loaded a chunk of code or data at runtime? Think loading and binding a .so/DLL file and calling its data structures from the parent program.
I understand that symbols will have to be resolved when loading a shared library. But this happens regardless of checked/unchecked nature of the language used by the library or the calling code. So, I repeat the question: can you name a single language implementation with array bound checking that uses some kind of symbol lookup to determine when it needs to do the checks?
Sure it does, but checking requires separate lookups or at the very least fetching extra metadata.
As for languages... how is it done in Perl? As I understand it, it is compiled to C as an intermediate step, which doesn't support it natively, so it makes the checks way longer than a few ASM instructions...
About everything that can do both eval() and the checking, will work in a similar way.
If you're checking an array index, why convert it to pointer and then check range of that pointer? It's much easier to just check the index against length - and that's one unsigned comparison, if your arrays are always 0-based.
Pointer in range:
- obtain pointer
- obtain bottom
- obtain top
- compare bottom
- compare top.
- dereference.
Array in bounds:
- obtain index
- obtain pointer
- obtain length
- compare length
- add index to pointer for dereferencing.
- dereference.
Same complexity, the extra steps just occur elsewhere.
Of course in the array case, the addition is unskippable in case of non-checking.
It's not the most optimistic case. Compilers for checked languages are often smart enough to figure out when bounds do not need to be checked, because there's no way an index can be out of bounds at this point (e.g. it was checked earlier and not changed since; or we're in a loop with counter from 0 to array length).
Agreed, but Murphy Never Sleeps. You may argue the situation is better than I painted it, but you can't argue my points are completely moot.
In any case, my point was that it's definitely not 20x that you've originally implied. I'm not arguing that there is no perf hit from checks at all (that is obviously false), just that it's not as big.
I concede... in case of optimized compilers.
If you take the Perl's example... sure it's not just the checking. There are the soft types, there is a lot of other stuff, but for my case it was about 30x slower than C. I'm pretty sure Java doesn't get it in 9 CPU instructions either.
How large is the overhead? Well, I only know Win32 exceptions closely, and for those the record is really just two pointers, one of which is the handler function (which gets called on any exception, and handles all cleanup inside itself), and the second is a pointer to the next record. Setting that up is 3 instructions - two PUSH to create the record on the stack, and one MOV to store its pointer in a predefined thread-local variable where the OS can find it. Tearing it down is 2 instructions (POP old pointer and MOV it to thread-local).
err... push-pop count doesn't match for me, what am I missing?
But MSIE -IS- (or was until quite recently?) the generic Win32 ActiveX "Web Browser" control plus a wrapper GUI application (or if you prefer, a web browser application with the ActiveX "Web Browser" control at its core).
Who is to say the listing doesn't include all exploits that affect said one single generic ActiveX control from whichever wrapper/browser it was called under a common class "ActiveX" and lists MSIE only for exploits that are MSIE-specific?
I saw a Secuina list similar to today's the other day. It listed counts per browser and per browser subsystem. MSIE was the worst, with ActiveX exploits comprising some 80% of its count. The count [MSIE (whole)] and [MSIE(whole) minus (MSIE->ActiveX)] looked strikingly similar to this article's [MSIE + ActiveX] and [MSIE alone] respectively, here.
I'm not skipping anything. If both x and p in your examples are locals that are mapped to registers directly (quite likely for a small function), then it will be something like:
mov eax, [ebx]
If both variables are true locals on the stack, it would be something like:
mov ebx, [ebp+12]
mov eax, [ebx]
mov [ebp+16], eax
You rarely need to use local pointer variables in small self-contained functions. Usually they will be on the stack or somewhere in the memory unless you just fetched one for current use and are reusing it a line below.
[non-checking 3]
Anyway, in a checking language variant you may need to fetch the pointer before you start retrieving its data or checking its validity. So, one likely MOV. [1]
I do not understand this at all. Why would I need to determine this kind of thing at runtime, and why in particular does it have to be done via some lookup table? Can you point out at any compiled language that actually does that?
Because you just loaded a chunk of code or data at runtime? Think loading and binding a .so/DLL file and calling its data structures from the parent program. Of course, in an optimistic and very common variant the compiler will do that for you at compile time.
[2]
In most languages today you only have one border to retrieve, as the other one is 0 (and you already have pointer to start). If you have a pointer to array in a register already (in a loop over said array, you will), retrieving length is one MOV.
If you're checking for NULL... If you protect separate chunks of allocated space, you need both ends. If you use an array, you have the pointer to beginning and the index, you had to get both from somewhere earlier. You don't need to check for negative index but you still have to add it to the pointer for dereference if you retrieved length, or for comparison if you retrieved end pointer. [2]
Compare with current index value, conditional jump. 2-4 instructions.
That's precisely 2 instructions (CMP/JGE), I've no idea where you get 4 here.
Ok, [2].
If both array and index are in registers (again, highly likely in a loop over array), retrieving a value and storing in a register is a single MOV. Storing in memory is one more.
- so we agree here. [2]
So, the pessimistic count is 9 instructions in the branch that ends successfully vs pessimistic 3 and optimistic 1 in non-checking language. That is still assuming you didn't run short on registers and don't need to juggle some stuff out to stack - instead of 1 register we're using how many? 3? 4? And that may hurt our performance once again because we need to overwrite some unrelated variable stored in a register now and fetch it back again later, while it could have survived the whole operation in an unused register untouched.
Not really. This branch would just call a function that throws the exception, so it's a single CALL.
Abusing the stack by a CALL you never intend to return from to store the address of where it happened on the stack for later use? Okay... hackish but acceptable. Anyway, exception usually gathers some more info about where and why it happened to know how much has to be removed from stack from the context that just died. That info would have to be stored prior to the jump. I don't know exactly how much data is needed to collect all the leftover garbage resulting from interruption (in non-garbage-collecting language), but as I understand it, it's no trivial matter.
The problem is defining -what- is your civil right and what is just a fancy.
Is owning a dog a civil right?
Is marriage a legal right? Noting that it's an entirely artificial legal construct which doesn't change anything physically.
How wrong would it be to separate "marriage" being a simple declaration of pairing a couple from "mutual commonwealth" which would introduce all the economic/legal effects of current marriage without declaring the two people anything else than bound by an economic contract? In this case, "mutual commonwealth" would introduce entirely nondiscriminatory legal way to have gay couples share a bank account, visit one another in hospital, pay taxes together, without affecting the religious feelings of the straight; a separation of the country from the church. And then, gays who still want to be wed, could seek a religion that would allow that just fine, and be recognized to be wed in light of this religion, completely separately from material and legal commonwealth and completely separately from the christian concept of marriage.
In this way, you'd give them a -civil- right to all the benefits of a marriage without the marriage itself, while cutting them off from -religious- concept of marriage which is neither subject nor interest of the law, other than freedom of faith with as discriminatory and as unfair concepts concerning abstract constructs of the faith as they only desire, except with no real discriminatory impact on the physical world and the actual laws.
On top of that, as much as freedom to believe whatever you wish should be protected, "offending religious feelings" should be dealt with Canonical law of said religion, to the extent allowed by common law, that is they could declare you condemned to hell and exclude you from religious community, but couldn't sue you for money.
In other words, I should be able to tell you you will go to hell because you are black, but I can't deny you work for that. And you can laugh at me saying hell doesn't exist, or go to my bishop to excommunicate me for not loving my black brother, but you can't sue me for damages resulting from discrimination.
You're skipping important parts like obtaining the pointer value from wherever it's found, storing the result where it will be used ( {*p;} alone is pretty much useless, you usually need some {x = *p;} - you could claim it's dereference plus assignment, I claim it's the smallest piece of code that makes sense).
As for checking for overflow,
1) look up which array this is - if it's local or statically linked, it could be done by preprocessor, but if it's dynamically linked, you need a lookup table. Symbol to pointer lookup - some 1-2 instructions.
2) Find and retrieve its border conditions (increment pointers, store values in registers), 4 or so instructions.
4) Compare with current index value, conditional jump. 2-4 instructions.
5) branch A - check ok. Retrieve/store the value. 1-2 instructions. Done.
6) branch B - handle the exception. Probably preparing the exception data alone will take some 10 instructions (where, which exception, all the metadata), then comes the generic code of the exception.
Of course the optimistic case reduces the amount of instructions executed to 3-5 or so, but the actual code will be much longer than that, except just single branches of it will be executed, and the pesimistic case will have 20 or more instructions to run through.
Nevertheless, even if little code gets executed on normal run, the exceptional condition will increase the size of the program including the whole 'failure' branch for every possible fault condition and while CPU usage will climb just a little, RAM and diskspace requirements skyrocket.
ActiveX is listed separately? Yay, that explains why MSIE fares so well.
MSIE is a rather simple GUI built around the ActiveX HTML Browser control ("Trident" engine). So the exploits that affect all browsers that use it (IE, FF+IE Frame, Netscape, Maxthon, and a bunch of others) are simply listed as ActiveX exploits.Only exploits that are dependent on MSIE GUI layer are counted as MSIE ones.
It's like they counted only XUL interface exploits for Firefox, treating Gecko rendering engine as a separate system with its own list, not affecting Firefox.
Rottweilers do have their share of problems.
They wake up slowly. If they've been dreaming about getting threatened, they might bite whoever woke them up before reorienting in the situation.
They are very patient but they snap rapidly. An abused rottweiler will withstand the abuse quietly for a long time, then finally snap and attack seemingly without warning and all overdue aggression, while other dog would growl and warn long before.
They have a pretty sensitive psyche. It's easy to make a murderer dog out of one, and then getting it back to normal is nearly impossible.
But that is just a basic knowledge every rottweiler owner should have. It's way easier to learn than what is needed for driver's license and way less dangerous than driving a car too. But there is some basic level of responsibility and knowledge required... and some lack it, which hurts all.
When it's one on one, the choices are pretty clear cut.
It becomes more mulled when it's unbalanced: major freedoms of few for minor securities of many, or minor freedoms of many for major securities of few.
The dog owners are a minority. The dogs are for them an important part of their lives. The people who are afraid of dangerous breeds are a majority. This is a mere anxiety for them, usually baseless too, only in rare cases reasonable.
Now is it fair to take an important part of lives of few to satisfy minor anxieties of many?
I feel a lot of scum being abusive and rude to women, threatening to rape them as well.
I have two rottweilers. They are spoilt rotten sweet couch potatoes. If a thief broke into our house they would LICK him to death. They've been brought up with a lot of love and they don't have a clue what aggression is. But despite that they are OMG ROTTWEILERS TAKE THESE MURDERER DOGS AWAY FROM ME!
Maybe we should tackle the actual problem, not the overgeneralization?
I could see it as a 'system' language as in 'write applications in it'.
Not scripts, not embedded functionalities, not CGI, and no, not servers.
Just a typical "double click to start" applications that you install on your desktop computer, which serve a thousand various purposes. The kind of stuff you write in Delphi or Visual C++. Fast and easy to write, fast and easy to run. Not too far from the OS to require squeezing through 50 abstraction layers, not too raw to bother with kernel routine calls to do basic stuff. Not too abstract and high level to slow it down to a crawl like Ruby, not too low-level to be overly dangerous like C.
It's placed somewhere between C and C++ on the "level highness" scale, doing some things that were long overdue in C++ natively, but not compromising performance for stuff like advanced inheritance, exception handling and such.