passing invalid datatype

Discussion in 'C Programming' started by mchoube@gmail.com, Mar 6, 2008.

  1. Guest

    Hi,

    if this post is off topic here so please pardon me and point to the
    correct group.

    we are in a process of testing our SDK from 'Security' point. we have
    indentified few test cases but i feel some are invalid scenarios. i
    will share the scenarios here please comment with your opnion(s).

    the API has following prototype:

    /**
    * The name property is normally a user defined string that is used as
    a human
    * readable replacement for the schedule ID. This can be considered
    the "file
    * name" of the schedule. This should be used for display only, as
    actually
    * storing the schedule by name would require the file name to be
    unique, which
    * the schedule doesn't guarantee. The schedule ID property should be
    used to
    * identify the schedule.
    *
    * @param newVal [in] - The new schedule name.
    *
    * @return sig_result
    *
    * <dl>
    * <dt>SIG_S_OK</dt>
    * <dd>Method Call was successful.</dd>
    *
    * <dt>SIG_E_POINTER</dt>
    * <dd>The newVal parameter was a NULL pointer.</dd>
    * </dl>
    *
    * @see get_Name
    */
    sig_result put_Name (const wchar_t* newVal);

    the scenarios (which i think invalid test cases):

    1. passing 'char *' variable as parameter to put_Name () instead of
    'wchar_t *'.
    2. passing 'long *' variable as parameter to put_Name () instead of
    'wchar_t *'.

    are the above test cases valid? my argument is that the compiler does
    give you a warning so you should be fixing it instead of passing 'char
    *' or 'long *'. how can we check the datatype of the parameter passed
    in the API?

    any help is greatly appreciated.

    Thanks,
    Mehul
    , Mar 6, 2008
    #1
    1. Advertising

  2. Richard Bos Guest

    wrote:

    > 1. passing 'char *' variable as parameter to put_Name () instead of
    > 'wchar_t *'.
    > 2. passing 'long *' variable as parameter to put_Name () instead of
    > 'wchar_t *'.
    >
    > are the above test cases valid?


    No.

    > my argument is that the compiler does give you a warning so you should
    > be fixing it instead of passing 'char *' or 'long *'.


    Yes.

    > how can we check the datatype of the parameter passed in the API?


    You can't. Once inside the function, what you have, from C's POV, is a
    wchar_t *, however brokenly that may have been generated.

    Richard
    Richard Bos, Mar 6, 2008
    #2
    1. Advertising

  3. (Richard Bos) writes:
    > wrote:
    >> 1. passing 'char *' variable as parameter to put_Name () instead of
    >> 'wchar_t *'.
    >> 2. passing 'long *' variable as parameter to put_Name () instead of
    >> 'wchar_t *'.
    >>
    >> are the above test cases valid?

    >
    > No.
    >
    >> my argument is that the compiler does give you a warning so you should
    >> be fixing it instead of passing 'char *' or 'long *'.

    >
    > Yes.
    >
    >> how can we check the datatype of the parameter passed in the API?

    >
    > You can't. Once inside the function, what you have, from C's POV, is a
    > wchar_t *, however brokenly that may have been generated.


    If you pass a foo* argument to a function expecting a bar*, and types
    foo and bar are incompatible, then that's a constraint violation, and
    a diagnostic is required.

    But wchar_t is a typedef for some integer type, and it *could* be
    compatible with either char or long, depending on the implementation.
    Suppose <stddef.h> in a particular implementation has

    typedef long wchar_t;

    Since a typedef creates an alias, not a new type, long* and wchar_t*
    are *the same type* in this implementation, and there is no way to
    detect the (possible) error of passing a long* to a function expecting
    a wchar_t*.

    But if the implementation instead has

    typedef unsigned short wchar_t;

    then the same call is a constraint violation, requiring a diagnostic.

    In neither case can you do any meaningful run-time check within the
    function.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Mar 6, 2008
    #3
  4. wrote:
    > Hi,
    >
    > if this post is off topic here so please pardon me and point to the
    > correct group.
    >
    > we are in a process of testing our SDK from 'Security' point. we have
    > indentified few test cases but i feel some are invalid scenarios. i
    > will share the scenarios here please comment with your opnion(s).
    >
    > the API has following prototype:
    >
    > /**
    > * The name property is normally a user defined string that is used as
    > a human
    > * readable replacement for the schedule ID. This can be considered
    > the "file
    > * name" of the schedule. This should be used for display only, as
    > actually
    > * storing the schedule by name would require the file name to be
    > unique, which
    > * the schedule doesn't guarantee. The schedule ID property should be
    > used to
    > * identify the schedule.
    > *
    > * @param newVal [in] - The new schedule name.
    > *
    > * @return sig_result
    > *
    > * <dl>
    > * <dt>SIG_S_OK</dt>
    > * <dd>Method Call was successful.</dd>
    > *
    > * <dt>SIG_E_POINTER</dt>
    > * <dd>The newVal parameter was a NULL pointer.</dd>
    > * </dl>
    > *
    > * @see get_Name
    > */
    > sig_result put_Name (const wchar_t* newVal);
    >
    > the scenarios (which i think invalid test cases):
    >
    > 1. passing 'char *' variable as parameter to put_Name () instead of
    > 'wchar_t *'.
    > 2. passing 'long *' variable as parameter to put_Name () instead of
    > 'wchar_t *'.
    >
    > are the above test cases valid? my argument is that the compiler does
    > give you a warning so you should be fixing it instead of passing 'char
    > *' or 'long *'. how can we check the datatype of the parameter passed
    > in the API?
    >
    > any help is greatly appreciated.
    >
    > Thanks,
    > Mehul


    In C++, you should be able to write overloaded functions taking char *
    and long *. In C, you can write functions wputName(long *) and
    putName(char *).

    Optimally, the program passing the value would pass a wchar_t *, as that
    code would be more portable.

    --
    --Falcon Kirtaran
    Falcon Kirtaran, Mar 7, 2008
    #4
  5. Richard Bos Guest

    Keith Thompson <> wrote:

    > (Richard Bos) writes:
    > > wrote:
    > >> 1. passing 'char *' variable as parameter to put_Name () instead of
    > >> 'wchar_t *'.
    > >> 2. passing 'long *' variable as parameter to put_Name () instead of
    > >> 'wchar_t *'.
    > >>
    > >> are the above test cases valid?

    > >
    > > No.


    > If you pass a foo* argument to a function expecting a bar*, and types
    > foo and bar are incompatible, then that's a constraint violation, and
    > a diagnostic is required.
    >
    > But wchar_t is a typedef for some integer type, and it *could* be
    > compatible with either char or long, depending on the implementation.


    In which case they might be valid test cases for that implementation;
    but even then, that does not make them valid test cases _for this SDK_,
    which the OP was asking about.

    Richard
    Richard Bos, Mar 7, 2008
    #5
  6. (Richard Bos) writes:
    > Keith Thompson <> wrote:
    >> (Richard Bos) writes:
    >> > wrote:
    >> >> 1. passing 'char *' variable as parameter to put_Name () instead of
    >> >> 'wchar_t *'.
    >> >> 2. passing 'long *' variable as parameter to put_Name () instead of
    >> >> 'wchar_t *'.
    >> >>
    >> >> are the above test cases valid?
    >> >
    >> > No.

    >
    >> If you pass a foo* argument to a function expecting a bar*, and types
    >> foo and bar are incompatible, then that's a constraint violation, and
    >> a diagnostic is required.
    >>
    >> But wchar_t is a typedef for some integer type, and it *could* be
    >> compatible with either char or long, depending on the implementation.

    >
    > In which case they might be valid test cases for that implementation;
    > but even then, that does not make them valid test cases _for this SDK_,
    > which the OP was asking about.


    They're necessarily not invalid test cases, they're just difficult to
    test.

    If wchar_t is a typedef for long, then passing something explicitly
    declared as type long* to a function that expects a wchar_t* is almost
    certainly a bug, but it's a bug that won't be caught by the compiler.
    Detecting such bugs is tricky. One possibility might be to do the
    test on multiple compilers, and consider the test to pass if at least
    one of them detects it.

    Whether this kind of thing should be considered a test case for
    put_Name() is another question (and not really a C question, so I
    won't attempt to answer it).

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Mar 7, 2008
    #6
  7. Richard Bos Guest

    Keith Thompson <> wrote:

    > (Richard Bos) writes:
    > > Keith Thompson <> wrote:
    > >> (Richard Bos) writes:
    > >> > wrote:
    > >> >> 1. passing 'char *' variable as parameter to put_Name () instead of
    > >> >> 'wchar_t *'.
    > >> >> 2. passing 'long *' variable as parameter to put_Name () instead of
    > >> >> 'wchar_t *'.
    > >> >>
    > >> >> are the above test cases valid?
    > >> >
    > >> > No.

    > >
    > >> If you pass a foo* argument to a function expecting a bar*, and types
    > >> foo and bar are incompatible, then that's a constraint violation, and
    > >> a diagnostic is required.
    > >>
    > >> But wchar_t is a typedef for some integer type, and it *could* be
    > >> compatible with either char or long, depending on the implementation.

    > >
    > > In which case they might be valid test cases for that implementation;
    > > but even then, that does not make them valid test cases _for this SDK_,
    > > which the OP was asking about.

    >
    > They're necessarily not invalid test cases, they're just difficult to
    > test.


    Oh, the cases can be tested, all right. And having done that, you'll
    have learned
    - about the implementation:
    - whether its wchar_t is a long, a char, or neither, and/or:
    - whether it is clever enough to warn or not warn about this, as
    appropriate;
    - about the library:
    - the square root of sod-all.

    Since the OP, AFAICT, wants to test the library, not the implementation,
    they are not valid test cases _for his purpose_. They may be valid test
    cases for an implementation's conformance or for the taste of my quince
    jelly, but neither of those is relevant to what the OP is looking for.

    Richard
    Richard Bos, Mar 12, 2008
    #7
    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. Patrick.O.Ige
    Replies:
    1
    Views:
    1,938
    Patrick.O.Ige
    Jul 2, 2006
  2. Java Guy
    Replies:
    1
    Views:
    665
    Manish Pandit
    Oct 15, 2006
  3. Jeff
    Replies:
    2
    Views:
    1,123
    Steve C. Orr [MCSD, MVP, CSM, ASP Insider]
    Apr 16, 2007
  4. kevin
    Replies:
    0
    Views:
    953
    kevin
    Jan 16, 2008
  5. Java Guy
    Replies:
    1
    Views:
    290
Loading...

Share This Page