arm_destroy_application(3)

1arm_destroy_application(3) ARM 4 Programmer's Manualarm_destroy_application(3)
2
3
4

NAME

6       arm_destroy_application - destroy application data
7

SYNOPSIS

9       #include <arm4.h>
10
11       arm_error_t
12       arm_destroy_application(
13           const arm_id_t *app_id,
14           const arm_int32_t flags,
15           const arm_buffer4_t *buffer4);
16

DESCRIPTION

18       arm_destroy_application() indicates that the registration data about an
19       application previously registered with arm_register_application() is no
20       longer needed.
21
22       The  purpose of this call is to signal the ARM implementation so it can
23       release any storage it is holding. Ending a process  or  unloading  the
24       ARM  library  results  in an implicit arm_destroy_application() for any
25       previously registered applications.
26
27       It is possible for multiple arm_register_application() calls to be made
28       in  the  same  process with identical identity data. When this is done,
29       arm_destroy_application() is assumed to be paired with  one  arm_regis‐
30       ter_application().  For  example, if arm_register_application() is exe‐
31       cuted twice with the same output ID, and  arm_destroy_application()  is
32       executed  once  using  this  ID,  it is assumed that an instance of the
33       application is still active and it is not safe to discard the  applica‐
34       tion registration data associated with the ID.
35
36       app_id is an application ID returned from an arm_register_application()
37       call in the same process.
38
39       No sub-buffer types are currently valid with this function call, so the
40       buffer4 pointer should be null (ARM_BUF4_NONE).
41
42       No  values  are  currently  defined for flags. The field should be zero
43       (ARM_FLAG_NONE).
44
45

RETURN VALUE

47       On success, the function returns ARM_SUCCESS. A  non-zero  value  indi‐
48       cates an error.
49

ERRORS

51       If  the  return code is negative, an error occurred. If the return code
52       is not negative, an error may or may not have occurred - the determina‐
53       tion  of  what  is an error and whether an error code is returned is at
54       the discretion of the ARM implementation. The application can test  the
55       return code if it wants to provide its own error logging.
56
57       This implementation returns no errors for arm_destroy_application().
58

CONFORMING TO

60       ARM Issue 4.0 C Language Bindings, Version 2
61

EXAMPLE

63       None.
64