STRIDE Wiki - User contributions [en]

Studio:Scripting Overview

2008-02-29T01:06:28Z

Root: New page: STRIDE affords you a number of different options for automating your testing, including datasets and scripts. Each option provides a unique set of testing capabilities. When conditional...

STRIDE affords you a number of different options for automating your

testing, including datasets and scripts. Each option provides a unique

set of testing capabilities. When conditional logic, event processing,

user intervention, or other complex operations are required, scripts may

be the most appropriate option.

Using scripts to drive test scenarios or to simulate missing components

has traditionally been difficult, if not impossible, when the unit under

test is located on the target platform. Moreover, scripting languages

and the C language do not necessarily mix well. Because of these difficulties,

developers rarely use scripts for testing and integration, despite the

potential benefits.

STRIDE makes it possible to use scripts written in any scripting language

to test your software units regardless of whether they are located on

the host, target, or both. There are two common use cases for using scripts

to integrate and test:

* To drive the testing of a unit or units by calling functions

and/or sending commands and receiving messages.
* To simulate a missing function or other component so an interdependent
unit can be tested.

To illustrate these two use cases, consider a hypothetical embedded

application containing three functions: A, B, and C. A calls B and B calls

C as shown on the left in the diagram below. Suppose that you developed

function B and you are ready to test it, but function C is not yet completed.

One solution, which would allow you to continue testing regardless of

the availability of function C, is to use scripts as shown on the right

in the diagram below. One script simulates the missing function C (Use

Case #2) while the other drives the testing of function B (Use Case #1).

[[Image:Overview_Scripting.png]]

As implied in the diagram, the fact that scripts replace functions A

and C does not change the interfaces with function B; via STRIDE, interfaces

defined in your embedded application are available at the source level

in your favorite scripting language. In addition, function B could be

on the target application, whereas the scripts replacing functions A and

C are running on the host.

Main Page

2008-02-28T19:44:50Z

Root:

Welcome to the new S2 Technologies™ '''STRIDE'''™''' Support Wiki'''.

This site is currently a '''WORK IN PROGRESS'''. It is expected to be available for general consumption by end of February (2008) with the STRIDE '''Moonlight''' beta release.
Customer additions are welcome and encouraged. Please read the '''[[S2 Wiki Support|S2 Wiki Support Policies]]''', '''[[Help:How to add a topic|How to add a topic]]''' and '''[[Help:Contents|Help]]''' pages for guidelines and instructions on editing. You must '''[[Special:Userlogin|log in or create an account]]''' before you can edit a page.

Please select a topic or category heading below, or enter a search string in the Search field to the left.

----

{|
{|
| valign="top" |
{|cellpadding="2" cellspacing="5" style="vertical-align:top;border:1px solid #bcc"
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Deploying STRIDE|Deploying STRIDE]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Test Utilities|Test Utilities]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Frameworks|Frameworks]]
|-
| valign="top"|
* [[Installing STRIDE]]
* [[Integrating STRIDE]]
* [[Verifying Installation]]
* [[Proof of Concept]]
* [[Framework| Framework]]
* [[Training]]
| valign="top"|
* [[Host Apps]]
* [[Test Classes]]
* [[Test Functions]]
* [[Test Runners]]
* [[Components]]
* [[Templates]]
| valign="top"|
* [[Using Frameworks]]
* [[Creating Frameworks]]
* [[Provided Frameworks]]
* [[Using Packages]]
* [[Creating Packages]]
* [[Provided Packages]]

|-
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Training|Training]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Application Notes|Application Notes]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Release Notes|Release Notes]]
|-
| valign="top" |
*[[Overview]]
*[[STRIDE Quick Start]]
*[[Target Test Code]]
*[[Interface Instrumentation]]
*[[Test Scripts]]
| valign="top"|
*[[:Category:SCL|SCL]]
*[[:Category:Scripting|Scripting]]
*[[:Category:Troubleshooting|Troubleshooting]]
*[[:Category:FAQ|FAQ]]
*[[New Appnotes Docs]]

| valign="top"|
* [[STRIDE 2.1.00xx | STRIDE 2.1.00xx (D Street)]]
* [[2.1.0201 | STRIDE 2.1.02xx (Moonlight)]]
|}
|}
|-

Category:SCL

2008-02-05T23:56:12Z

Root: /* Where should these topics go? */

===Pointers===
* [[Can STRIDE marshal both data and pointers?]]
* [[Can an array be cast to a pointer?]]
* [[Casting and pointers]]
* [[Accessing target data while processing a proxy call]]

===Arrays===
* [[How do I apply an SCL pragma to an array?]]
* [[Assigning array elements]]
* [[How does the STRIDE compiler handle zero-length arrays?]]

===Callbacks===
* [[Accessing the return value of a function using scripting]]
* [[Are multiple callbacks possible?]]
* [[Callback functions in Perl scripts]]

===Workarounds===
* [[How do I work around variable arguments for stubs?]]
* [[Understanding SCL conflicts]]

===Unions===
* [[Applying pragmas up and down type chains]]

===Miscellaneous SCL topics===
* [[Working with "default" candidates]]
* [[Advantages and disadvantages of "default" candidates]]

Studio:Working with "default" candidates

2008-02-05T23:55:44Z

Root:

scl_ptr_flist() serves as a "shorthand" method of declaring a "default" candidate. 
'''Note''': When using scl_ptr_flist() to define candidates, the function pointer prototypes are defined internally within STRIDE, rather than by the user. 

'''Example''' 
<tt>// function pointer typedef 
typedef void (*FPtr) (int, char); 
void foo(FPtr *pFPtr); 
void foo1(FPtr *pFPtr); 
void foo2(FPtr *pFPtr); 
void foo3(FPtr *pFPtr); 
// candidate prototypes 
void C1(int x, char y); 
void C2(int x, char y); 
void C3(int x, char y); 
// pragmatize candidate prototypes 
#pragma scl_function(C1) 
#pragma scl_function(C2) 
#pragma scl_function(C3) </tt>

'''How to declare a "default" candidate using scl_ptr_flist()''' 
There are several methods of declaring a "default" candidate using scl_ptr_flist(). Each method is explained below. 
'''Method 1: Candidate list declaration using predefined function prototypes'''
<tt>#pragma scl_function(foo) 
#pragma scl_ptr_flist(*foo.pFPtr, C1, C2, C3)</tt> 

The candidates' (C1, C2, C3) prototypes are defined and pragmatized, and proxies/stubs will be generated. In the parent function (the function that contains the function pointer PFptr) will use a for loop to search through the static table to bind the function pointer with the SMID or vice versa. The command and response payloads of the candidate functions (C1, C2, C3) can be captured via tracing.
 
'''Method 2: Candidate list declaration using shorthand method'''
<tt>#pragma scl_function(foo1) 
#pragma scl_ptr_flist(*foo1.pFPtr, "cand1") </tt>

"Default" proxies/stubs will be generated for the name in quotes in scl_ptr_flist() "cand1" in the example above. The command and response payloads of the candidate functions (e.g., "cand1") can be captured via tracing. 
 
'''Method 3: Candidate list declaration using combination of predefined functions and shorthand method'''
 
<tt>#pragma scl_function(foo2)
#pragma scl_ptr_flist(*foo2.pFPtr, "cand4", C2)</tt> 

The candidate "cand4" is interpreted by STRIDE as follows: 

<tt> void cand4(int p1, char p2); 
#pragma scl_function(cand4)</tt> 

"Default" proxies/stubs will be generated for the name in quotes in scl_ptr_flist() "cand4" in the example above. The command and response payloads of the candidate functions (e.g., "cand4") can be captured via tracing. 
 
'''Method 4: "Default" candidate declaration''' 
<tt>#pragma scl_function(foo3) 
#pragma scl_ptr_flist(*foo3.pFPtr, "def_cand")</tt> 

The candidate "def_cand" is interpreted by STRIDE as follows: 
<tt>void def_cand(int p1, char p2); 
#pragma scl_function(def_cand)</tt> 

A "default" proxy/stub will be generated for def_cand. The parent function will not use a for loop and the proxy will replace the existing function pointer in the table with the passed-in function pointer. The command and response payloads of any function prototype with the identical signature to def_cand can be captured via tracing.

Studio:Using printf

2008-02-05T23:55:24Z

Root:

In some cases, printf is a quick and easy way to add debug information to your code. When using STRIDE, it is helpful to have the printf output redirected to the trace view window, so that the printf output is in sequence with all the function calls, messages, and trace points. Having printf output sent to the trace views not only consolidates all the debug information into one place — the trace view — it also helps to understand the sequence of events.

STRIDE provides a simple runtime command, srTraceStr, which sends strings to the trace window; however, replacing printf statements with srTraceStr in the source code can require a great deal of effort, which may not be worth it. A much simpler option is to use a macro definition to globally replace printf with srTraceStr. In addition, srTraceStr and printf's argument lists do not match exactly; therefore, parameter mapping is required. srTraceStr's syntax is as follows: 
<tt>srEXPORT srWORD srSTDCALL srTraceStr( srWORD wSTID,
srCHAR *szString,
srLevel_e eLevel );</tt>

szString is the string to be displayed in the trace view. In addition, srTraceStr contains a filtering level for the host trace view. Since printf does not offer any level of trace view filtering, it can be mapped to a single level. In most cases, level 0 is appropriate since there is no need to filter printf statements; usually you want to see them, as they are generally there for a reason.

srTraceStr's other parameter, wSTID, is a bit more complicated. A STID has to be created before srTraceStr can be called. The following two options are available:
*A STID specific to the printf tracing could be created in the target initialization code. In other words, the “STRIDE printf” would have its own STID, allowing it to be easily filtered out in the trace view if required.
*Alternately, the STID used for the intercept module could be reused. Since the scope of the “IM STID” is limited to the xxxIM.c file, the “STRIDE printf” would have to be part of this file. The intercept module is automatically generated, and therefore should not be modified; however, the example below demonstrates how the “IM STID” can be reused without having to modify the automatically-generated intercept module code.

The following macro replaces printf with a function called stride_printf : 
<tt>#define printf stride_printf</tt>

Now we have to implement the stride_printf function. Since we replaced printf,we have to address variable arguments. The following example demonstrates a possible implementation: 
<tt>static __inline srWORD stride_printf(char *s, ...)
{
srWORD ret; 
va_list args; 
char str[MAX_STRIDE_PRINTF_SIZE]; 
va_start(args, s); 
sprintf(str, s, args); 
ret = srTraceStr (wSTID, (srCHAR*) str, srLEVEL_0); 
return ret; 
}</tt>

In the above example, the intercept module STID (wSTID) was used.

Now that we have made the change, the printf output will go to the STRIDE trace view — however, what if STRIDE is not being used but you still want to see the printf output? This can be done simply by adding a small function which allows switching between the normal printf and stride_printf; by exposing this interface in STRIDE, the output can be controlled regardless of whether or not you are using STRIDE.
<tt>void stride_printf_set(stride_printf_flag_t flag)
{ 
stride_printf_on = flag; 
}</tt> 

Now the STRIDE printf function has to change slightly to add a “normal” printf: 
<tt>srWORD stride_printf(char *s, ...)
{ 
srWORD ret = srOK; 
va_list args; 
char str[MAX_STRIDE_PRINTF_SIZE]; 
va_start(args, s); 
if ((!(stride_printf_on & STRIDE_PRINTF)) || 
(stride_printf_on & OS_PRINTF)) 
{ 
printf(s, args); 
} 
if (stride_printf_on & STRIDE_PRINTF) 
{ 
sprintf(str, s, args); 
ret = srTraceStr (wSTID, (srCHAR*) str, srLEVEL_0); 
} 
return ret; 
}</tt>

'''Sample header files''' 
Two header files are required in order to use printf to add debug information to your code: a header file which redefines printf to stride_printf, and a header file containing the stride_printf implementation as an inline function as well as the SCL pragmas for STRIDE.

'''Redefining printf to stride_printf''' 
This header file should be included in one of the general include files, which in turn is included in all the source files to limit source code modifications.
<tt>#ifndef STRIDE_PRINTF_H 
#define STRIDE_PRINTF_H 
#ifdef __cplusplus 
extern "C" { 
#endif 
#define MAX_STRIDE_PRINTF_SIZE 255 
#define OS_PRINTF 1 
#define STRIDE_PRINTF 2 
extern srWORD stride_printf(char *s); 
/* Redefine printf to stride_printf */ 
#define printf stride_printf 
#ifdef __cplusplus 
} 
#endif 
#endif /* STRIDE_PRINTF_H */</tt> 

'''Implementing stride_printf as an inline function and SCL pragmas''' 
The stride_printf_scl.h file is included in the STRIDE workspace. It contains the stride_printf implementation as an inline function as well as the SCL pragmas for STRIDE. 
<tt>#ifndef STRIDE_PRINTF_SCL_H 
#define STRIDE_PRINTF_SCL_H 
#ifdef __cplusplus 
extern "C" { 
#endif 
#include <stdio.h> 
#include <stdarg.h> 
#include "stride_printf.h" 
static unsigned char stride_printf_on = OS_PRINTF; 
extern srWORD wSTID; 
static __inline void stride_printf_set(unsigned char flag) 
{ 
stride_printf_on = flag; 
} 
#undef printf 
static __inline srWORD stride_printf(char *s, ...) 
{ 
srWORD ret = srOK; 
va_list args; 
va_start(args, s); 
if ((!(stride_printf_on & STRIDE_PRINTF)) || 
(stride_printf_on & OS_PRINTF)) 
{ 
printf(s, args); 
} 
if (stride_printf_on & STRIDE_PRINTF) 
{ 
char str[MAX_STRIDE_PRINTF_SIZE]; 
sprintf(str, s, args); 
ret = srTraceStr (wSTID, (srCHAR*) str, srLEVEL_0); 
} 
return ret; 
} 
#ifdef _SCL 
#pragma scl_function(stride_printf_set) 
#endif 
#ifdef __cplusplus 
} 
#endif 
#endif /* STRIDE_PRINTF_SCL_H */

Studio:How to generate a preprocessor (.i) file for analysis

2008-02-05T23:55:09Z

Root:

'''Preprocessing individual files'''

You can run the preprocessor on one or more header files to generate .i files, which can then be used for analysis. To do this from within Studio, select one or more top-level header files, right-click, and choose '''Preprocess'''. 
'''Note''': You will need to rename the file to have a .h extension.

Only the selected files are compiled, and preprocessed (.i) files are generated for them. During the compilation, the workspace settings for #defines and include paths are in effect. Existing databases are not affected. 
'''Note''': The #include <stdarg.h> will require the workspace to have a valid pointer (usually to the Microsoft C includes directory).

Studio:How do I access global variables?

2008-02-05T23:54:57Z

Root:

STRIDE allows you to call functions and send messages on the target, which is in most cases all you need for validation. However, in some cases it might be necessary to read or modify global variables or certain memory locations. If there are API functions available to access the global variables or read memory, those APIs could be exposed to STRIDE and used. If no such API calls are available, they can be added; this requires changes to the target code. Although STRIDE doesn’t directly support accessing target memory with simple helper functions, you can easily access target information without changing the target code by adding code to a header file containing SCL pragmas.

This header file would then be included in the STRIDE workspace, and therefore included in the intercept module. It would not be required to include the header file in any of the customer target code, nor would modifications to the customer code be required. Since the function is known to the intercept module and the intercept module is the only one calling the function, it could be static and therefore have no impact on the rest of the code. The following demonstrates a header file which is included in the STRIDE workspace and subsequently in the intercept module; the function is defined as static, since its scope is limited to the intercept module.

'''Example: Reading a number of bytes from the target'''

<code>static void SCL_get_num_bytes ( void *ptr, unsigned char* data, int num_bytes)</code> 
<code>{ </code> 
<code> memcpy ( data, ptr, num_bytes ); </code> 
<code>} </code>

'''Reading and writing global data'''

Another application is to read and write global data. For example, we could have a global state variable. Either the header file which defines the global state variable could be included, or an external definition could be added to the header file. The first option is preferred; in some cases the global state variable definition could be in a .c file.

'''Example: STRIDE header file'''

<code>/* extern definition for global */</code> 
<code>extern int global_state</code> 
<code>/* helper function to set the state */</code> 
<code>static void SCL_set_state(int state)</code> 
<code> { </code> 
<code> global_state = state; </code> 
<code> } </code> 
<code> /* helper function to get (read) the state */ </code> 
<code> static int SCL_get_state(void) </code> 
<code> { </code> 
<code> return global_state;</code> 
<code> } </code>

Studio:Delegating ISHELL SendEvent

2008-02-05T23:54:42Z

Root:

When trying to dynamically intercept a call for the application under test, intercepting only the call/method of interest was difficult when delegating the IShell Virtual Table, as it allows all methods to be intercepted for all callers. 

Delegating the user's call to the IShell helper macro ISHELL_SendEvent is a better method. ISHELL_SendEvent is defined in AEEShell.h as follows: 
<tt>#define ISHELL_SendEvent(p,cls,ec,wp,dw) 
GET_PVTBL(p,IShell)->SendEvent(p,0,cls,ec,wp,dw)</tt> 

This requires a small amount of instrumentation to the calling application, essentially to define the Group ID and include IM.h. You must also complete the following steps: 
<ol>
<li>Ensure that the calling application is using the helper macro to call the Send event.</li>
<li>Add the following code to the AEEShell.h file instead of the #ifdef _SCL conditional block:</li>
<tt>#undef ISHELL_SendEvent 
int ISHELL_SendEvent(IShell *po, AEECLSID cls, AEEEvent eCode, uint16 wParam, uint32 dwParam); 
#pragma scl_function(ISHELL_SendEvent) 
#pragma scl_ptr_opaque(ISHELL_SendEvent,po) </tt>
<li>Create a user-mangled dynamic delegate for the function ISHELL_SendEvent.</li>
<li>Add the instrumentation to the calling application's code:</li>
<tt>#ifdef srIMON 
#define <groupid-name> 
#include <name>IM.h 
#endif</tt> 

This allows you to dynamically intercept the call for the application under test.

Main Page

2008-02-05T22:01:54Z

Root:

Welcome to the new S2 Technologies™ '''STRIDE'''™''' Support Wiki'''.

This site is currently a '''WORK IN PROGRESS'''. It is expected to be available for general consumption by end of February (2008) with the STRIDE '''Moonlight''' beta release.
Customer additions are welcome and encouraged. Please read the '''[[S2 Wiki Support|S2 Wiki Support Policies]]''', '''[[Help:How to add a topic|How to add a topic]]''' and '''[[Help:Contents|Help]]''' pages for guidelines and instructions on editing. You must '''[[Special:Userlogin|log in or create an account]]''' before you can edit a page.

Please select a topic or category heading below, or enter a search string in the Search field to the left.

----

{|
{|
| valign="top" |
{|cellpadding="2" cellspacing="5" style="vertical-align:top;border:1px solid #bcc"
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Deploying STRIDE|Deploying STRIDE]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Test Utilities|Test Utilities]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Frameworks|Frameworks]]
|-
| valign="top"|
* [[Installing STRIDE]]
* [[Integrating STRIDE]]
* [[Verifying Installation]]
* [[Proof of Concept]]
* [[Framework| Framework]]
* [[Training]]
| valign="top"|
* [[Host Apps]]
* [[Test Classes]]
* [[Test Functions]]
* [[Test Runners]]
* [[Components]]
* [[Templates]]
| valign="top"|
* [[Using Frameworks]]
* [[Creating Frameworks]]
* [[Provided Frameworks]]
* [[Using Packages]]
* [[Creating Packages]]
* [[Provided Packages]]

|-
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Training|Training]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Application Notes|Application Notes]]
! style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:Release Notes|Release Notes]]
|-
| valign="top" |
*[[Overview]]
*[[Hello Stride]]
*[[Interface Instrumentation]]
*[[Target Test Code]]
*[[Test Scripts]]
| valign="top"|
*[[:Category:SCL|SCL]]
*[[:Category:Scripting|Scripting]]
*[[:Category:Troubleshooting|Troubleshooting]]
*[[:Category:FAQ|FAQ]]

| valign="top"|
* [[STRIDE 2.1.00xx | STRIDE 2.1.00xx (D Street)]]
* [[2.1.0201 | STRIDE 2.1.02xx (Moonlight)]]
|}
|}
|-

Studio:How to define message structures

2008-02-05T21:56:36Z

Root:

The following rules make it easier to process unions and select the active member(s) within a union or nested unions, as well as making it easier to transfer data between tasks.
* Have a one-to-one correlation between disciminants and union members.
* The order of enums for discriminants matches with the order of members within the union.
* In the case of nested unions, each union should have its own discriminant.
* Use inline data instead of pointers.

Below is an example:
<tt>typedef struct 
{ 
DEVICE_NAME, 
INQUIRY, 
SD, 
SECURITY, 
CONN, 
} app_opcodes_t;</tt>

The corresponding message structure is as follows:
<tt>typedef struct 
{ 
ros_hdr_t ros_hdr; 
vris_hdr_t vris_hdr; 
app_hdr_t app_hdr; 
union 
{ 
app_name_msg_t app_name_msg; 
app_inquiry_msg_t app_inquiry_msg; 
app_sd_msg_t app_sd_msg; 
app_sec_msg_t app_sec_msg; 
app_conn_msg_t app_conn_msg; 
} ros_msg 
} app_msg_t;</tt>

The first element of the union app_name_msg matches with the first enum value of DEVICE_NAME (discriminant within ros_hdr). The number and order of the discriminant values (app_opcodes_t) are the same as the union members.

If the union within the message contains other unions (nested unions), the same rule would apply. The following example demonstrates app_sec_msg_t within ros_msg:
<tt>typedef enum 
{ 
DISCOVERABLE_CFM, 
CONNECTABLE_CFM, 
SEC_AUTHORIZE_CFM, 
SEC_AUTHENTICATE_CFM, 
SEC_BOND_CFM, 
} app_prim_sec_t; 
typedef struct 
{ 
app_prim_sec_t sec_msg_rsp; 
union 
{ 
discoverable_mode discoverable_info; 
connectable_info_t connectable_info; 
authorize_info_t authorize_info; 
authenticate_info_t authenticate_info; 
user_info_input_t user_input_info; 
bond_info_t bond_info; 
} sec_msg; 
} app_sec_msg_t;</tt>

The above examples have the same number of discriminant values and union members. There is a one-to-one correlation between discriminant and union member. Having a discriminant for each union within nested unions decouples the unions and makes it more scalable and easier to maintain. The unions become independent of each other and can easily be extended.

Studio:How does STRIDE know about my APIs and messaging interfaces?

2008-02-05T21:56:20Z

Root:

STRIDE learns about APIs and messaging interfaces through the header files of embedded applications. To clarify ambiguities in complex interfaces, developers add pragma statements (SCL) to further specify the characteristics of interfaces and data types. STRIDE compiles through these header files and builds an XML database of the application interface signatures. These application interfaces are now remotely available to the developer through STRIDE.

Studio:How can I tell which version of a workspace is used when connected to the target at runtime?

2008-02-05T21:45:40Z

Root:

When working with multiple targets, you may want to determine which version of a workspace is being used at runtime. To determine the target to which you are connected, add a helper function to the Intercept Module which can return something from the target (e.g., a string whose value is a target compile-time setting) that will tell the script the kind of target to which it is connected.

You can also add a preprocessor define with a version number as part of the workspace build (not the target build). The define is not used for compilation. A script will check which preprocessor define is set and act accordingly.

Studio:Sending and receiving broadcast messages in the Runtime

2008-02-05T21:45:22Z

Root:

If broadcast messages are being sent from the target to the host (i.e., there are no subscribers on the target), the data must be marshalled up to the host. However, when both the broadcaster (owner) and a receiver (user) are on the target, it is more efficient to specify srST_RSP_PTR since only a pointer to the message is moved internally.

By contrast, if srST_RSP_VAL is specified, the entire message is copied before being sent.

Handling non-standard or unsupported keywords

2008-02-05T21:42:52Z

Root:

For example if the <tt>__inline__</tt> keyword is missing or unsupported, you can work around it by adding <tt>'__inline__='</tt> to the workspace definitions.

[[Category:Troubleshooting]]

Studio:How do I work around variable arguments for stubs?

2008-02-05T21:34:04Z

Root:

STRIDE does not directly support variable argument lists; however, it is possible to call interfaces with variable arguments as stubs. Currently there is no workaround for proxies or dynamic delegates. 
Interfaces with variable arguments can be wrapped using helper functions in the SCL file. The wrapper function depends on the number of variable arguments and the interface. 
For example, the UNIX system call "open" is defined as: 
<tt>extern int open (const char *__file, int __oflag, ...);</tt> 

In most cases, the variable argument is NULL; however, when creating a file, the file permission can be specified as an optional argument. In this case, it is simplest to call a wrapper function to the SCL file which has 3 arguments (the 3rd one being the mode). The wrapper function would be defined as follows: 
<tt>static int scl_file_open (const char *file, int oflag, mode_t mode) 
{ 
return open(file, oflag, mode); 
} </tt>

The wrapper function calls the open interface with the three arguments. The SCL pragmas would be applied to scl_file_open: 
<tt>#pragma scl_function(scl_file_open) 
#pragma scl_string(scl_file_open.file, MAX_FILE_NAME_LENGTH)</tt> 

Having a wrapper function for each possible variable argument could require a number of different wrapper functions if the variable argument can be of different types (e.g., a pointer to different structures), depending on the mandatory arguments. In this case, it would be easier to define the variable arguments as a union of all possible types. The UNIX system call "ioctl" could be an example of such an interface: 
<tt>extern int ioctl (int __fd, unsigned long int __request, ...) ;</tt> 

In most cases the variable argument (if there is one) is a pointer to a structure. The structure depends on the request value. An ioctl request has encoded in it whether the argument is an "in" parameter or "out" parameter, and the size of the variable argument in bytes.

Click [http://linux.about.com/library/cmd/blcmdl2_ioctl_list.htm?terms=config+h here] for a list of possible ioctl requests and the variable argument types. In this case, the variable argument could be wrapped by a union. The following example demonstrates a possible union definition in the SCL file: 
<tt>typedef union 
{ 
struct termios* p_termios; /* TCGETS, TCSETS, TCSETSW, TCSETSF, TIOCGLCKTRMIOS, TIOCSLCKTRMIOS */ 
struct termio* p_termio; /* TCGETA, TCSETA, TCSETAW, TCSETAF */ 
int data; /* TCSBRK, TCXONC, TCFLSH, TIOCSCTTY, TCSBRKP, TIOCSBRK, TIOCCBRK, TIOCMIWAIT, TIOCGICOUNT,
IOCGHAYESESP, TIOCSHAYESESP */ 
int* p_int; /* TIOCOUTQ, TIOCMGET, TIOCMBIS,TIOCMBIC, TIOCMSET, TIOCGSOFTCAR, TIOCSSOFTCAR, FIONREAD,
TIOCINQ, IOCPKT, FIONBIO, TIOCSETD, TIOCGETD, FIOASYNC, TIOCSERGWILD, TIOCSERSWILD,
TIOCSERGETLSR, FIOQSIZE */ 
pid_t* p_pid; /* TIOCGPGRP, TIOCSPGRP, TIOCGSID */ 
char* p_char; /* TIOCSTI, TIOCLINUX */ 
struct winsize* p_winsize; /* TIOCGWINSZ, TIOCSWINSZ */ 
struct serial_struct* p_serial_struct; /* TIOCGSERIAL, TIOCSSERIAL */ 
struct async_struct* p_async_struct; /* TIOCSERGSTRUCT */ 
struct serial_multiport_struct* p_serial_mp; /* TIOCSERGETMULTI, TIOCSERSETMULTI */ 
/* void: TIOCNXCL, TIOCCONS, TIOCNOTTY, FIONCLEX, FIOCLEX, TIOCSERCONFIG, TIOCEXCL, */
} scl_ioctl_u; </tt> 

The wrapper function will take a pointer to the union as the third argument. Depending on the request, the variable argument can be an input or output pointer. The request argument (union discriminate) is passed by value and therefore is an input only.

STRIDE does not support output pointers to unions without a discriminate value (or input only discriminate).

To have a discriminate value in both the input and output direction, the request parameter has to be passed as a pointer to the wrapper function. When the request is passed as a pointer, the discriminate is available in both the input and output direction. The wrapper function is defined as follows: 
<tt>static int scl_ioctl (int fd, unsigned long int* request, scl_ioctl_u* args) 
{ 
return ioctl(fd, *request, args->p_int); 
}</tt> 

Next we need to specify the interface and the union using SCL. The pragmas are: 
<tt>#pragma scl_function(scl_ioctl) 
#pragma scl_ptr(scl_ioctl.args, INOUT, PRIVATE) 
#pragma scl_ptr(scl_ioctl.request, INOUT, PRIVATE) 
#pragma scl_values(*(scl_ioctl.request), TCGETS, TCSETS, TCSETSW, \
TCSETSF, TCGETA, TCSETA, TCSETAW, TCSETAF, \
TCSBRK, TCXONC, TCFLSH, TIOCEXCL, TIOCNXCL, \
TIOCSCTTY, TIOCGPGRP, TIOCSPGRP, TIOCOUTQ, \
TIOCSTI, TIOCGWINSZ, TIOCSWINSZ, TIOCMGET, \
TIOCMBIS, TIOCMBIC, TIOCMSET, TIOCGSOFTCAR, \
TIOCSSOFTCAR, FIONREAD, TIOCINQ, TIOCLINUX, \
TIOCCONS, TIOCGSERIAL, TIOCSSERIAL, TIOCPKT,\
FIONBIO, TIOCNOTTY, TIOCSETD, TIOCGETD, \
TCSBRKP, TIOCSBRK, TIOCCBRK, \
TIOCGSID, FIONCLEX, FIOCLEX, FIOASYNC, \
TIOCSERCONFIG, TIOCSERGWILD, TIOCSERSWILD, \
TIOCGLCKTRMIOS, TIOCSLCKTRMIOS, \
TIOCSERGSTRUCT, TIOCSERGETLSR, \
TIOCSERGETMULTI, TIOCSERSETMULTI, \
TIOCMIWAIT, TIOCGICOUNT, TIOCGHAYESESP, \
TIOCSHAYESESP, FIOQSIZE); 
#pragma scl_union(*(scl_ioctl.args), *(scl_ioctl.request)); 
#pragma scl_union_activate(*(scl_ioctl.args), p_termios, TCGETS, TCSETS, TCSETSW, TCSETSF, TIOCGLCKTRMIOS, TIOCSLCKTRMIOS); 
#pragma scl_union_activate(*(scl_ioctl.args), p_termio, TCGETA, TCSETA, TCSETAW, TCSETAF); 
#pragma scl_union_activate(*(scl_ioctl.args), data, TCSBRK, TCXONC, TCFLSH, TIOCSCTTY, TCSBRKP, TIOCSBRK, TIOCCBRK, TIOCMIWAIT,
TIOCGICOUNT, TIOCGHAYESESP, TIOCSHAYESESP); 
#pragma scl_union_activate(*(scl_ioctl.args), p_int, TIOCOUTQ, TIOCMGET, TIOCMBIS,TIOCMBIC, TIOCMSET, TIOCGSOFTCAR, TIOCSSOFTCAR,
FIONREAD, TIOCPKT, FIONBIO, TIOCSETD, TIOCGETD, FIOASYNC, TIOCSERGWILD, TIOCSERSWILD, TIOCSERGETLSR, FIOQSIZE); 
#pragma scl_union_activate(*(scl_ioctl.args), p_pid, TIOCGPGRP, TIOCSPGRP, TIOCGSID); 
#pragma scl_union_activate(*(scl_ioctl.args), p_char, TIOCSTI, TIOCLINUX); 
#pragma scl_union_activate(*(scl_ioctl.args), p_winsize, TIOCGWINSZ, TIOCSWINSZ); 
#pragma scl_union_activate(*(scl_ioctl.args), p_serial_struct, TIOCGSERIAL, TIOCSSERIAL); 
#pragma scl_union_activate(*(scl_ioctl.args), p_async_struct, TIOCSERGSTRUCT); 
#pragma scl_union_activate(*(scl_ioctl.args), p_serial_mp, TIOCSERGETMULTI, TIOCSERSETMULTI);

Studio:Understanding SCL conflicts

2008-02-05T21:33:49Z

Root:

There is a new class of conflicts reported by the compiler called SCL conflicts. These conflicts are caused when two or more top-level header files contain conflicting constant values or pragmatized types. These were silently ignored in previous versions of STRIDE.

There are two types of SCL conflicts: 
<ol>
<li>The value of an enumeration constant or numeric valued preprocessor macro is in conflict with the results of the compilation of two top-level header files. A warning will be issued indicating the name associated with the inconsistent values. The compilation will still be successful, as this is only a warning; however, the value for the constant stored in ascript.Constants() will be the string “ERROR_VALUE_CONFLICT” rather than either of the original conflicting numeric values. In previous versions of STRIDE, the second value was accepted by default.</li>
<li>A type, T, occurs in two different top-level header files and is structurally different in both. This structural difference can be caused by inconsistent or conflicting SCL pragmas applied to the type, or it can be caused by a C language difference between the types. This type of conflict is considered an error; therefore, the compilation fails and error message is returned.</li>
 
'''Example 1''' 
The following example uses two top-level header files, Header1.h and Header2.h. 
''Header1.h''
<tt>#define A 1</tt> 
''Header2.h''
<tt>#define A 2</tt> 
The compilation of workspace 1 (via Header1.h) will return a Merge Conflict warning for “A”. The compilation will still be successful; the value of “A” in ascript.Constants() will be the string “ERROR_VALUE_CONFLICT”. 
'''Example 2''' 
The following example uses two top-level header files, Header1.h and Header2.h, and one header file that is not a top-level header file, NotTopLevelHeader.h. 
''Header1.h''
<tt>#include "NotTopLevelHeader.h" 
#pragma scl_ptr (S.p, OUT, PRIVATE); 
int f (S s); 
#pragma scl_function(f); </tt>
''Header2.h''
<tt>#include "NotTopLevelHeader.h" 
int g (S s); 
#pragma scl_function(g); </tt>
''NotTopLevelHeader.h''
<tt>typedef struct S {int *p;} S;</tt> 
As a result of the functions f() and g() having a different picture of the shared type S, the compilation fails and returns the following Merge Error: 
<tt>... \header1.h(0) : Error : Merge conflict -- Found conflicting destinations for scl_ptr(S.p, ... )</tt>

Studio:How does the STRIDE compiler handle zero-length arrays?

2008-02-05T21:33:17Z

Root:

Under option, the STRIDE compiler allows an stucture member array to be declared with zero length. This is most frequently used for the last member of a structure (although it may be used for any member). The declaration of a zero length array affects the structure in the following ways:

1. The size of the structure will be adjusted upward, if necessary, so that it ends on a boundary suitable for a field of the declared array type.

2. The offset of the first member following the zero length array declaration, if one exists, will be adjusted upward to a boundary suitable for a field of the declared array type if necessary.

As an example, consider:

struct S {
char i;
int ary[0];
};

Assuming that char is one byte in size and requires single-byte alignment and int has four byte size and four byte alignment, then

sizeof(struct S) == 4.

If the zero length array had not been declared then

sizeof(struct S) == 1;

Studio:How do I apply an SCL pragma to an array?

2008-02-05T21:33:00Z

Root:

To apply an SCL pragma to an array, treat the array as if it was declared as a pointer and use pointer-type syntax. For example: 
<tt>typedef unsigned char BOOL; 
#define TRUE 1 
#define FALSE 0 
typedef struct 
{ 
BOOL list[5]; 
int type; 
} S_T; 
int foo(BOOL flag, S_T p); 
#pragma scl_function(foo) 
#pragma scl_values(*S_T.list, TRUE, FALSE)</tt>

Category:SCL

2008-02-05T21:32:00Z

Root:

===Pointers===
* [[Can STRIDE marshal both data and pointers?]]
* [[Can an array be cast to a pointer?]]
* [[Casting and pointers]]
* [[Accessing target data while processing a proxy call]]

===Arrays===
* [[How do I apply an SCL pragma to an array?]]
* [[Assigning array elements]]
* [[How does the STRIDE compiler handle zero-length arrays?]]

===Callbacks===
* [[Accessing the return value of a function using scripting]]
* [[Are multiple callbacks possible?]]
* [[Callback functions in Perl scripts]]

===Workarounds===
* [[How do I work around variable arguments for stubs?]]
* [[Understanding SCL conflicts]]

===Unions===
* [[Applying pragmas up and down type chains]]

===Where should these topics go?===
* [[Advantages and disadvantages of "default" candidates]]

Studio:Are multiple callbacks possible?

2008-02-05T21:31:40Z

Root:

Due to the single-threaded nature of most applications, once an off-target owner function is called, the owner may not call back into it. However, multiple callbacks may be done by using a short-term local timer which may continue processing after returning control back to the application and unblocking it. If callbacks are called from different threads it is possible that multiple callbacks are called at the same time.

Category:SCL

2008-02-05T21:20:55Z

Root:

===Pointers===
* [[Can STRIDE marshal both data and pointers?]]
* [[Can an array be cast to a pointer?]]
* [[Casting and pointers]]
* [[Accessing target data while processing a proxy call]]

===Arrays===
* [[How do I apply an SCL pragma to an array?]]
* [[Assigning array elements]]
* [[How does the STRIDE compiler handle zero-length arrays?]]

===Callbacks===
* [[Accessing the return value of a function using scripting]]
* [[Are multiple callbacks possible?]]
* [[Callback functions in Perl scripts]]

===Workarounds===
* [[How do I work around variable arguments for stubs?]]
* [[Understanding SCL conflicts]]

===Unions===
* [[Applying pragmas up and down type chains]]

===Where should these topics go?===
* [[Advantages and disadvantages of "default" candidates]]

Studio:Applying pragmas up and down type chains

2008-02-05T21:08:46Z

Root:

When a type T is pragmatized, it also applies to any types that are defined in terms of T.

In the following SCL, Example 1 demonstrates when the scl_union pragma has no effect on pS, S1, or pS1. This is by design. In order for the pragma to apply, it must be structured as shown in Example 2.

'''Example 1'''
<tt>typedef struct { 
enum {A,B} discrim; 
union 
{ 
int x; 
float f; 
} u; 
} S, *pS, S1, *pS1; 
#pragma scl_union(S, u, discrim); </tt>

'''Example 2'''
<tt>typedef struct { 
enum {A,B} discrim; 
union 
{ 
int x; 
float f; 
} u; 
} S; 
typedef S* pS; 
#pragma scl_union(S, u, discrim);

Studio:Advantages and disadvantages of "default" candidates

2008-02-05T21:08:31Z

Root:

The following table describes the advantages and disadvantages associated with the "default" candidate method vs. the candidate method.

{| class="wikitable", cellpadding="5"

|-

!

! '''"Default" candidate method'''

! '''Candidate method'''

|-

| '''Define and pragmatize each function prototype'''

| Not needed.

| Cumbersome if there are hundreds of candidate functions.

|-

| '''Code footprint of the generated code'''

| Only the proxy/stub of the "default" candidate is generated; thus, the code footprint is much smaller.

| The code footprint is dependent upon how many candidates are defined using the scl_ptr_flist() pragma, since a proxy/stub is generated for each candidate defined in the list.
|-

| '''Capturing of function callback command/response payloads via the trace module'''

| Any function callback command/response payloads with the identical signature can be captured.

| Only those candidate functions defined in the scl_ptr_flist() pragma can be captured.

|-

| ''' Visibility of function callbacks via the trace module'''

| The function callback being called is unknown. All of the function callbacks with the identical signature will be displayed with the "default" candidate name and SMID.

| All of the function callbacks being called are known, as long as the candidate functions were declared in the scl_ptr_flist() pragma.

|}
 
One disadvantage of using the shorthand method to define candidates in scl_ptr_flist(), as shown in Method 3 of the [[Working with "default" candidates]] topic, is that the function pointer prototypes are not defined by the user/customer, but rather by STRIDE. So, for example, if the user wants to create a proxy for foo2() with stub candidate functions C2 and "cand4" on the target, the generated IM code will give "undefined" compiler errors for "cand4". The following procedure using the header file MyHeader.h (the file containing the SCL pragmas or function prototypes) resolves this issue:
<tt>#ifdef srIMON 
void cand4(int x, char y); 
#endif </tt>

The use of the srIMON preprocessor directive allows the SDAC to compile the file without any name conflicts for "cand4", since these are already defined within STRIDE. It also allows the generated IM code to compile successfully.

'''MyFunctions.c''' 
MyFunctions.c is an example of a user-created file containing the actual code for the candidate "cand4":
<tt>void cand4(int x, char y) 
{ 
} </tt>

'''MyTest.c''' 
MyTest.c is an example of a user-created file containing a test thread that makes the call to foo2() with the appropriate function pointer callback:
<tt>#include “MyHeader.h” 
FPtr funcPtr; 
// set to cand4 
funcPtr = cand4; 
foo2(&funcPtr);</tt> 
In some instances, the candidates on the target are not known to the implementer of foo2() and the candidates may be static, so the above solution isn’t applicable. Using the “default” candidate mechanism is the perfect solution to this problem. The following example demonstrates how to do this (refer to Method 3 above):

In MyHeader.h (the file that contains the SCL pragma’s or the function prototypes), replace the following:
<tt>#pragma scl_ptr_flist(*foo2.pFPtr, “cand4”, C2)</tt> 
with:
<tt>#pragma scl_ptr_flist(*foo2.pFPtr, “default_cand”) // default candidate</tt> 

'''MyFunctions.c''' 
MyFunctions.c is an example of a user-created file containing the actual code for the candidates (unknown_cand1, unknown_cand2):
<tt>static void unknown_cand1(int x, char y) 
{ 
} 
static void unknown_cand2(int x, char y) 
{ 
} </tt>

'''MyTest.c''' 
MyTest.c is an example of a user-created file containing a test thread that makes the call to foo2() with the appropriate function pointer callback.

<tt>#include “MyHeader.h” 
FPtr funcPtr; 
// set to unknown_cand1 
funcPtr = unknown_cand1; 
foo2(&funcPtr); 
// set to unknown_cand2 
funcPtr = unknown_cand2; 
foo2(&funcPtr); </tt>

Studio:Accessing target data while processing a proxy call

2008-02-05T20:48:08Z

Root:

In some cases, void pointers are passed into proxy functions calls, or the passed structures are so complex that they cannot completely be described for STRIDE. In these cases, the proxy (e.g., a script) might have to access certain data on the target to be able to validate the functionality of the call. For example, this might be required with an interface that writes structured data to a file: 
<tt>int write(const void *buffer, int element_size, int count)</tt>

STRIDE needs to know the data structure in order to correctly marshal the data across platforms. The element size itself is not enough information for STRIDE. The buffer pointer could be typecast to a byte pointer; however, in this case the number of elements would be based on element size and count. STRIDE supports sized pointers, as long as the size is a single field and not the combination of multiple fields.

How can an interface like this be easily dealt with in STRIDE if we plan on testing an application which uses this interface, but the library which implements the functionality is not yet available?

First of all, the assumption is the actual structure is of no interest. We simply want to test the ability to write to a stream and later read from it, and verify we get the same data back. In this case, we can leave the buffer pointer as a void pointer and just pass the void pointer to STRIDE. Once in the proxy function, we need a way to retrieve the actual data at this pointer address from the target; this can be done with a helper function which reads a number of bytes from a certain memory address and passes it back to STRIDE. A simple helper function in the .h file perform this function: 
<tt>static void SCL_get_num_bytes(void *ptr, unsigned char* data, int num_bytes)
{
memcpy(data, ptr, num_bytes);
}</tt>

An important note is that the data has to be valid when the helper function is called. In the case of a proxy call, the pointer should certainly be valid until the function returns. The proxy script is as follows:
write.owner.register event = ascript.WaitForEvent();
if (event = write)
{
/* Copy the buffer pointer from the proxy call */
scl_get_num_bytes.ParameterList.num_bytes = write.ParameterList.element_size *write.ParameterList.count;

/* Call the helper function to retrieve the data */
scl_get_num_bytes.Call();

/* Process the data */
get_num_bytes.User.OutPointers.data ... ...

write.Return();
/* return from the proxy function call */
}

The same can be done for the read function. Once the read proxy is called, a helper function can be called to copy the actual data in place. The read interface is as follows:

int read(void *buffer, int element_size, int count);
static void SCL_set_num_bytes(void *ptr, unsigned char* data, int num_bytes)
{
memcpy(ptr, data, num_bytes);
}
read.owner.register event = ascript.WaitForEvent();
if (event = read)
{
/* set the data to be read */
set_num_bytes.User.ParameterList.data = ... ...

/* copy the buffer pointer from the proxy call */
scl_set_num_bytes.ParameterList.ptr = read.ParameterList.buffer;

/* calculate the number of bytes */
scl_set_num_bytes.ParameterList.num_bytes = read.ParameterList.element_size *read.ParameterList.count;

/* Call the helper function to retrieve the data */
scl_set_num_bytes.Call();

/* Process the data */
read.Return(); /* return from the proxy function call */
}

Category:SCL

2008-02-05T20:47:57Z

Root:

===Pointers===
* [[Can STRIDE marshal both data and pointers?]]
* [[Can an array be cast to a pointer?]]
* [[Casting and pointers]]
* [[Accessing target data while processing a proxy call]]

===Callbacks===
* [[Accessing the return value of a function using scripting]]
* [[Are multiple callbacks possible?]]
* [[Callback functions in Perl scripts]]

===Workarounds===
* [[How do I work around variable arguments for stubs?]]
* [[Understanding SCL conflicts]]

Studio:Casting and pointers

2008-02-05T18:50:38Z

Root:

A cast must be applied to a pointer before anything else. In other words, you must apply scl_cast before scl_ptr, as illustrated by the following example: 
<tt>#pragma scl_function(GetUnicodeName) 
#pragma scl_cast (GetUnicodeName, name, unsigned short*) 
#pragma scl_ptr (GetUnicodeName, name, OUT, PRIVATE) 
#pragma scl_string (GetUnicodeName, name, 100)</tt>

Studio:Can an array be cast to a pointer?

2008-02-05T18:04:38Z

Root:

No. You cannot cast an array to a pointer type. Because there are subtle differences between them, they are not always interchangeable in SCL like they are in C.

Instead of using the following: 
<tt>INT vr_get_foo(INT entry, INT index, file_table_t * out_buffer) 
typedef struct 
{ 
register ringer_types_t ringer_type; 
BYTE alias_filename[(MAX_RINGER_ALIAS_NAME_LEN+1) *2]; 
UINT16 pad; 
}ringer_file_table_t; 
#pragma scl_function(v_get_mmedia_ringer) 
#pragma scl_ptr(vr_get_mmedia_ringer, out_buffer, OUT, PRIVATE) </tt> 

Use this SCL instead: 
<tt>#pragma scl_function(vr_get_mmedia_ringer) 
#pragma scl_ptr(vr_get_get_mmedia_ringer, out_buffer, OUT, PRIVATE) 
#pragma scl_string(ringer_file_table_t, alias_filename, (MAX_RINGER_ALIAS_NAME_LEN+1) * 2)</tt>

Studio:Can STRIDE marshal both data and pointers?

2008-02-05T17:54:11Z

Root:

STRIDE does not marshal both the pointer value and the data. You have to pick one of the two. If a pointer is defined as void or the scl_ptr_opaque pragma is applied the pointer value is marshaled otherwise the data the pointer points to is marshaled. Opaque pointers can be passed to other functions or helper function to retrieve the data to which it points.

Category:SCL

2008-02-05T17:53:44Z

Root:

===Pointers===
* [[Can STRIDE marshal both data and pointers?]]
* [[Can an array be cast to a pointer?]]
* [[Casting and pointers]]

===Callbacks===
* [[Accessing the return value of a function using scripting]]
* [[Are multiple callbacks possible?]]
* [[Callback functions in Perl scripts]]

===Workarounds===
* [[How do I work around variable arguments for stubs?]]
* [[Understanding SCL conflicts]]

Category:SCL

2008-02-05T17:50:23Z

Root:

===Pointers===

===Callbacks===

===Workarounds===

Studio:Working with "default" candidates

2008-02-04T23:48:27Z

Root:

Studio:Using printf

2008-02-04T23:46:09Z

Root:

Studio:Understanding SCL conflicts

2008-02-04T23:45:51Z

Root:

Studio:Sending and receiving broadcast messages in the Runtime

2008-02-04T23:45:22Z

Root:

Handling non-standard or unsupported keywords

2008-02-04T23:45:06Z

Root:

For example if the <tt>__inline__</tt> keyword is missing or unsupported, you can work around it by adding <tt>'__inline__='</tt> to the workspace definitions.

[[Category:Application Notes]]

Studio:How to generate a preprocessor (.i) file for analysis

2008-02-04T23:44:47Z

Root:

Studio:How to define message structures

2008-02-04T23:41:54Z

Root:

Studio:How does the STRIDE compiler handle zero-length arrays?

2008-02-04T23:39:34Z

Root:

Studio:How does STRIDE know about my APIs and messaging interfaces?

2008-02-04T23:39:18Z

Root:

Studio:How do I work around variable arguments for stubs?

2008-02-04T23:39:01Z

Root:

Studio:How do I apply an SCL pragma to an array?

2008-02-04T23:38:23Z

Root:

Studio:How do I access global variables?

2008-02-04T23:38:06Z

Root:

Studio:How can I tell which version of a workspace is used when connected to the target at runtime?

2008-02-04T23:37:40Z

Root:

Studio:Delegating ISHELL SendEvent

2008-02-04T23:32:15Z

Root:

Studio:Casting and pointers

2008-02-04T23:31:41Z

Root:

Studio:Can an array be cast to a pointer?

2008-02-04T23:31:24Z

Root:

Studio:Can STRIDE marshal both data and pointers?

2008-02-04T23:30:57Z

Root:

Studio:Accessing target data while processing a proxy call

2008-02-04T23:29:44Z

Root:

Studio:Applying pragmas up and down type chains

2008-02-04T23:29:26Z

Root:

Studio:Advantages and disadvantages of "default" candidates

2008-02-04T23:29:02Z

Root: