So, write code, compile and run, ship it, but don't bother to check it?
I read my own programs and tweak the code, the formatting, and the comments. I find more bugs that way than by testing. Testing is a very bad way to find bugs. Letting a few million web sites find the critical bugs is even worse.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation
Most facebook stuff is friends and family, people who know one another.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation
Even a bar in Thailand?...
Tim
-- Seven Transistor Labs Electrical Engineering Consultation Website: http://seventransistorlabs.com
Think of it as an interstate, or trans-continential bar, where all your friends and family hang out on a Saturday night. It's not just strangers. My wife keeps me up on all of the nieces, nephews, their kids, and friends in a dozen states.
I don't do Facebook or Twitter, but I'd rather do that than talk on the phone. I'd prefer email but that doesn't seem to interest the rest and I would miss the ancillary conversations. I see the point but I also agree that it's a little strange seeing some pretty private and personal things out there for anyone to see.
You don't do any of it but you know what everyone is saying. Well...
Step-thru debugger.
That is correct. Throughout my life I've noticed the most interesting people are the ones who are highly reluctant about discussing what they've done and what they plan to do. Those are precisely the kind of people I'd like to get to know, but they obviously won't go near Faecesbook, and so that's why I myself don't bother with it, never have and never will.
True, you could be talking to BIG BUBBA, in the pen, that just wants to love someone, anyone!
Jamie
Sure it is, and I bet the coder that worked on that section knew exactly what they were doing!
Jamie
Okay, age and race.
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Let me get this straight. You've never so much as talked to "those people", you have never talked to "those people", you have no interest in talking to "those people", yet in your mind you still know everything about "those people". There is a word for that attitude. "Bigot" comes to mind.
No, I don't want anything to do with Facebook, either, but not because of some scary "those people" who inhabit the "swamp".
At the time of its creation, both memory and CPU time were expensive. It wasn't practical to specify the language in a way that ensured bounds checking because of the memory and time costs involved.
Another common mistake - continuing to use freed memory - was even harder to address.
It would nice if all the application software exposed to the web were rewritten in a safe language, but that's not going to happen any time soon.
That said, anyone created a new web-exposed application would have to have their head examined if they wrote it in C or C++.
Sylvia.
Have they never been "inexpensive"?
This sort of malady has been known since the 60s at least, and bounds checking has been around since about the same time (e.g., when was BASIC introduced -- which AFAIK, always has bounds checking... at least when interpreted?). For God sakes, the 80186 even brought the BOUNDS instruction to x86. It goes unused to this day!
It doesn't help that C's [ASCII] "strings" are zero-terminated. Because they're just stupid arrays, and the standard libraries decided they should be treated in that way. Absolutely no necessity of doing it that way. Of all the dubious aspects of the language, that's one that should recieve the most ire. What a stupid idea. Other languages (I'm only familiar with QuickBasic offhand) store strings with a length prefix. And do bounds checking besides.
Here's another thought: Bad programmers want to be like good programmers. So they want their code to be fast. So they write ugly, terse code. They prematurely optimize. They settle on algorithms that are understandable. And they leave out security and sanity features, like bounds checking. Fully missing the fact that, good programmers achieve all of these goals (or at least strive to).
The same sort of logic that, say, a racecar driver might apply to remove the seatbelts -- saving a few pounds and eking out that last 0.02 second on the quarter mile or whatever.
The same focus on short-term gains that's destroying the rest of the world, not just software...
Tim
-- Seven Transistor Labs Electrical Engineering Consultation Website: http://seventransistorlabs.com
If the instruction is used, then it occupies memory space, and consumes CPU time. In the vast majority of cases, and indeed, in all correct programs, this is space and time wasted.
Bounds checking also implies that the compiler can determine the limits of the memory area being used. The simplest case, where the memory is an array whose declaration is visible to the compiler is easy to handle, but once parameters are involved, the implementation has to start passing descriptors around, and the bounds checking becomes even more expensive.
Back in the days of 640K PCs, this was an unaffordable luxury. These days, both the cost situation and the security environment have changed, so that one would prefer all programming to be done languages that do actually bear these costs.
It's not inherently unsafe, though anyone who's doing much string manipulation will tend to write functions for the purpose, if only to avoid mindlessly repetitive code.
However, 'C' was never designed for use by people who do not consider the security ramifications of what they're writing.
I think you're misstating that. The problem is not that the bad programmers are trying to be like good programmers, it's just that they don't see the possible ramifications of what they're doing. In the ranks of employed programmers, they may not give a stuff anyway - it's just a job.
This is not confined to the kind of mistake that can be made in 'C'. The number of times I've seen people construct SQL statements from input data without considering the possibility that the input data may contain syntactically significant characters (SQL insertion vulnerability).
So, yes, we should now be using safe languages, but we still need to manage the various levels of competence. This implies proper reviews of work, but it is expensive, and people frequently don't really understand the review process either. Even in environments where code review is part of the formal process, what comes out is frequently just nitpicking over variable naming and spelling.
Sylvia.
Corrected here with recently released corrected openssl. Bank checks out as well so it's all good. Linux, compiled the corrected software this A.M.
In the 1970's i wrote a lot of programs for 16 bit mini computers using FORTRAN IV, which only had tables and indexes, no pointers or character strings. At least some compilers had the option to generate run time index checks. This was usually employed during product development, but turned off in the shipped product.
FORTRAN IV did not have any string data type, so you had to write your own string library using byte arrays (or in the worst case integer arrays). It was as primitive as C. The only difference is that C provides ready made string subroutine library (strcpy etc.).
Fortran-77 integrated strings into the language. A similar integration was available only in C++, not in C.
Actually no you are wrong. The fault in this case lies in the Unix based OpenSSL and it was used by many banks and other corporate secure websites. Tools are available now to check if the dozy b*stards have fixed their sites and the only sensible thing to do is change your password(s) on all affected sites once they are secure again.
For once MickeySoft is not guilty. This was an entirely open source MFU!
A fair number of banks and other financial institutions have used this OpenSSL code to implement their "secure" https transactions.
-- Regards, Martin Brown
Security flaws like this are usually handled discretely at first. People who find a flaw report it to the developers (openssl in this case), and/or to Linux/BSD distributors (since it is used on such systems). Big sites such as google, facebook, banks, etc., have dedicated people who will track such information and get the fix in place in their systems. Then there will be public disclosure so that all the "small" people can see the problem and fix their servers, and so that end users can take appropriate precautions.
There is /no/ way to get the information to the multitudes of small site admins without also giving the information to the bad guys. But usually the big site admins get the information first, as do the upstream people
- so that when the small guys hear of the problem, they can just "apt-get update" to get a fixed version of the libraries.
Of course, sometimes people who find such flaws think it is more profitable to sell the information to the bad guys rather than report it to the developers. And sometimes people think it is better to be open about everything as soon as possible. But usually the bugs are reported to developers, and only revealed to the masses when the fix is in place (or when the vendors have failed to release a fix in a timely fashion).
declard buffers make for inflexible software.
immagine if your email program could only handle 20 attachments of
300K each because that was the buffer size, if sowmone wanted to send you an email with a 2M attachment you'd have to exit that program and run the version that supported 200k text and a 6M attachment,and if you upgraded your RAM you'de need to install a new operating system.
-- umop apisdn --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
since it's yahoo: DMARC
-- umop apisdn --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.