- Forum
- General C++ Programming
- Trying to understand dirty testing.
Trying to understand dirty testing.
My understanding of it is a test that runs data contrary to expected input data. For example, lets say we have written a string length function which takes a char *.
A dirty test would be to pass in an char array that no termination value.
To protect against data like this, we can add an additional param of the size of vector along with the vector itself. Is this correct?
A dirty test would be to pass in an char array that no termination value.
To protect against data like this, we can add an additional param of the size of vector along with the vector itself. Is this correct?
I thought when they used C-strings they just checked for a null ('\0'). But it'd be a good idea to know the length.
Well my question is how is dirty testing for other types done?
For example, lets say a function uses 'new', and for some reason the memory within 'new' is defective/damaged. The new function will return a pointer to this defective memory. How is this testable?
It would be writable without error since the memory allocated is valid.
But upon deletion, an assert would be thrown since the deallocated memory does not match the size of the memory region being deleted.
And this scenario as well...,lets say there is a function taking in 5 params. This particular function is completely hidden/private/etc and only used by the system and never touched by the user. Is it still necessary to protect this function against 'dirty' data being passed in? And assume that all the systems using this function are trying their best to send it clean data.
For example, lets say a function uses 'new', and for some reason the memory within 'new' is defective/damaged. The new function will return a pointer to this defective memory. How is this testable?
It would be writable without error since the memory allocated is valid.
But upon deletion, an assert would be thrown since the deallocated memory does not match the size of the memory region being deleted.
And this scenario as well...,lets say there is a function taking in 5 params. This particular function is completely hidden/private/etc and only used by the system and never touched by the user. Is it still necessary to protect this function against 'dirty' data being passed in? And assume that all the systems using this function are trying their best to send it clean data.
new never returns an invalid pointer, it either throw an exception or returns NULL ( 0 )
chrisname
You're right, I was just trying to illustrate an example.
A better one would be sprintf versus sprintf_s, I mean, they're trying to protect the function (of the _s type) by adding an additional param of the max size of buffer.
So this leads me to further questions...such as what if the max size of buffer itself is incorrect?
You're right, I was just trying to illustrate an example.
A better one would be sprintf versus sprintf_s, I mean, they're trying to protect the function (of the _s type) by adding an additional param of the max size of buffer.
So this leads me to further questions...such as what if the max size of buffer itself is incorrect?
Last edited on
Well, what about this other scenario?
---
And this scenario as well...,lets say there is a function taking in 5 params. This particular function is completely hidden/private/etc and only used by the system and never touched by the user. Is it still necessary to protect this function against 'dirty' data being passed in? And assume that all the systems using this function are trying their best to send it clean data.
---
And this scenario as well...,lets say there is a function taking in 5 params. This particular function is completely hidden/private/etc and only used by the system and never touched by the user. Is it still necessary to protect this function against 'dirty' data being passed in? And assume that all the systems using this function are trying their best to send it clean data.
If the size of the buffer is incorrect; you'll get a buffer overrun, segfault, and die.
As for the second; if the function is itself a privileged function call; calling it would cause a segfault anyway (or, more likely, a signal which would be misinterpreted as a segfault). It may not be necessary to 'protect' it but it would probably be a good idea. You can't always trust that data corruption won't occur, even if you're writing privileged code.
As for the second; if the function is itself a privileged function call; calling it would cause a segfault anyway (or, more likely, a signal which would be misinterpreted as a segfault). It may not be necessary to 'protect' it but it would probably be a good idea. You can't always trust that data corruption won't occur, even if you're writing privileged code.
Topic archived. No new replies allowed.