pthread/queue.yml: Property unintentionally weak?

While playing around with tasks to get a feel for an idea of ours, I realized (after about 1h of staring at it) that the task queue.yml has an assertion that is somewhat weaker than expected and can easily be misunderstood.

It simulates a queue by enqueuing and dequeuing things and keeps a shadow array of things that have been enqueued and dequeued and then (I would guess) wants to check that one gets out what one put it. Unfortunately, the check comparing those is flawed:

if (!dequeue(&queue) == stored_elements[i])
{
  reach_error();
}

This performs a logical negation on the result of dequeue and then compares with the shadow data structure. So as long as I get any non-zero value out of the queue if I put in a non-zero value, reach_error is not called.

(It can be called because of the actual concurrency issue, where i is advanced too far, and stored_elements[i] is 0 as initialized, provided the enqueued value was not 0).

Of course, there's no problem with having this very specific assertion in the task. However, we might also want to have a version that patches this and checks if(dequeue(&queue) != stored_elements[i]) and thus is more strict about the results of dequeue, and would more closely match the intention behind having a queue.

(My guess for why this task is like that is that someone forgot parens).

If desired, I can prepare copies of the queue tasks with stronger assertions (maybe even for this year depending on the freezing deadline).