●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Slashdot is powered by your submissions, so send in your scoop
Forgot your password?
Close
wnewsdaystalestupid
sightfulinterestingmaybe
cflamebaittrollredundantoverrated
vefunnyunderrated
podupeerror
×
1482199
story
Posted
by
Zonk
4, 2006 @01:15PM
from the good-practice dept.
Carl Bialik from WSJ writes "Many companies are teaching programmers to write safer code and test their security as software is built, not afterward, the Wall Street Journal reports. This stands in contrast to an earlier ethos to rush to beat rivals with new software, and, of course, brings tradeoffs: 'Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.' The WSJ focuses on RIM and Herb Little, its security director, who 'uses Coverity every night to scan the code turned in by engineers. The tool sends Mr. Little an email listing potential red flags. He figures out which problems are real and tracks down each offending programmer, who has to fix the flaw before moving on. Mr. Little has also ramped up security training and requires programmers to double-check each others' code more regularly.'"
Related Links
The Lost Gizmondo Halo Title
Generic Dungeons, Universal Dragons
This discussion has been archived.
No new comments can be posted.
Load All Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
byr_jensen11 ( 598210 ) writes:
Writers are encouraged to proofread.
twitter
facebook
byAcidTag ( 528338 ) writes:
The difference is that writing a paper that can stand a proof-read means it has one execution path, you read the article top to bottom and are done.
A program has any number of execution combinations, and without a decent test-harness some paths may not be checked. If ever piece of software written was tested in every concievable scenario we wouldnt have any bugs, when that day comes I'll be a happy coder. The more 'features' one adds to a program, the problems of detecting bugs increases. Simply creating
byorielbean ( 936271 ) writes:
This just in after that :
Business models sacrifice quality for speedy delivery of product. :-)
byAnonymous Coward writes:
No point you proofreading you own code. You see what you think you've written, not what you've actually written, therefore don't spot any problems with it.
The trick is to get 2-3 other people to review it.
1. The earlier you spot a defect, the cheaper it is to fix.
2. Test results are only as good as the test code written.
3. Edge cases don't normally show up in test code. Test cases are typically designed to show that the code works, rather than finding the boundary where it fails.
4. You can suggest better ways of writing the code/learn new tricks during code reviews.
Parent
twitter
facebook
bykcbrown ( 7426 ) writes:
No point you proofreading you own code. You see what you think you've written, not what you've actually written, therefore don't spot any problems with it.
Sometimes.
But sometimes, you dospot problems. I'll often spot errors in prose I've written here prior to submitting it. It's one of the reasons I use the "Preview" button (as shocking and unconventional as that may be). I don't necessarily catch everything, but I do catch a lot.
It's the same for coding. If I go over what I've written fi
bymattyrobinson69 ( 751521 ) writes:
Thats true, sometimes, if i'm having problems with an 'unfixable' bug, I get my non-programmer girlfriend to read through my code, she understands the basic, like every ( should have a ), every { should have a }, a { is not the same as a (., almost every line should end with a ; (presuming most lines have that), if she makes a mistake and thinks and if (a = b) { should have a ;, its no big deal.
She finds a fair few bugs that way. Like i said, she's not a programmer, far from it.
byishmalius ( 153450 ) writes:
I'm just so happy that a "Developer" article actually made the front page. I have been afraid that the tech level of the audience of Slashdot has been falling lately. Compare it to the number of "Game" articles on the front page.
But to stay with the topic, analysis tools are just that: tools. They are not a cure to chronic software problems. Developers are not excused from the responsibility of at least attempting to write quality code.
Some current project development methods really contribute to buggy and insecure code. Example: XP. I really think that some aspects of XP programming are a bad idea. Namely, the "code as fast as you can" aspect of it is fraught with errors. A more thoughtful, disciplined approach might seem like it is terribly slow. Yet being inherently less buggy, it can reach the target faster than the sloppier, more haphazard approach. This is much like the Tortoise and the Hare. Or maybe a better analogy would be like a rally driver who is more careful with his fuel and tires.
Don't get me wrong. Some parts of XP are fine. The Buddy System is an excellent way to get things done quickly by short-circuiting the collaboration cycle.
Parent
twitter
facebook
byhotsauce ( 514237 ) writes:
You should really read Unit Testing in Java: How the Tests Drive the Code [amazon.com]. XP is about small, direct steps, and when these are done with tests first, they greatly improve the quality of the code. You can draw all the big, fancy, pie-in-the-sky diagrams you want, and still get sloppy code.
bywickedj ( 652189 ) writes:
"Some parts of XP are fine."
Yes, I believe they've pretty much got Solitaire down.
bynietsch ( 112711 ) writes:
It is very nice that this bozo has a (very expensive I read) little program that tries to detect problems when they have already happened. So along comes mr friendly one day (or more?) after the fact to dicipline the programmer? That does not sound like a very positive approach to me.
If you want to learn someby something (I hope mr belittle does) it works much better if you have a quick feedback loop, react immediately when something is going wrong, not one weekend later when the programmer has all but forg
bymilimetric ( 840694 ) writes:
Revamping the software-development process creates a Catch 22 : being more careful can mean missing deadlines.
He keeps using that word. I do not think it means what he thinks it means.
bytcopeland ( 32225 ) * writes:
Static analysis is great stuff. I've worked on an open source Java static analysis tool, PMD [sf.net], for the past few years and I've gotten lots of feedback from folks who have used it to find all sorts of things in their code. Just a quick scan for unused variables can yield some excellent results, and the copy/paste detector works quite nicely too. And there's a book, too! [pmdapplied.com]
Coverity's doing a nice job with their tech marketing, too - l think a couple of open source projects are using the stuff they found to clean things up. At least, there's been a fair amount of traffic on the Ruby [ruby-lang.org] core list about some things Coverity's scan found. Good times...
twitter
facebook
byJonboy X ( 319895 ) writes:
Umm, about your comment: The link goes to a blog entry of yours about the inefficiency of using StringBuffer.append(String) to append a single-character string instead of just using StringBuffer.append(char). Sure, it's a good idea, but there's another kinda-orthogonal piece of advice that will likely improve runtime performance a good bit more:
The vast majority of the code that uses StringBuffer could save a bunch of time by using the new-ish(JDK 1.5) StringBuilder class [sun.com], which has the same API but is not
byCoryoth ( 254751 ) writes:
Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works.
Unit tests don't prove your code works any more than drawing a few right angled triangles and measuring the sides proves Pythagoras' theorem. If you want to prove your ode works you use a theorem prover. To do tht you usually need to provide more detailed specification (beyond just type signatures) about how your code is intended to function. That tends to be more work, though if you really need to know your code is going to work it can often save time in the long run (over ridculously long and exhaustive testing). There are things out there that provide toold support for theorem proving aout your code: SPARK Ada [wikipedia.org] along with the SPARK tools provides a powerful theorem prover, and HasCASL [uni-bremen.de] with CASL tools (including the HOL theorem prover) provides string theorem proving for Haskell. Even ESC/Java2 [secure.ucd.ie] utilises a theorem prover (called Simplify) to provide extended static checking of Java code. I'm sure there are more examples.
My point is not that Unit testing is bad (it's very good), but that you shouldn't overstate its effectiveness. Unit tests are a great way to provide a reasonable degree of assurance that your code will hopefully ork as intended. It isn't a substitute for actual assurance however. It really depends on exactly how sure you need to be - how much an error will cost, and whether that can be tolerated.
Jedidiah,
Parent
twitter
facebook
byJonboy X ( 319895 ) writes:
Let me guess: you've never worked in industry, have you?
By "prove", I mean to present evidence to someone that will cause them to believe whatever it is that you're proving. This of course depends both on what you're proving and whom you're trying to convince. The unit test may not convince you that my code is "correct", but it will convince my boss not to fire me.
It's not all about satisfying your theorems, buddy...
byCoryoth ( 254751 ) writes:
I've worked in industry as a mathematician. When we say we're going to prove something we actually prove it, rather than just tossing out a few random examples for demonstration. Given that a piece of software is, at its heart, just a lot of mathematics, and the fact that it really is possible to prove things about code in the real sense of the word, I would be very careful about saying you "prove" your software works.
Jedidiah.
Parent
twitter
facebook
bySchwarzchild ( 225794 ) writes:
When we say we're going to prove something we actually prove it
I'm not so sure about that. A proof is usually a series of statements that convinces somebody that something is true. Because of this there are many proofs that are wrong. If someone were to prove something it would be more likely to be correct, that is you actually proved it, if a series of formally specified steps were taken like in a declarative language such as Prolog or something of that nature. There is at least one project that is attem
bydiscstickers ( 547062 ) writes:
Oh right, computers run on ideas.
All code is mathematics applied and thus can be proven or disproven to work in the way it was intended.
bybugg ( 65930 ) writes:
I know plenty of software engineering folks- that is, folks that are pushing hard for the acceptance of software development- as a full fledged branch of engineering- who would cringe at your definition of the word "prove" with regards to software engineering. Proving code is a relatively hot research topic in software engineering precisely because it's something that is rarely done and difficult to do. It's not typically done in industry.
Our math friend was right to say that arguments that your code wo
byCoryoth ( 254751 ) writes:
I never said proving theorems about your code was easy, and I agree, for a lot of projects it isn't going to be the cost effective way of doing things. On the other hand there is a reasonable amount of middle ground, and increasing tool support for actually doing some degree of theorem proving. ESC/Java2 is a great example of this - it's not about completely proving your code correct, its about using extra specification to run a theorem prover over parts of your code and provide warnings about all the possi
byDan Farina ( 711066 ) writes:
There are a couple of bundles of lecture notes (#41 and #42 at http://www-inst.eecs.berkeley.edu/~cs164/sp05/lec t ures/index.html [berkeley.edu]) about proof checking in programs. Simply put, solvers can't handle programs of normal size in industry. Proof CHECKING, on the other hand, is quite fast, but that means the programmer has to provide a proof, which the slides show can get quite tedious for even small examples.
byJonboy X ( 319895 ) writes:
Nah. Engineering used to mean something along the lines of "applying scientific and mathematical principles in order to design useful stuff", but now it's generally tossed around to mean "building useful, complicated stuff". Again, it depends who's using the term and in what context.
byaddaon ( 41825 ) writes:
You say "I am unable to prove this correct" and, if such a proof is required for acceptance of the feature, re-write in such a way that you can deliver it along with a proof, or demonstrate that doing so is unreasonable.
bySkim123 ( 3322 ) writes:
Your post brought back a flood of memories from grad school that I would have cared to have forgotten! :-) (Namely, having to spend a semester on exploring correctness theorems, which are about as exciting as spending a week to prove that paint will dry when it would clearly be more entertaining to just sit there for a day and watch it dry.)
bytcopeland ( 32225 ) * writes:
> using the new-ish(JDK 1.5) StringBuilder class
Sounds like a good rule for the migrating [sourceforge.net] ruleset!
bynuzak ( 959558 ) writes:
Like I say every thime this kind of thing comes up, Java isn't slow (any more), but we're certainly not helping matters with this kind of sloppy coding.
Amen to that. Apparently no one at Sun got the memo though when they designed these craptacular libraries in the first place. Saddling us with locks, locks, locks, locks everywhere we look because it assumes you're using shared state in the first place -- even if there's not a thread API method to be seen in the app.
The JVM is not slow. Java the language
byStellian ( 673475 ) writes:
Enough whith Coverity allready. It's like the 50th slashdot article that talks about this.
FYI, it costs about 50.000 $ for a medium sized project (500.000 lines), and is no more than a lint on steroids. Here [infoworld.com] is a somewhat cheaper competitor.
None of this tools is a mach for a manual audit performed by a professional.
Parent
twitter
facebook
bymattwarden ( 699984 ) writes:
None of this tools is a mach for a manual audit performed by a professional.
At $1/line, not everyone can do this.
byIamTheRealMike ( 537420 ) writes:
FYI, it costs about 50.000 $ for a medium sized project (500.000 lines)
Yes it's incredibly expensive. Yet, plenty of well known companies pay for it, so I suspect it's worth it to them.
is no more than a lint on steroids.
Er, no. No, no, wrong, no.
I've got access to the Coverity results for WineHQ. It's already found many problems that evaded both manual code review and unit testing. Its rate of false positives is remarkably low once properly configured. A lot of these problems would only occur in obscure circumstances or on error paths - but these are precisely the kind of errors that unit testing tends not to reveal. It can detect problems like race conditions or memory leaks that lint cannot. The recent X security bugs were revealed by the tool first.
I've seen tools like this before, but not one as good as this. I've never used competing commercial products, so cannot speak as to their effectiveness, but for a large C++ codebase I would certainly be happy to have such a tool helping me out.
Microsoft have used similar programs developed by MS Research on the Windows codebase for some time now and they're apparently very effective. Quite a lot of security problems revealed by them were silently fixed along with other problems in updates.
None of this tools is a mach for a manual audit performed by a professional.
Totally wrong. Every patch that gets checked into Wine passes code review by at least Alexandre who is without question the best programmer I've ever met. He is easily as good as Linus but his much quieter and more conservative personality means he doesn't get Linus' press attention (a good thing, imo). And all the patches are posted to a public mailing list where several other people can and do review patches too.
Static analysis can reveal problems that simply don't get spotted by the human eye because they're too complicated to follow, because they occur in very weird situations, or because the code evolves over time under the direction of many different people and inconsistencies creep in.
Parent
twitter
facebook
bySuperKendall ( 25149 ) writes:
I am in the process of evalutating Fortify and it seems like a really good product as well, with security at the heart of the evaluation rather than just mere bug finding.
Have not looked at Klocwork yet but it seems similar.
byCoryoth ( 254751 ) writes:
If you want a truly powerful Java static analysis tool consider ESC/Java2 [secure.ucd.ie] which includes not just the usual extra static checking you would expect, but also includes a theorem prover which can provide warnings for all kinds of deep and subtle errors. Read through this presentation (warning PDF) [uni-bremen.de] to get an idea of exactly how many things ESC/Java2 can catch, including warnings about race conditions and deadlocks. If you want powerful statsic analysis of Java code ESC/Java2 is definitely the way to go.
Jedidiah
byHerkum01 ( 592704 ) writes:
A dirty little secret for Perl has been Test::Devel. As you write your tests in Perl collects stats on what has been called in your tests, and has what not. An excellent book for learning about Perl testing can be found here Perl Perl Testing: A Developer's Notebook [amazon.com]
byTheGreek ( 2403 ) writes:
You should be.
byOpportunist ( 166417 ) writes:
After missing a few deadlines, the marketing goons will push to abandon security for more crap on the shelves.
After all, that's how the software market works. People buy anything. "LOOK! THE NEW (insert program/OS name here)! I MUST HAVE IT!"
Stable?
Secure?
Mem-leak free?
In one word: FINISHED?
Who cares? It's new, it's shiny, it's been all over all the mags and preview pages, the hype is on, WANNAHAVE!
And as long as we keep buying the unfinished crap, it won't change.
Yes, I'm sure everyone in the tech departments would see this as the right way to go. Test your software, preferably during development, not afterwards. Go through memleak tests, go through stability tests, have some experienced whitehats poke at it, and if it survives, let it go into beta.
If anyone gets that idea past marketing, I will bow down to him.
twitter
facebook
byNineNine ( 235196 ) writes:
You're right... The problem is that software consumers already have a mindset that makes broken programs OK, and the way to fix them is by buying the new version. One of the worst offenders that I've seen in Intuit. Intuit is famous for releasing new programs every single year, regardless of whether or not anything has actually changed. They're also notorious for simply not fixing old code after the new version is released, with the official response of "Your problem is fixed in the new version. Buy tha
byPhisbut ( 761268 ) writes:
The problem is that we all, as consumers, already accept this kind of shit as acceptable. I wish I knew a way to reverse this, but realistically, I don't see this mindset changing any time soon.
The problem is that we let companies sell software with licenses that give them all the rights, while at the same time they waive all responsibility... I don't think I've ever seen a software piece that didn't come with a disclaimer of the type "This is provided as is and we are not responsible for whatever happens
byGnavpot ( 708731 ) writes:
After missing a few deadlines, the marketing goons will push to abandon security for more crap on the shelves.
Is it a fact that early testing will delay a project?
I must admit that I don't know much about large software development projects. But I do know a lot about large development projects in my own profession. It seems that any problem which was unresolved/ignored/insignificant during early development will turn into huge problems a few days before a deadline.
Are software projects different?
bybladesjester ( 774793 ) writes:
Unfortunately a lot of (bad) managers don't judge on quality. They judge on lines of code or features that someone produces. The mentality is "get it out the door and worry about the nitpicking later" (and later never comes).
While you will never fix every single bug and not all bugs make sense to fix, this practice leaves a lot of bugs that should be fixed.
byrumblin'rabbit ( 711865 ) writes:
You are absolutely correct. In general, the more patient and methodical you are, the faster the project gets done. It definitely saves money over the life time of the project. This is particularly true for large projects.
It's when you rush and abandon good practises that the project is in danger
of becoming seriously late.
It's something everyone knows, and everyone occasionally forgets.
byOpportunist ( 166417 ) writes:
If the alternative is early testing or no testing, then yes, early testing delays a project.
byFordiman ( 689627 ) * writes:
Hold on... you BUY software? Do you work as IT for a company or something?
Seriously, I haven't bought a piece of software in years... Not that I have any commercail software, or anything. I'm all OSS at home, and at work, there is no non OSS user (read: me) installed software either.
Meanwhile, I just bought a sweet used small-form 933MHz Dell to replace my old 500MHz Dell. Not much of a step up, but lets face it: I don't use this thing for gaming.
bycolinrichardday ( 768814 ) writes:
I've purchased copies of some Linux distributions (most recent, SUSE 10.0).
byFordiman ( 689627 ) * writes:
Acutally, I haven't bought any in years.
Playing NES games on my GBA requires no recently purchased software. I have an old NES with games I bought in the late 80's/early 90's. I download the corresponding ROMs to those games, place them in PogoShell (an OSS project) and upload them to my GBA's X-ROM cart (a commercial product, but hardware) using a non-open freeware driver for it.
Now, what were you saying, Troll?
byKjella ( 173770 ) writes:
Acutally, I haven't bought any in years. I have an old NES with games I bought in the late 80's/early 90's. I download the corresponding ROMs to those games
Well, I'll excuse the troll. You're not purchasing games, you're infringing on copyright. At this point you're going to quote me several quite valid justifications, but it is not the law. Whoever you downloaded it from doesn't have distribution rights, you don't have reproduction rights and in any case a copy of an illegal copy is an illegal copy.
byFordiman ( 689627 ) * writes:
I assert that downloading is not illegal if I already posess a licensed copy of the game, but I won't debate that.
If I'm guilty of infringement, I can't give a shit. Legal or not, I don't believe that copyright should be binding past ten years - check my past posts, I've got a record of saying five-ten should be the copyright limit, and I do live by that.
Ever read 'The Moon is a Harsh Mistress' by Robert Heinlein? In that book, the character Bernardo De La Paz states his political 'affiliation', which pre
byTheGreek ( 2403 ) writes:
If I'm guilty of infringement, I can't give a shit. Legal or not, I don't believe that copyright should be binding past ten years - check my past posts, I've got a record of saying five-ten should be the copyright limit, and I do live by that.
Unfortunately for you, what you believe doesn't matter.
"I'm sorry, officer. I don't believe that the speed limit should only be 45 on this road. I'm far enough away from the urban area, aren't I?"
bykv9 ( 697238 ) writes:
Unfortunately for you, what you believe doesn't matter.
fortunately for us, you don't make the laws
"I'm sorry, officer. I don't believe that the speed limit should only be 45 on this road. I'm far enough away from the urban area, aren't I?"
truly insightful. i'm sure him downloading ROMs is the same as going over the speed limit, crashing into a gas station and blowing away a good chunk of road.
these analogies... please stop.
byTourney3p0 ( 772619 ) writes:
Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.
Alright, so writing better code means you might miss a deadline. But not writing better code means.. things are exactly as they've always been, or the software development cycle will be revamped appropriately?
Not much of a catch 22.
twitter
facebook
byUbuntuDupe ( 970646 ) writes:
to paraphrase Oscar Wilde: Anyone who doesn't have enough time to do it right, has enough time to do it again.
byFordiman ( 689627 ) * writes:
A good revamping would be for management to learn what the word 'rediculous' means in the context of the word 'deadline'.
byFordiman ( 689627 ) * writes:
Hey, look, a grammar troll.
*stops paying attention*
byKapsar ( 585863 ) writes:
A Catch 22 is a "damned if you do, damned if you don't" circumstance. In this case if you miss your deadline because you created a better product, or you make your deadline but end up with crap and then miss it later. catch 22 is not an old school mentality, it's a realistic way of looking at situations, read the book you'll understand then.
byIpalindromeI ( 515070 ) * writes:
A Catch 22 is a "damned if you do, damned if you don't" circumstance.
No, it isn't. [wikipedia.org]
byIpalindromeI ( 515070 ) * writes:
Reading further, I see that the article agrees with you. Oh well.
byWisp ( 1763 ) writes:
The new Black!
twitter
facebook
bycableshaft ( 708700 ) writes:
I usually do some quick general design and planning beforehand, then go in and write the software one element at a time, testing to make certain it works properly before moving on to the next. The benefits seem to far outweight doing it the other way, for me, as it reveals problems I wouldn't have noticed in the planning stages in the design or implementation early, and it also helps isolate where any bugs would be located at, so I'm not checking all over the place.
I'm not sure if it really saves me any time in the long run, but I'm much more comfortable coding this way, which is probably more important.
Also, so far, I've been the only coder for my projects at work and my games at home, so it *might* not be quite as effective for large teams, although what I've read on XP seems to suggest that it can still be very effective.
twitter
facebook
bybigpat ( 158134 ) writes:
I usually do some quick general design and planning beforehand
Exactly. I really don't think taking more time to "code" is the answer. The majority of security problems in software come about because of design issues. The focus should be on security as a functional requirement. Sure buffer overflows and such can result from poor coding techniques, but I have found it is just a general lack of functional definition which dooms a project to a lot of revision later in the process.
bykentyman ( 568826 ) writes:
Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.
That's not a Catch-22 [wikipedia.org]. That's just a tradeoff.
twitter
facebook
bymetamatic ( 202216 ) writes:
Jeez, next thing programmers will be expected to document their code.
What will the XP weenies do then?
twitter
facebook
byFiveDollarYoBet ( 956765 ) writes:
Those aren't security holes.... They're undocumented network transfer features!
It sounds good and all but there's a direct correlation between the deadline and how bullet proof the code is.
insert sig here
twitter
facebook
byYrd ( 253300 ) writes:
Correct-by-construction programming is a fundamental part of a proper education in software engineering, I would have thought.
Where did these people learn to code?
twitter
facebook
bytruthsearch ( 249536 ) writes:
In the real world... where the client says, "I don't care about security, just get it done!" Of course they start to care after a break-in, so they have things fixed in hind-sight.
Parent
twitter
facebook
byGillBates0 ( 664202 ) writes:
I always make sure I use the highest quality bits when I program. You'll find none of those low-quality, flimsy and occasionally perforated bits in my code.
Agreed, periodic checking for holes has it's own value, but nothing beats using the best quality, industrial-strength (tm) bits to start with, moreso while developing reliable software in the post-911 world.
twitter
facebook
byMasterC ( 70492 ) writes:
...but nothing beats using the best quality, industrial-strength (tm) bits to start with...
For those not in the industry sector but in information technology sector, are those the same as the Best Information Technology Strength (BITS) bits? I've used BITS bits before and they were solid and performed quite well.
The Big Unsigned Superior Technology bits are the best choice for the adult entertainment sector. They're so successful that I hear its those bits that dominate the internet and slashdotters' hard
bySponge Bath ( 413667 ) writes:
...use the highest quality bits
I bought a box of 'Great Quality' bits from Fry's.
It only contained zeros, but they price was great!
byMetabolife ( 961249 ) writes:
After taking this training routine, Microsoft says that Vista will be delayed another 2 years.
twitter
facebook
bymkiwi ( 585287 ) writes:
Sometimes it amazes me what people do with the C programming language, for good or for bad. Take some pro programmers who I caught using gets() instead of fgets(). I'm not a rocket scientist, but I'd say anything that uses gets() is a serious problem, since that function does no bounds checking and is prone to attacks.
How do people learn to code like this? Is it just early habits that do not go away?
twitter
facebook
byRichard Steiner ( 1585 ) writes:
I've always wondered why such harmful code is allowed to survive. We certainly don't allow it in our own local utility libraries.
Rewrite the standard gets() function, and have the compiler force programs which utlize the old one to handle the new one (either by making the change transparent to existing code or by forcing the programmer to address the problem by making some minor changes).
Problematic standard library functions are traps just waiting to happen.
UNIX is too "steeped in tradition" for its own g
byRichard Steiner ( 1585 ) writes:
What's wrong with adding a required size argument to getc() and forcing code using the old problematic function to alter their function calls?
Isn't that preferable to leaving a potential timebomb out there?
There is never "no way" in software. There might be "not acceptable" for various reasons, but that isn't the same.
Hopefully most compilers treat getc() as a deprecated function, anyway.
bychthonicdaemon ( 670385 ) writes:
In many cases they learn to program for their own projects, where speed/ease of coding may be more important than security. If you just pick up an old C book, no-one warns you to stay away from gets(), so people learn to use it, and it works. Then they get told to use something else that is more secure but it is slow or more difficult to learn, so they don't.
In my building there is a whole floor of guys doing simulations in Fortran 77. When I tell them about new functions in F90 or about ways they cou
bycain ( 14472 ) writes:
The example in the write up is not a catch 22 [wikipedia.org]. A catch 22 requires two things be done, each one before the other, thus neither can be done.
twitter
facebook
byPeyna ( 14792 ) writes:
Have you read the book "Catch-22"?
"There was only one catch and that was Catch-22, which specified that a concern for one's safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn't, but if he was sane he had to fly them. If he flew them he was crazy and didn't
byLargeWu ( 766266 ) writes:
No, I think you have failed to comprehend the example from the book. Go back and read it again. A catch-22 is a circular set of conditions that can only be fulfilled if the other is true.
The second condition in your example falsely assumes that code which is released on schedule cannot also be bug free.
Furthermore, "Damned if you do, damned if you don't" is a lose-lose situation, not a catch-22. This phrase assumes that "do" and "don't" are not dependent on each other. Of course, if you have to "do"
byRoadkills-R-Us ( 122219 ) writes:
A Catch 22 requires two mutually exclusive things to be at the same time.
It comes from the book of the same name wherein the only way to get the army to take you out of the war, you had to be proven crazy, but desiring to get out proved you weren't crazy, so there was no (legal) way out (without getting injured or killed in the line of duty).
--
``...like an alpaca sack full of hairy strawberry ice cream, bleeding, pink toes awry...''
byMr Z ( 6791 ) writes:
Is it just me, or does the article just read like a thinly veiled advertisement for Coverity? It's reads like a generic commercial template: "Meet Bob. Bob thought everything was fine. But then he discovered he had Problem X. That's when Bob discovered Company Y with Solution Z." (etc. etc.).
twitter
facebook
bycant_get_a_good_nick ( 172131 ) writes:
Seems they've been astroturfing for a while. wasn't that long ago they did a big writeup on flaws Coverity found in certain FLOSS projects. at least then they found some bugs and helped fix.
I'm all for tools like this. YOu can find a billion text editors on sourceforge.net but very few good programmers tools. Just this smells like an add for me.
Parent
twitter
facebook
byderek_farn ( 689539 ) writes:
Tools are a cost effective way of checking source for lots of different kinds of problems. I have no direct experience of the Coverity tool, but see that they are certainly good at getting lots of publicity. A List of static analysis tools [wikipedia.org] is available on Wikipedia.
twitter
facebook
byblitz487 ( 606553 ) writes:
I went to Coverity's web site. There isn't much useful information there about what it does, but there is lots of vague hype and attempts to get you to register. But what turned me off was their website hijacked the 'back' button so you couldn't leave their site.
Why do companies think that is a good idea?
by192939495969798999 ( 58312 ) writes:
If being careful makes you miss the deadline, then the deadline is set wrong. Shipping a product with security holes that you knew about + could've fixed with a bit more time is how we got into the position we're in. Pushing back a release date to fix them first should be the rule, not the exception.
twitter
facebook
by192939495969798999 ( 58312 ) writes:
Right, that's because the commercial software development model is broken. It takes longer than they'd care to spend, and that's why the quality of commercial software suffers compared with software properly designed. Of course this costs way more to do, but it should pay off better in the end because of reduced maintenance, etc. costs over the life of the product, which also should be significantly extended because of higher quality.
byBillly Gates ( 198444 ) writes:
Especially if you don't know assembler.
The problem I see is that hackers today use buffer and stack overflows. The compiler creates the insecure code more than the program.
I wonder how secure managed code in .Net is? I know MS boasts that not a single security hole has been spotted so far but I do not know of any apps that use it? I know Java is secure for that reason but less usefull on the desktop.
byBillosaur ( 927319 ) * writes:
Assuming you have a good idea of what input to your program is supposed to be, and you have an adequate method of checking to make sure the data is not some sort of goo (love those regexs!), then you should be able to test the software as you go. I'm of the school that tends to build each part, test it, and move on. It cuts down on the holes if I know where a piece of data comes from, where it's going, and what manipulations may happen to it along the way.
byWeaselmancer ( 533834 ) writes:
Narrator: A new program written by my company is shipped on time, but with bugs. The network stack locks up. The OS crashes and burns and scrambles the hard drive. Now, should we initiate a code review? Take the number of licenses in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a code review, we don't do one.
Business woman on plane: Are there a lot of these kinds of bugs?
Narrator: You wouldn't believe.
Business woman on plane: Which software company do you work for?
Narrator: A major one.
twitter
facebook
byFulcrum of Evil ( 560260 ) writes:
No, you didn't have to do that. Without the callous disregard for loss of life, that exchange is just stupid.
byWeaselmancer ( 533834 ) writes:
Without the callous disregard for loss of life, that exchange is just stupid.
Ok then, does this help? [airliners.net]
byFulcrum of Evil ( 560260 ) writes:
He didn't mention planes. I know that, where I work, a crashed server isn't even a big deal.
byCoryoth ( 254751 ) writes:
What really makes it troubling for software is this: What is the "average out of court settlement" per discovered bug in a piece of software?
Jedidiah.
by955301 ( 209856 ) writes:
Now advertisements for COTS products are news articles?
While I appreciate the articles on NASA releasing code analysis tools - or pointers to freshmeat - embelishing about something I can't immediately use is boring. Procurement happens at a snails pace for purchased software - gimme something I can throw on the stage and start training dev's to use.
Or at least something in depth that shows statistics on *how much* the schedule slips by when taking this security first approach - that would be news:
"WSJ repo
byGreyfox ( 87712 ) writes:
I see static analysis and code auditing as an excellent step on the road of security, but at a completely different level you have to also make sure that the processes you're coding are also secure. All the secure programming techniques in the world will not help you if your design itself has flawed assumptions. So not only should you program for security but you should also design for security.
twitter
facebook
byVGR ( 467274 ) writes:
From the article:
Many companies rushed to beat rivals with new software, and checking for bugs that could later be exploited by hackers was often seen as a waste of time. That has begun to change in the past few years as new laws force the disclosure of security holes and breaches...
What laws are these? This is the first I've heard of such a thing. And why do I have a feeling these laws have a clause that directly or indirectly exempts certain large software companies?
twitter
facebook
bysuv4x4 ( 956391 ) writes:
I've some inside info and let me tell you how it works: write the best code, check for holes, make sure there are no bugs and so on and so on, but if you miss the deadline you're definitely fired.
And since the deadline is always unrealistic, all checks get down in priority as you try to keep your job hammeric code that barely works with the speed of light.
bytgrigsby ( 164308 ) writes:
This stands in contrast to an earlier ethos to rush to beat rivals with new software, and, of course, brings tradeoffs: 'Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.'
As with everything in a project, adherence to security guidelines must be figured into the time estimates for a project. Time estimates must in turn be based on department-reviewed technical specs. Tech specs are based on design and development reviewed functional specs. Functi
byAllnighterking ( 74212 ) writes:
The problem is one of doing things in software the way Automobile companies did in the 60's and Japan stopped doing in the 70's. Traditionally in software development you design... then send to engineering to build then send to QA for an endless cycle of test bitch fix bitch retest bitch fix bitch test bitch deadline ooops market.
QA should be involved the moment some fool says "I have an idea" and stay in the loop all the way. Testing in increments as things are built. I've done more in a white paper on my site as for writing this all up but this is the jist. Integration of Quality control from the start means less problems. The idea of. I'll fix it later sucks because it never gets to be later.
twitter
facebook
byz4pp4 ( 923705 ) writes:
Everybody makes mistakes. That is how we learn and progress to a more experienced state of being.
By telling people not to make mistakes is letting them know that they cannot try out new and inventive, sometimes even shorter ways of doing things.
Unit testing is fine and should be encouraged, but really the thing you want to do here is make your build process do all the donkey work as much as possible, and let your programmers worry about the programming issues and doing things smarter and achieve the most
bySeaDuck79 ( 851025 ) writes:
Good.
Fast.
Cheap.
Pick any two.
You can define the scope, the deadline, or the budget.
Pick one. Not two. Not three. One.
byAeiwiMaster ( 20560 ) writes:
I have been think if it isn't posible
to make a valgrind tool which scans for secuity issus ?
http://valgrind.org/info/tools.html [valgrind.org]
bysyousef ( 465911 ) writes:
being more careful can mean missing deadlines
Failing to plan extra time to be more careful (ie. check for bugs) means missing deadlines. Only an incompetent manger, or a dishonest conman setting the team up to fail is going to insist on extra care in coding and/or code review and not put the extra time required on the plan. There's definitely a time vs quality tradeoff but it has nothing to do with missing deadlines since they should be set correctly.
bysl4shd0rk ( 755837 ) writes:
It's sad times indeed when you have to explain to a programmer to test his code. It sounds to me like the easy-buttons are catching up with laziness and breeding stupidity.
byRichard Steiner ( 1585 ) writes:
Software development is an iterative process that involves unit, subsystem, and system testing, optimally by BOTH the programmer(s) and by at least one dedicated third party.
We always had business analysts test our stuff. They knew how it was supposed to work, but more importantly: they usually didn't understand the technical underpinnings, so they didn't know what they *weren't* supposed to test. That sometimes produced interesting results. :-)
bytgrigsby ( 164308 ) writes:
These Five Orders of Ignorance play an tremendously important role in systems development
Apparently they also play a heavy role in Donald Rumsfeld's job.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
●
566 commentsChina Raises Tariffs on US Goods To 84% as Rift Escalates
●
521 commentsAmazon To Display Tariff Costs For Consumers, Report Says
●
361 commentsTrump AI Czar Sacks on Universal Basic Income: 'It's Not Going To Happen'
●
320 commentsChina Raises Tariffs on US Imports To 125%
●
290 commentsEuropean Tourism To US Plunges
Generic Dungeons, Universal Dragons
The Lost Gizmondo Halo Title
Slashdot Top Deals
Slashdot
●
●
of loaded
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...