I love it! Thanks, this was stopped me from compiling the tests (since some commit not long ago I guess, because I could before).
Just one remark. In one test _PREHASH_AgentID is set to "AgentID" (no doubt a place holder), while in the other you set it to 0 (now needed because it's a const). Perhaps a more symmetric approach is better?  I'd opt for setting the other also to a random string, like "Grumpity Productengine", or "Aleric Inglewood" now I think about it. Other options are "All Your Base Are Belong To Us" and "Hi mom!". Got be SURE they aren't used though -- don't want any new 'Grumpity' embarrashments :p

> Just one remark. In one test _PREHASH_AgentID is set to "AgentID"
> (no doubt a place holder), while in the other you set it to 0
> (now needed because it's a const). Perhaps a more symmetric approach
> is better?

indra/llui/tests/llurlentry_stub.cpp (Diff revision 1)

This test already contained these placeholder strings, so I just left it at that, only adapting the types.

indra/newview/tests/llremoteparcelrequest_test.cpp (Diff revision 1)

In this test here, however, I think the pointers actually ended up undefined in the original code, so setting them to NULL was the closest I possibility could think off.

As building succeeded with this, I concluded that these pointers are passed around but never dereferenced during the test.[*] I feel setting nullpointers nicely signals that fact, though it should probably be augmented by a
	// never used during this test
or
	// never dereferenced in this test
comment to make that intent clear.

I agree though, that we should try to handle this similarly in both tests, if possible. So I tried setting the pointers in indra/llui/tests/llurlentry_stub.cpp to NULL, too, which works nicely.

However, I then realized that the tested code might have nullpointer guards around dereferencing code, so that if we pass nullpointers we are actually testing another scenario than when passing pointers to actual data and that this might be the reason why no null-pointer exceptions occur during the tests.

Of course, we could now examine the tested code to see whether this is the case. However, it would be a bad idea to adapt the test code based on that examination, as the tested code might be changed later without this question being re-evaluated and the test rewritten accordingly.

Is there another pointer value besides NULL (thus not usually tested for) that still fails reliably when tried to dereference?

----
[*] Remember that tests are executed when building and are hopefully completely deterministic, so that any potential null-pointer-exception would have shown up.

Not a fan of widespread cleanup changes as I said in a previous review, but if this is getting rid of compilation errors on some machines, I'm all for it. 

As already mentioned in the review request description, comments in message_prehash.h and message_prehash.cpp claim that these files have been generated:

indra/llmessage/message_prehash.h (Diff revision 2)

indra/llmessage/message_prehash.cpp (Diff revision 2)

Do we have to expect them to be re-generated again in the future? If so, the code for generating them should be changed alongside the change I propose here, so that future generations (pun intended) won't  inadvertently override and revert the change.

At first, I thought the code for generating them was not part of the source tree, but now I think I have located it in indra/llmessage/message.cpp. (I would have expected it to be a script, not a compiled program.) I will investigate this further and augment the review request with a change to the generating code, too, if applicable.

Latest diff looks good. Great that you found the generator for this code!

If the file is generated, what is it doing checked into the source tree at all?  This sounds to me like an invitation to future errors.

Is there some reason why we should not just delete the checked in version and have it generated every time it's needed?

Given that Boroondas reports that the message.cpp in the viewer source tree does not produce the same generated file as what we have checked in, and Q's comment that this shared code, should we remove the message.cpp from this tree and just use the generated file?  Would that break tests?

It seems axiomatic to me that there should only be one source for this - if the authoritative one is the one in the simulator sources, that's fine, but there should only be one.

I don't like the idea of making changes (however good they are, and I agree that the new declarations are cleaner) that are not in sync with the server side.

I'm ok with changing declarations of some pointers to _PREHASH_ strings and setting them to NULL as they are not de-referenced and not really used in tests now. But I'm not sure about changes to code generating all the other _PREHASH_ declarations because it's not yet clear how they should be re-generated.