Good test program that special malloc!
Ack
Mathi.

----- [email protected] wrote:

> Summary: clm: Ensure SaNameT strings are NUL-terminated [#1056]
> Review request for Trac Ticket(s): 1056
> Peer Reviewer(s): Mathi
> Pull request to: 
> Affected branch(es): opensaf-4.5.x, default(4.6)
> Development branch: default
> 
> --------------------------------
> Impacted area       Impact y/n
> --------------------------------
>  Docs                    n
>  Build system            n
>  RPM/packaging           n
>  Configuration files     n
>  Startup scripts         n
>  SAF services            y
>  OpenSAF services        n
>  Core libraries          n
>  Samples                 n
>  Tests                   n
>  Other                   n
> 
> 
> Comments (indicate scope for each "y" above):
> ---------------------------------------------
> 
> changeset 2886df6251953185dea87d5b121ddfe740154010
> Author:       Anders Widell <[email protected]>
> Date: Thu, 11 Sep 2014 12:51:24 +0200
> 
>       clm: Ensure SaNameT strings are NUL-terminated [#1056]
> 
>       CLM uses the SaNameT structure for output parameters (in various
> data
>       structures), but it did not guarantee that the string inside the
> SaNameT
>       structure was NUL-terminated. This meant that these SaNameT
> structures could
>       not safely be read using the saAisNameBorrow() function.
> 
>       Code has been added to the clm agent to ensure proper NUL termination
> in
>       SaNameT structures.
> 
> 
> Complete diffstat:
> ------------------
>  osaf/libs/agents/saf/clma/clma_api.c   |  3 +++
>  osaf/libs/common/clmsv/clmsv_enc_dec.c |  2 ++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> 
> Testing Commands:
> -----------------
> Use CLM interfaces that produce SaNameT as output. In order to trigger
> the bug
> I used a special malloc() function that fills the allocated memory
> with non-zero
> bytes.
> 
> 
> Testing, Expected Results:
> --------------------------
> SaNameT output from CLM shall contain NUL-terminated strings.
> 
> 
> Conditions of Submission:
> -------------------------
> Ack from Mathi
> 
> 
> Arch      Built     Started    Linux distro
> -------------------------------------------
> mips        n          n
> mips64      n          n
> x86         n          n
> x86_64      y          y
> powerpc     n          n
> powerpc64   n          n
> 
> 
> Reviewer Checklist:
> -------------------
> [Submitters: make sure that your review doesn't trigger any
> checkmarks!]
> 
> 
> Your checkin has not passed review because (see checked entries):
> 
> ___ Your RR template is generally incomplete; it has too many blank
> entries
>     that need proper data filled in.
> 
> ___ You have failed to nominate the proper persons for review and
> push.
> 
> ___ Your patches do not have proper short+long header
> 
> ___ You have grammar/spelling in your header that is unacceptable.
> 
> ___ You have exceeded a sensible line length in your
> headers/comments/text.
> 
> ___ You have failed to put in a proper Trac Ticket # into your
> commits.
> 
> ___ You have incorrectly put/left internal data in your
> comments/files
>     (i.e. internal bug tracking tool IDs, product names etc)
> 
> ___ You have not given any evidence of testing beyond basic build
> tests.
>     Demonstrate some level of runtime or other sanity testing.
> 
> ___ You have ^M present in some of your files. These have to be
> removed.
> 
> ___ You have needlessly changed whitespace or added whitespace crimes
>     like trailing spaces, or spaces before tabs.
> 
> ___ You have mixed real technical changes with whitespace and other
>     cosmetic code cleanup changes. These have to be separate commits.
> 
> ___ You need to refactor your submission into logical chunks; there
> is
>     too much content into a single commit.
> 
> ___ You have extraneous garbage in your review (merge commits etc)
> 
> ___ You have giant attachments which should never have been sent;
>     Instead you should place your content in a public tree to be
> pulled.
> 
> ___ You have too many commits attached to an e-mail; resend as
> threaded
>     commits, or place in a public tree for a pull.
> 
> ___ You have resent this content multiple times without a clear
> indication
>     of what has changed between each re-send.
> 
> ___ You have failed to adequately and individually address all of the
>     comments and change requests that were proposed in the initial
> review.
> 
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
> 
> ___ Your computer have a badly configured date and time; confusing
> the
>     the threaded patch review.
> 
> ___ Your changes affect IPC mechanism, and you don't present any
> results
>     for in-service upgradability test.
> 
> ___ Your changes affect user manual and documentation, your patch
> series
>     do not contain the patch that updates the Doxygen manual.

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to