[opensource-dev] Review Request: make PREHASH variables char const* const

[Seth ProductEngine]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/100/#review259
-----------------------------------------------------------


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.

- Seth


On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/100/
> -----------------------------------------------------------
> 
> (Updated Jan. 22, 2011, 7:40 a.m.)
> 
> 
> Review request for Viewer and Seth ProductEngine.
> 
> 
> Summary
> -------
> 
> For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522
> 
> What I did:
> In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining.
> 
> Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. Because this generation might not have been a one-off thing, I changed the generating code, too, so it won't override this change here when the generation happens the next time. However, that part of the code is not called by Viewer, although the relevant function — dump_prehash_files() — ends up in the Viewer binary. That function probably gets called by the simulator, when one runs the latter with -prehash. (See https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 )
> 
> 
> This addresses bug VWR-24487.
>     http://jira.secondlife.com/browse/VWR-24487
> 
> 
> Diffs
> -----
> 
>   doc/contributions.txt fc7e5dcf3059 
>   indra/llmessage/message.cpp fc7e5dcf3059 
>   indra/llmessage/message_prehash.h fc7e5dcf3059 
>   indra/llmessage/message_prehash.cpp fc7e5dcf3059 
>   indra/llprimitive/llprimitive.h fc7e5dcf3059 
>   indra/llprimitive/llprimitive.cpp fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.h fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 
>   indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 
>   indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 
> 
> Diff: http://codereview.secondlife.com/r/100/diff
> 
> 
> Testing
> -------
> 
> Compiled (standalone, 64bit Linux) with and without LL_TESTS.
> Started the viewer, logged in, walked and flew around a bit. Everything seems to work.
> 
> 
> Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed.
> 
> Locally invoked start_messaging_system() with b_dump_prehash_file == true instead of FALSE, to see what would be generated after my change to dump_prehash_files().
> The message_prehash.(h|cpp) generated by that had the correct type qualifiers and formatting, but some lines were removed or added compared to the modified files from the source tree. That probably means that the files aren't fully synchronized with the message template file in the source tree. Because the "added" constants are spread all over the file, while the "removed" ones were at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree are actually more up-to-date than the message template file in the source tree.
> 
> 
> Thanks,
> 
> Boroondas
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110126/3d057c0f/attachment.htm