passing invalid datatype

[mchoube]

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

 

[Richard Bos]

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

 

[Keith Thompson]

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.

 

[Falcon Kirtaran]

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.

 

[Richard Bos]

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

 

[Keith Thompson]

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).

 

[Richard Bos]

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