Challange for you becomes a challenge for others! Help creating a code snippet:

[Brad Jones]

I need help creating a code snippet for a writing project I'm working on. This code snippet needs to be in C++ and it needs to illustrate a bug. I need the code to be clean and easy to follow, yet the code needs to have the bug so that others can then try to find it.

I actually need to do a couple of these, but I'll start with an easy one.

>> Dereferencing NULL pointers

Can you create a code snippet that is clean, clear and easy to follow, but that includes an error in dereferencing a NULL pointer? Feel free to post to this thread your submission for this. I'm sure others will let us know if what you submit is good or could be better!

Are you up to the challenge of writing a little buggy code?!

[2kaud]

One example is

int main()
{
char *nref { nullptr };

	(*nref)++;
}

[superbonzo]

I'll start with an easy one.

it's not so easy; unfortunately the standard is not very explicit on when a null pointer dereference ( or more generally, an indirection of a pointer to an object with indeterminate value ) gives ub or not; sometimes is legal, sometimes not, sometimes it depends on the standard version ... the basic idea is that you *can* dereference a null pointer as long as no lvalue-to-rvalue conversion occurs, that in turn depends on fairly obscure and intricate rules spreaded over all the language specification ...

for example ( >=c++11, supposing I recall correctly, of course )

int main()
{
	int a = 0;
	int *b = &a;

	*(int*)0; // OK
	*(volatile int*)0; // UB
	typeid(*(volatile int*)0); // OK
	a = *b, *(int*)0; // OK
	a = *(int*)0, *b; // UB
	a = (*b, *(int*)0); // UB
	a = (*(int*)0, *b); // OK
	// ...
}

[Brad Jones]

Excellent feedback guys!

Here is what I'm really driving towards with the examples..... I'd like to create an 8 to 20 line listing of code (can be longer or shorter if needed) that looks good, that has the bug on one of the lines. This listing will be presented to a group of developers and they will be told to find and identify the bug. I'll actually give them 5 choices for where/what the bug is.

In the case of this listing, I want to be able to identify that the bug is on line X and is a null pointer being dereferenced.

Should be fun stuff when it is done! Care to modify either of your listings (or if anyone else wants to submit a new one...)?

Thanks!

[OReubens]

ANd of course, just because NULL (or more correctly any pointer between 0x00000000 and 0x0000FFFF) can not possibly be valid memory on WIndows doesn't mean this is true on all platforms.
there are systems out there where you actually do want to have a pointer set to 0 to change system specific memory (such as system time, or keyboard buffer).
THis is the case for real mode PC (DOS) where the first few Kb in low memory are reserved for BIOS variables. ANd is true for many other platforms.

In WIndows MS made the smart decision to make the bottom and top 64K memory in the available address space 'invalid' precisely for the purpose of more easily detecting this kind of error.

ALso, an actual null pointer bug is difficult to "hide" in small section of code (especially if the null assignment has to be the error rather than the null being the sideeffect of another bug)... a 'stray' or uninitialised pointer is more easily 'hidden'. Not sure if you're after one or the other.
ALso more easy in C than C++, since in C++ any pointer is more likely a failure to not use proper C++ solutions (containers, iterators, streams, ...). Making pointers 'suspicious' in all usage case, where this is less so in C where it's impossible to avoid most.

for example something like

char* pFileName = strrchr("c:\nofile.here", '\\');
// user pFileName later..

in the above code the pointer will be zero, is the assignment the bug ? or the fact you didn't test the result of strrchr ? or the fact you forgot to escape the \ in the filename ?
also, the above, while compilable in C++ isn't a proper C++ sample since it's using the c lib and there's better ways in c++ to avoid precisely these kinds of issues.

[Brad Jones]

So dereferencing a null pointer is a hard one to illustrate in a code snippet. Let's try a different one:

>> Usage of uninitialized data

[Codeplug]

Being lazy, here are some thoughts:
Combine the two to demonstrate that global vars are zero-init'd (causing null deref?) while locals are not.
Hide the null deref in a local function call passing a pointer (function parameter validation?).

gg

[superbonzo]

Should be fun stuff when it is done! Care to modify either of your listings (or if anyone else wants to submit a new one...)?

I'm not sure I follow you ... should the snippets be tricky and hard to "solve" ? or should they convey some dangerous practice in a simple and concise way ?

BTW,

there are systems out there where you actually do want to have a pointer set to 0 to change system specific memory (such as system time, or keyboard buffer).
THis is the case for real mode PC (DOS) where the first few Kb in low memory are reserved for BIOS variables. ANd is true for many other platforms.

uhm, standard wise, null pointers never refers to valid objects in memory, both in c++ and AFAIR in c; so, either those platforms are non conforming or they use special binary value representations for null pointers or special apis to access such null addresses ... or am I missing something ?

[Brad Jones]

I'm not sure I follow you ... should the snippets be tricky and hard to "solve" ? or should they convey some dangerous practice in a simple and concise way ?

I'm wanting to illustrate dangerous, standard errors that can be inadvertently coded into applications. I'd like the code to be realistic, not "purposefully tricky." The idea is to show a standard error and see if people can find them (and how long it takes them to find them).

To another point - I'd prefer each snippet that is being created to focus on a single error. Another part of this is to see if people can find the one error.

Here is an example I had created of how these will be (kind of) presented:

What's wrong with the following code:

char my_array_of_letters[26];
for( int i = 0; i <= 26; i++ )
          my_array_of_letters[i] = (char)(i + 64); 

cout << my_array_of_letters[1] << my_array_of_letters[18];
cout << my_array_of_letters[3] << my_array_of_letters[3];

(a) The char cast in the third line causes a type-mismatch error. You can't do (char) (i + 64)
(b) The for loop is infinite
(c) There is a buffer overflow for the my_array_of_letters array
(d) my_array_of_letters is not initialized before it is used
(e) Nothing is wrong. The code works fine.

[tiliavirga]

This code snippet needs to be in C++

Usually when the dangers and traps of C++ are to be illustrated most of the examples come from the C part of C++.

That's fine but lets not forget that C++ is an extension of C and that the extension has improved immensely with versions 11 and 14 to the point where C++ feels almost like a new language. It's now definately on par with Java and C# (who were once introduced as secure alternatives to C++)

So maybe the time has come for C++ programmers to stop flagellating themselves for the C-devil in them and start using modern secure C++ instead.

[Brad Jones]

Even using modern, secure C++, people still make errors. What are some of the errors they still make with the modern iterations of C++? Can you identify some tiliavirga?

[2kaud]

Even using modern, secure C++, people still make errors. What are some of the errors they still make with the modern iterations of C++? Can you identify some tiliavirga?

See this post http://forums.codeguru.com/showthrea...e-doesn-t-work for a c++ example.

[tiliavirga]

See this post http://forums.codeguru.com/showthrea...e-doesn-t-work for a c++ example.

I've put in a reply (post #4) to that thread to indicate what I think could qualify as a "modern secure C++ solution" to the OP's problem.

[tiliavirga]

Even using modern, secure C++, people still make errors. What are some of the errors they still make with the modern iterations of C++? Can you identify some tiliavirga?

Certainly, but I rather leave it to the experts, like say

http://www.gimpel.com/html/index.htm

My recommendation is to use a lint-style analyzer (like the one in the link above) but when a bug is found don't just fix it. Instead rewrite the code using higher (read 11 and 14) language constructs so the bug is no longer possible. And do this preemptively without waiting for a bug to prompt you. I can pretty much promise this will completely rid your code of the kind of bugs we are talking about in this thread.

Programmers are notorious problem solvers and I'm sure they'll find great entertainment in the bug-puzzles you are preparing (for field-tested examples see "bug of the month" in the link above). But producing good ones is tricky, the educational value is limited, and the conclusion is already at hand: Use a lint-style analyzer and prefer the highest level of abstraction the language offers.

[Brad Jones]

Certainly, but I rather leave it to the experts,

I don't disagree. The end result of this 'exercise' of showing a dozen bugs and seeing the kind of time it takes it to then focus on how a tool can bring that time down to near zero.

But for now I am doing the 'bug of the month' type activity to try to illustrate the various types of bugs. These are all bugs (by the way) that a tool would eradicate, or at least find, easily.

So having said that, I need to create a simple, working snippet of code with choices that can be used as shown in post #9, but for dereferencing a NULL pointer.....