Handle API (SourceMod) - Revision history

Fyren: Undo revision 5690 by Zerak (talk)

2024-06-26T17:44:01Z

Undo revision 5690 by Zerak (talk)

2022-12-11T21:10:51Z

‎Reading/Checking Handles

2021-04-25T10:22:55Z

‎Handle Security

2017-01-09T01:04:27Z

‎Handle Security: I guess.

2014-06-09T19:25:25Z

‎Implementing the Native: Corrected misspelled variable names

2008-03-29T12:38:39Z

"cannot" changed to "can also"

2008-02-18T08:16:05Z

‎Reading/Checking Handles: Changed "herr" to "err". "herr" does not exist!

2007-06-08T14:41:41Z

‎New Security Rules

2007-06-08T14:38:18Z

HandleSecurity changed to HandleAccess

2007-05-04T20:17:29Z

‎Reading/Checking Handles

@@ Line 13: / Line 13: @@
 ==HandleType_t==
-The <tt>HandleType_t</tt> describes a type under which Handles can be created.  Types can have up to 15 sub-types; sub-types can also have their own sub-types, called child types.  When Handles are being read, they are "type checked," to make sure they are being read under a given type.  When a type is destroyed, all Handles under the type are destroyed.  If the type has child types, each child type is also destroyed.
+The <tt>HandleType_t</tt> describes a type under which Handles can be created.  Types can have up to 15 sub-types; sub-types cannot have their own sub-types, called child types.  When Handles are being read, they are "type checked," to make sure they are being read under a given type.  When a type is destroyed, all Handles under the type are destroyed.  If the type has child types, each child type is also destroyed.
 Handle types also allow overloading of various Handle operations.  Currently, the only overloaded action is for overloading when a Handle is destroyed.  This allows the encapsulated pointer to be safely destroyed by the type interface.  The interface which overloads type operations is called <tt>IHandleTypeDispatch</tt>.

@@ Line 134: / Line 134: @@
 ===Reading/Checking Handles===
 Handles aren't very useful unless you have natives to use them.  Let's say we want to write lines of text to our File type.
-<cpp>/* native WriteLine(Handle:hndl, const String:line[]); */
+<cpp>/* native bool WriteLine(Handle hndl, const char[] line); */
 static cell_t sm_WriteLine(IPluginContext *pContext, const cell_t *params)
+{
@@ Line 142: / Line 142: @@
 	/* Build our security descriptor */
-	sec.pOwner = NULL;	/* Not needed, owner access is not checked */
+	sec.pOwner = nullptr;	/* Not needed, owner access is not checked */
 	sec.pIdentity = myself->GetIdentity();	/* But only this extension can read */
@@ Line 149: / Line 149: @@
 	 * This type of cast is safe since sizeof(void **) == sizeof(void *) == sizeof(T *) in almost all cases.
 	 */
-	FILE *fp;
+	FILE *fp = nullptr;
 	if ((err = g_pHandleSys->ReadHandle(hndl, g_FileType, &sec, (void **)&fp))
 	     != HandleError_None)
@@ Line 157: / Line 157: @@
 	/* Get the text */
-	char *text;
+	char *text = nullptr;
 	pContext->LocalToString(params[2], &text);

@@ Line 46: / Line 46: @@
 *<tt>access</tt>: An array where each index is a <tt>HandleAccessRight</tt> enumeration member.  If set to 0, an access right is allowed without a <tt>HandleSecurity</tt> instance.  Otherwise, the following bitwise flags are checked:
 **<tt>HANDLE_RESTRICT_IDENTITY</tt>: If flagged, this access right is only granted if the <tt>pIdentity</tt> member of the <tt>HandleSecurity</tt> struct matches the Handle's '''type's''' owner.
-**<tt>HANDLE_RESTRICT_OWNER</tt>: If flagged, this access right is onyl granted if the <tt>pOwner</tt> member of the <tt>Handlesecurity</tt> struct matches the Handle's owner.
+**<tt>HANDLE_RESTRICT_OWNER</tt>: If flagged, this access right is only granted if the <tt>pOwner</tt> member of the <tt>Handlesecurity</tt> struct matches the Handle's owner.
 The following access rights exist for Handles:

@@ Line 39: / Line 39: @@
 ==Handle Security==
-Handle security permissions inherit from their parent type unless given an alternate set of permissions.  Handles are "secured" by two properties, unlike Handles, which just have one.  When verifying your identity with a secured Handle function, you must use the <tt>HandleSecurity</tt> struct, which has two properties:
+Handle security permissions inherit from their parent type unless given an alternate set of permissions.  Handles are "secured" by two properties, unlike handle types, which just have one.  When verifying your identity with a secured Handle function, you must use the <tt>HandleSecurity</tt> struct, which has two properties:
 *<tt>pOwner</tt>: The owner of the Handle, which is usually a plugin <tt>IdentityToken_t</tt>.
 *<tt>pIdentity</tt>: The owner of the Handle's type, or the <tt>IdentityToken_t</tt> securing its type.

@@ Line 219: / Line 219: @@
 	 */
 	FILE *fp;
-	if ((herr = g_pHandleSys->FreeHandle(hndl, &src))
+	if ((err = g_pHandleSys->FreeHandle(hndl, &sec))
 	     != HandleError_None)
+	{

@@ Line 186: / Line 186: @@
+{
 	/* Create default access rights */
-	HandleAccess acc;
+	HandleAccess rules;
-	g_pHandleSys->InitAccessDefaults(NULL, &acc);
+	g_pHandleSys->InitAccessDefaults(NULL, &rules);
 	/* Restrict delete to only our identity */
-	acc.access[HandleAccess_Delete] = HANDLE_RESTRICT_IDENTITY;
+	rules.access[HandleAccess_Delete] = HANDLE_RESTRICT_IDENTITY;
 	/* Register the type with our security permissions */
@@ Line 197: / Line 197: @@
 ,
 			NULL,
-			&acc,
+			&rules,
 			myself->GetIdentity(),
 			NULL);