Thursday I interviewed with a company in the Houston, Texas area.

One of the interviewers had me examine two pieces of buggy code and try 
to identify the bugs.  I don't remember all of the details.  Here is the 
first one:

function() {
// some stuff

	if (whatever) {
		// code here to get a mutex lock
		// other stuff
	}
	// code here to release the mutex lock
	// the rest of the function code
}

The way I simplified it makes it easier to spot the bug.

The second one was issued with the warning that very few people can id 
the bug:

char* some_function() {
	char yada[100];

	char* p=yada;

	// some stuff that fills the array with data

	// and more stuff

	// and more stuff

	return p;
}

When I saw the return statement, and looked back to what the pointer was 
set to, I said, "I wouldn't do that."
"Do what?" the interviewer asked.
"Return a pointer to a local variable."
This provoked a laugh from the interviewer.

Seriously?  Not many people catch that?

Evidently not.  In chatting with the interviewers that day, they all 
confirmed that most bugs are stupid things like this.

Anyway, the job prospect is still a going affair, so I suppose I did 
okay in the interview.

Regards,
John

Post a reply to this message

On 04/03/2012 9:20 PM, John VanSickle wrote:
> Thursday I interviewed with a company in the Houston, Texas area.

Break a leg, John. :-D

-- 
Regards
     Stephen

Post a reply to this message

Nicely done!  I have to imagine that finding the interview questions to 
be too easy is certainly a good sign for your employment prospects. 
Come to think of it, as simple as that second question is it seems to be 
a pretty good way to test what level of "mental model" a person uses 
when coding, and since lots of people apparently botch it, it seems to 
be a pretty necessary test too.

Post a reply to this message

John VanSickle <evi### [at] kosherhotmailcom> wrote:
> Evidently not.  In chatting with the interviewers that day, they all 
> confirmed that most bugs are stupid things like this.

  Sadly, the vast majority of people programming in C (or C++) professionally
out there don't actually know the language enough to avoid such trivial ways
to shoot yourself in the foot. It may be something that you and me can spot
in a second, but I'm certain the average professional C programmer can't see
it. It's no wonder programs are so buggy. A sad state of affairs.

  In C++ in particular this is another situation were the majority of C++
programmers out there have no idea what's wrong:

//-------------------------------------------------------------
template<typename Value_t>
class Array
{
    Value_t* mData;
    std::size_t mSize;

 public:
    Array(std::size_t size):
        mData(new Value_t[size]),
        mSize(size)
    {}

    ~Array() { delete[] mData; }

    Value_t& operator[](std::size_t index)
    {
        assert(index < mSize);
        return mData[index];
    }

    const Value_t& operator[](std::size_t index) const
    {
        assert(index < mSize);
        return mData[index];
    }
};
//-------------------------------------------------------------

-- 
                                                          - Warp

Post a reply to this message

On 3/4/2012 2:33 PM, Warp wrote:
> John VanSickle<evi### [at] kosherhotmailcom>  wrote:
>> Evidently not.  In chatting with the interviewers that day, they all
>> confirmed that most bugs are stupid things like this.
>
>    Sadly, the vast majority of people programming in C (or C++) professionally
> out there don't actually know the language enough to avoid such trivial ways
> to shoot yourself in the foot.

It's quite a pity too, seeing as how C++ provides so many intricate and 
sophisticated ways to shoot yourself in the foot.

Post a reply to this message

On 03/04/2012 04:20 PM, John VanSickle wrote:
> Anyway, the job prospect is still a going affair, so I suppose I did
> okay in the interview.

Yep ... I'd say you did pretty darn good. Fingers crossed ... Keep us 
posted.

Post a reply to this message

Le 04/03/2012 23:33, Warp nous fit lire :
>   In C++ in particular this is another situation were the majority of C++
> programmers out there have no idea what's wrong:

* you used a template ? (nop, just a red herring for you! but a single
uppercase letter is usually preferred to Value_t)
* you have the [] checks the upper range (whereas usually it's at()
which check, and [] do not)
* you checked upper range, but not lower one
* you should have stated index in [] with const
* using assert is not the right way to handle the issue.
* you did not test in creator the value of size ( 0 ?)
* copy-constructor... you're in trouble with mData
* you did not disable automatic conversion of "number" into Array<>, so
if you have some different signature for some methods using either
number or Array<>, you're in for surprise (explicit)

With actual compiler:

* you forget the include needed for size_t (cstring)
* you forget the declaration of assert() (assert.h)

Post a reply to this message

>    In C++ in particular this is another situation were the majority 
of C++
 > programmers out there have no idea what's wrong:

Are you just referring to the lack of copy constructor and assignment 
operator, or is there something more subtle here?

  - Slime

Post a reply to this message

On 3/4/2012 14:33, Warp wrote:
>          return mData[index];

Given the previous discussion, I'm betting this is the error Warp was 
talking about - returning the address of a variable that gets disposed when 
this object gets disposed. It's basically the same bug - scopes exceeding 
lifetimes.  I'm amused that Ada actually prevents this bug unless you 
explicitly say "Yes, yes, I'm intentionally assigning a value to a pointer 
whose lifetime is shorter than that of the pointer."

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Le 05/03/2012 01:10, Darren New a écrit :
> On 3/4/2012 14:33, Warp wrote:
>>          return mData[index];
> 
> Given the previous discussion, I'm betting this is the error Warp was
> talking about - returning the address of a variable that gets disposed
> when this object gets disposed. It's basically the same bug - scopes
> exceeding lifetimes.  I'm amused that Ada actually prevents this bug
> unless you explicitly say "Yes, yes, I'm intentionally assigning a value
> to a pointer whose lifetime is shorter than that of the pointer."
> 

I doubt it a bit. It would be at worst an issue with the
copy-constructor of Value_t (if any), but I would think (maybe wrongly)
that due to the prototype of the function (returning a reference to
Value_t), the mData[index] is actually the real reference (compiler
handling the issue of &/* for us here).

One real bug is when used with the following code:

int foobar()
{
 Array<int> foo(3);
 foo[0] = 3;
 foo[1] = 7;
 foo[2] = 0;
 {
 Array<int> bar(foo); // get a copy of foo
 bar[2] = bar[1] + bar[0]; // no problem, it's 3+7
 }
 foo[2] += foo[1] * foo[0];     // you might crash here already
 return foo[2];     // these result is going to be surprising sometime
}                   // you definitely have a problem with glibc here!

Same kind of issue might happen if you provide Array<> to methods by
values without const (hence needed some copy-constructor... and the call
to the destructor for the intermediate objects)

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message