Re: Tips to analyze a project with thousands of files

Discussion in 'C++' started by Werner, Oct 24, 2012.

  1. Werner

    Werner Guest

    On Saturday, October 20, 2012 7:07:35 AM UTC+2, Like Learn wrote:
    > My task is to analyze a legacy firmware project using Qualcomm MDM9X00
    >
    > baseband chip with thousands of files (literally) to fix a bug. There is no
    >
    > design documents about the project. The project is qriting in C++, halve of
    >
    > them are commented in Doxygen format, while the other halve not.

    [snip]

    - Compile with various compilers with high warning levels, and allow
    no warnings (even if it takes explicitly disabling some that you
    understand).
    - Replace all sprintf's and printf's and functions taking varargs
    with something that is typesafe, alternatively check each one. I
    think the gcc compiler actually warns when this is used wrong.
    - Replace all memcpy and strcpy functions with typesafe
    alternatives.
    - Verify your inputs, especially inputs that realize to (cause)
    strings.
    - Check conversion between signed and unsigned, especially those
    that calculate buffer sizes, and are used as arguments to
    strncpcy/memcpy (which should not be used anyway)...
    - Check all bald pointers. Make sure they are at least initialized.
    (I use a lightweight pointer wrapper to ensure this).
    - Ensure that RAII is employed everywhere if not GC exists
    (I've no experiene with other forms of garbage collection). This
    means wrapping all bald pointers anyway.

    Kind regards,

    Werner

    Regards,

    Werner
     
    Werner, Oct 24, 2012
    #1
    1. Advertising

  2. Werner

    Jorgen Grahn Guest

    On Wed, 2012-10-24, Werner wrote:
    > On Saturday, October 20, 2012 7:07:35 AM UTC+2, Like Learn wrote:
    >> My task is to analyze a legacy firmware project using Qualcomm MDM9X00
    >>
    >> baseband chip with thousands of files (literally) to fix a bug. There is no
    >> design documents about the project. The project is qriting in C++, halve of
    >> them are commented in Doxygen format, while the other halve not.

    > [snip]
    >
    > - Compile with various compilers with high warning levels, and allow
    > no warnings (even if it takes explicitly disabling some that you
    > understand).
    > - Replace all sprintf's and printf's and functions taking varargs
    > with something that is typesafe, alternatively check each one. I
    > think the gcc compiler actually warns when this is used wrong.


    It does, and you can tell it "this function of mine takes
    printf-like arguments, please check it too".

    > - Replace all memcpy and strcpy functions with typesafe
    > alternatives.


    - Do the same for bzero(), memcmp(), memset(), ... most functions
    which deal with void*.

    - Audit the C-style casts (g++ -Wold-style-cast).

    > - Verify your inputs, especially inputs that realize to (cause)
    > strings.
    > - Check conversion between signed and unsigned, especially those
    > that calculate buffer sizes, and are used as arguments to
    > strncpcy/memcpy (which should not be used anyway)...
    > - Check all bald pointers. Make sure they are at least initialized.
    > (I use a lightweight pointer wrapper to ensure this).
    > - Ensure that RAII is employed everywhere if not GC exists
    > (I've no experiene with other forms of garbage collection). This
    > means wrapping all bald pointers anyway.


    - Apply 'const' to increase readability.

    - Look for small bunches of related data which should be small
    classes. People tend to write the big, long-lived classes and
    leave the small things as 'int', even if they have very specific
    behavior (e.g. statistics counters which start at 0 and only can be
    incremented).

    That (what I listed, and almost all of what Werner listed) is some of
    the things I try to do when I work with legacy code.

    Although your situation may be different ... if for example
    you're doing the maintenance on old releases and some other
    team is doing new development, noone will thank you for doing
    drastic changes. Unfortunately.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 25, 2012
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ******ãÊÝÜÜÜÜÜÜÜÇÆÜÜÜÜÜÜá******

    Enjoy Thousands Of Tips and Trikes

    ******ãÊÝÜÜÜÜÜÜÜÇÆÜÜÜÜÜÜá******, Jul 27, 2010, in forum: Python
    Replies:
    0
    Views:
    227
    ******ãÊÝÜÜÜÜÜÜÜÇÆÜÜÜÜÜÜá******
    Jul 27, 2010
  2. Jorgen Grahn
    Replies:
    1
    Views:
    403
    Jorgen Grahn
    Oct 21, 2012
  3. Öö Tiib
    Replies:
    0
    Views:
    354
    Öö Tiib
    Oct 20, 2012
  4. Replies:
    1
    Views:
    368
    Jorgen Grahn
    Oct 21, 2012
  5. Stuart
    Replies:
    0
    Views:
    391
    Stuart
    Oct 23, 2012
Loading...

Share This Page