Studio:Working with "default" candidates - Revision history

Timd: Text replace - 'Category:Function Pointers' to 'Category:Studio:Function Pointers'

2009-08-21T00:50:34Z

Text replace - 'Category:Function Pointers' to 'Category:Studio:Function Pointers'

← Older revision		Revision as of 00:50, 21 August 2009
Line 70:		Line 70:

	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.		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.
	[[Category:Function Pointers]]		[[Category:Studio:Function Pointers]]

Timd: Working with "default" candidates moved to Studio:Working with "default" candidates

2009-08-18T23:27:46Z

Working with "default" candidates moved to Studio:Working with "default" candidates

← Older revision	Revision as of 23:27, 18 August 2009
(No difference)

Robg: /* Method 1: Candidate list declaration using predefined function prototypes */

2008-10-06T18:19:09Z

Method 1: Candidate list declaration using predefined function prototypes

← Older revision		Revision as of 18:19, 6 October 2008
Line 31:		Line 31:
	</source>		</source>

	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.		The candidates' (C1, C2, C3) prototypes are defined and captured, 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==		==Method 2: Candidate list declaration using shorthand method==

Robg: /* Example */

2008-10-06T18:16:01Z

Example

← Older revision		Revision as of 18:16, 6 October 2008
Line 17:		Line 17:
	void C3(int x, char y);		void C3(int x, char y);

	// ~~pragmatize~~ candidate prototypes		// capture candidate prototypes
	#pragma scl_function(C1)		#pragma scl_function(C1)
	#pragma scl_function(C2)		#pragma scl_function(C2)

Timd at 23:42, 10 March 2008

2008-03-10T23:42:47Z

← Older revision		Revision as of 23:42, 10 March 2008
Line 1:		Line 1:
	scl_ptr_flist() serves as a "shorthand" method of declaring a "default" candidate.~~<br><br>~~		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. <br>~~

	'''~~Example~~'''~~<br>~~		'''Note''': When using scl_ptr_flist() to define candidates, the function pointer prototypes are defined internally within STRIDE, rather than by the user.
	~~<tt>// function pointer typedef<br>~~
	~~typedef void~~ (*FPtr) ~~(int~~, ~~char);<br>~~
	~~void foo(FPtr *pFPtr);<br>~~
	~~void foo1(FPtr *pFPtr);<br>~~
	~~void foo2(FPtr *pFPtr);<br>~~
	~~void foo3(FPtr *pFPtr);<br><br>~~
	~~// candidate~~ prototypes ~~<br>~~
	~~void C1(int x~~, ~~char y);<br>~~
	~~void C2(int x, char y);<br>~~
	~~void C3(int x, char y);<br><br>~~
	~~// pragmatize candidate prototypes<br>~~
	~~#pragma scl_function(C1)<br>~~
	~~#pragma scl_function(C2)<br>~~
	~~#pragma scl_function(C3)<br></tt>~~

	~~'''~~How to declare a "default" candidate using scl_ptr_flist()~~'''<br>~~		=Example=
			<source lang="c">
			// 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)
			</source>

			=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.<br><br>		There are several methods of declaring a "default" candidate using scl_ptr_flist(). Each method is explained below.<br><br>
	~~'''~~Method 1: Candidate list declaration using predefined function prototypes~~'''~~		==Method 1: Candidate list declaration using predefined function prototypes==
	<tt>#pragma scl_function(foo)~~<br>~~		<source lang="c">
	#pragma scl_ptr_flist(*foo.pFPtr, C1, C2, C3)</~~tt><br~~>		#pragma scl_function(foo)
			#pragma scl_ptr_flist(*foo.pFPtr, C1, C2, C3)
			</source>

	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.		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.
	~~<br><br>~~
	~~'''Method 2: Candidate list declaration using shorthand method'''~~
	~~<tt>#pragma scl_function(foo1)<br>~~
	~~#pragma scl_ptr_flist(*foo1.pFPtr, "cand1")<br></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.~~<br>~~		==Method 2: Candidate list declaration using shorthand method==
	~~<br>~~		<source lang="c">
	~~'''~~Method 3: Candidate list declaration using combination of predefined functions and shorthand method~~'''~~		#pragma scl_function(foo1)
	<br>		#pragma scl_ptr_flist(*foo1.pFPtr, "cand1")
	~~<tt>~~#pragma scl_function(foo2)		</source>
	#pragma scl_ptr_flist(*foo2.pFPtr, "cand4", C2)</~~tt><br~~>
			"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==

			<source lang="c">
			#pragma scl_function(foo2)
			#pragma scl_ptr_flist(*foo2.pFPtr, "cand4", C2)
			</source>

	The candidate "cand4" is interpreted by STRIDE as follows:<br>		The candidate "cand4" is interpreted by STRIDE as follows:<br>

	<tt> void cand4(int p1, char p2);~~<br>~~		<source lang="c">
	#pragma scl_function(cand4)</~~tt><br~~>		void cand4(int p1, char p2);
			#pragma scl_function(cand4)
			</source>

	"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.<br>		"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.<br>
	~~<br>~~
	~~'''Method 4: "Default" candidate declaration'''<br>~~
	~~<tt>#pragma scl_function(foo3)<br>~~
	~~#pragma scl_ptr_flist(*foo3.pFPtr, "def_cand")</tt><br><br>~~

	The candidate "def_cand" is interpreted by STRIDE as follows:<br>		==Method 4: "Default" candidate declaration==
	~~<tt>~~void def_cand(int p1, char p2);~~<br>~~		<source lang="c">
	#pragma scl_function(def_cand)</~~tt><br~~>		#pragma scl_function(foo3)
			#pragma scl_ptr_flist(*foo3.pFPtr, "def_cand")
			</source>

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

	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.		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.
	[[Category:Function Pointers]]		[[Category:Function Pointers]]

Timd at 18:09, 29 February 2008

2008-02-29T18:09:19Z

← Older revision		Revision as of 18:09, 29 February 2008
Line 53:		Line 53:

	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.		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.
			[[Category:Function Pointers]]

Root at 23:55, 5 February 2008

2008-02-05T23:55:44Z

← Older revision		Revision as of 23:55, 5 February 2008
Line 53:		Line 53:

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


	~~[[Category:Application Notes]]~~

Root at 23:48, 4 February 2008

2008-02-04T23:48:27Z

← Older revision		Revision as of 23:48, 4 February 2008
Line 55:		Line 55:


	[[Category:~~KB]]~~		[[Category:Application Notes]]
	~~[[Category:SCL~~]]

Andreo at 23:09, 11 December 2007

2007-12-11T23:09:12Z

← Older revision		Revision as of 23:09, 11 December 2007
Line 56:		Line 56:

	[[Category:KB]]		[[Category:KB]]
			[[Category:SCL]]

Root at 22:57, 21 June 2007

2007-06-21T22:57:30Z

← Older revision		Revision as of 22:57, 21 June 2007
Line 53:		Line 53:

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


			[[Category:KB]]