The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Artima Developer Spotlight Forum
SANS Compiles Top 25 Most Dangerous Programming Errors

27 replies on 2 pages. Most recent reply: Jan 30, 2009 7:21 AM by Fireblaze .

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 27 replies on 2 pages [ « | 1 2 ]
Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 8:12 AM
Reply to this message Reply
Advertisement
> I actually think that putting data validation in code is a
> bad solution for a lot of problems. For one, it makes
> code a lot harder to make reusable. The valid range for
> your application may not be the same as it is for my
> application. How would library and framework developers
> deal with that? They'd have to allow the maximum range
> supported by the type and that defeats the purpose.

In C++ it might look like this:

range<int> r(10, 20);
...
r = 25; // throws exception (assuming '=' is overloaded)
...

Basically, anyone can define a range for their own purpose and the range object would do a check on every assignment.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 8:15 AM
Reply to this message Reply
> In C++ it might look like this:
>
> range<int> r(10, 20);
> ...
> r = 25; // throws exception (assuming '=' is
> overloaded)
> ...
>
> Basically, anyone can define a range for their own purpose
> and the range object would do a check on every assignment.

The better Pascal implementations were able to optimize away many of the checks. I'm not sure how many C++ compilers would manage to do likewise with objects in that form.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 9:10 AM
Reply to this message Reply
> > In C++ it might look like this:
> >
> > range<int> r(10, 20);
> > ...
> > r = 25; // throws exception (assuming '=' is
> > overloaded)
> > ...
> >
> > Basically, anyone can define a range for their own
> purpose
> > and the range object would do a check on every
> assignment.
>
> The better Pascal implementations were able to optimize
> away many of the checks. I'm not sure how many C++
> compilers would manage to do likewise with objects in that
> form.

I wouldn't worry too much about compiler optimizations in this case because it can only be optimized in some cases (when we use literal constants to specify range and values). What's important is flexibility: being able to define a range dynamically (i.e. r(x, y)) and to specify a non-numeric range, for example:

// only for values item_X where 1 <= X <= 5
range<string> r(item_1, item_5);
...
r = "item_8"; // throws exception
r = "abc"; // throws exception
r = "item_4"; // fine
...

Isn't that neat? Why provide a built-in range construct that only works with integers (or maybe floats too) when we can provide constructs that let users create their own range objects?

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 9:11 AM
Reply to this message Reply
Should be: range<string> r("item_1", "item_5");

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 10:05 AM
Reply to this message Reply
> > I actually think that putting data validation in code is
> a
> > bad solution for a lot of problems. For one, it makes
> > code a lot harder to make reusable. The valid range
> for
> > your application may not be the same as it is for my
> > application. How would library and framework
> developers
> > deal with that? They'd have to allow the maximum range
> > supported by the type and that defeats the purpose.
>
> In C++ it might look like this:
>
> range<int> r(10, 20);
> ...
> r = 25; // throws exception (assuming '=' is
> overloaded)
> ...
>
> Basically, anyone can define a range for their own purpose
> and the range object would do a check on every assignment.

So if I'm writing a library and I don't know what the range is for your needs, what do I put in there instead of "r(10,20)"?

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 10:21 AM
Reply to this message Reply
> So if I'm writing a library and I don't know what the
> range is for your needs, what do I put in there instead of
> "r(10,20)"?

The user of your library will specify what range they need, not you, the library designer; you would just create the range class with the necessary member functions.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 10:45 AM
Reply to this message Reply
> > So if I'm writing a library and I don't know what the
> > range is for your needs, what do I put in there instead
> of
> > "r(10,20)"?
>
> The user of your library will specify what range they
> need, not you, the library designer; you would just create
> the range class with the necessary member functions.

So I need to expose implementation details so that the user can specify the range of the variables in my classes?

In any event, if it's up to the user to specify the limits, what makes this approach better than any of the other ways data can be validated?

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 11:19 AM
Reply to this message Reply
> > > So if I'm writing a library and I don't know what the
> > > range is for your needs, what do I put in there
> instead
> > of
> > > "r(10,20)"?
> >
> > The user of your library will specify what range they
> > need, not you, the library designer; you would just
> create
> > the range class with the necessary member functions.
>
> So I need to expose implementation details so that the
> user can specify the range of the variables in my
> classes?
>

Your class would validate the range on assignments, you could just expose a few useful functions or maybe some explicit conversion operators (i.e. from range to int, if the user specified the range to be of integer type), etc.

> In any event, if it's up to the user to specify the
> limits, what makes this approach better than any of the
> other ways data can be validated?

This was just my response to someone's previous post about having language construct to specify a value range, and they gave an example from Pascal and Ada. So, i'm saying that it's better to have the language provide facilities to create such user-defined objects instead of having built-in constructs for it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 20, 2009 11:47 AM
Reply to this message Reply
> > In any event, if it's up to the user to specify the
> > limits, what makes this approach better than any of the
> > other ways data can be validated?
>
> This was just my response to someone's previous post about
> having language construct to specify a value range, and
> they gave an example from Pascal and Ada. So, i'm saying
> that it's better to have the language provide facilities
> to create such user-defined objects instead of having
> built-in constructs for it.

OK, I agree with you on that.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 21, 2009 2:59 AM
Reply to this message Reply
> Your class would validate the range on assignments, you
> could just expose a few useful functions or maybe some
> explicit conversion operators (i.e. from range to int, if
> the user specified the range to be of integer type), etc.

The GUI library (wrapping various MFC classes) I have developed uses a similar technique.

All input edit boxes contain a reference to an instance of a class that presents three checking and formatting functions. The standard box refers to the default implementation that essentially does nothing. Users of the edit boxes can then derive formatting classes from the base, which can define any weird and wonderful formatting/checking they desire. The derived class is sent to the input box as the desired format/check rules.

I work on the belief that input correctness should be tested at the earliest possible time. i.e. If you have an input box that expects negative floating point numbers then 0.-123 or -0.1.2.3 should not even be possible to type in. This ensures that the data read from this box does not have to be checked for syntax correctness after the event.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 21, 2009 4:44 AM
Reply to this message Reply
> The idea that just by providing the right features and
> tools we can eliminate bugs is completely bogus.

Tools are not optimal. They can be improved a lot, to the point that only few bugs are left.

> All
> studies on the subject point to the contrary.

Could you please point us to these studies?

> Improvements in tooling can make a big difference but it
> t will not solve the problem.

Ultimately, there is no level at which a proof system will be satisfactory 100%. Because when a proof A is validated based on proof B, someone has to prove B as well.

Nonetheless, tools can be improved a lot.

>
> If the range can be specified on the variable, the
> programmer can still specify the wrong range. It's no
> more safe than many other comprehensive validation scheme.
> The point is that input should be checked. There's no
> o tool that can protect us from incorrect specification.

What if the input check is incorrect?

I'd rather write my code as the requirements say rather than be based on the intuition of some programmer.

>
> I actually think that putting data validation in code is a
> bad solution for a lot of problems. For one, it makes
> code a lot harder to make reusable.

Can you prove that?

The valid range for
> your application may not be the same as it is for my
> application. How would library and framework developers
> deal with that? They'd have to allow the maximum range
> supported by the type and that defeats the purpose.

That's why templates exist, to make code reusable and customizable.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 21, 2009 4:45 AM
Reply to this message Reply
> > I actually think that putting data validation in code is
> a
> > bad solution for a lot of problems. For one, it makes
> > code a lot harder to make reusable. The valid range
> for
> > your application may not be the same as it is for my
> > application. How would library and framework
> developers
> > deal with that? They'd have to allow the maximum range
> > supported by the type and that defeats the purpose.
>
> In C++ it might look like this:
>
> range<int> r(10, 20);
> ...
> r = 25; // throws exception (assuming '=' is
> overloaded)
> ...
>
> Basically, anyone can define a range for their own purpose
> and the range object would do a check on every assignment.

Let's also not forget this:

range<10, 20> r = 25;

The above can be caught at compile time.

Fireblaze .

Posts: 21
Nickname: fireblaze
Registered: Jul, 2006

Re: SANS Compiles Top 25 Most Dangerous Programming Errors Posted: Jan 30, 2009 7:21 AM
Reply to this message Reply
* Improper Input Validation "Assume all input is malicious."

All programming language default libraries assumes that all input is propper. There you have the real problem. Instead of fixing the root cause, ei bad libaries that are bundled with the language.

Its the same with bufferoverflow and bufferunderflow just plain bad language decitions to allow exceptions to crash everything.

Flat View: This topic has 27 replies on 2 pages [ « | 1  2 ]
Topic: Adobe's Adrian Ludwig on Running AIR on Linux Previous Topic   Next Topic Topic: The Jamon Templating Engine
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use