Introduction
Arm’s Platform Security Architecture (PSA) is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level.
The PSA Cryptographic API (Crypto API) described in this document is an important PSA component that provides an interface to modern cryptographic primitives on resource-constrained devices. The interface is user-friendly, while still providing access to the primitives used in modern cryptography. It does not require that the user have access to the key material. Instead, it uses opaque key handles.
This document is part of the PSA family of specifications. It defines an interface for cryptographic services, including cryptography primitives and a key storage functionality.
This document includes:
- A rationale for the design.
- A high-level overview of the functionality provided by the interface.
- A description of typical architectures of implementations for this specification.
- General considerations for implementers of this specification and for applications that use the interface defined in this specification.
- A detailed definition of the API.
Companion documents will define profiles for this specification. A profile is a minimum mandatory subset of the interface that a compliant implementation must provide.
Design goals
Suitable for constrained devices
The interface is suitable for a vast range of devices: from special-purpose cryptographic processors that process data with a built-in key, to constrained devices running custom application code, such as microcontrollers, and multi-application devices, such as servers. Consequentially, the interface is scalable and modular.
- Scalable: you shouldn’t pay for functionality that you don’t need.
- Modular: larger devices implement larger subsets of the same interface, rather than different interfaces.
Because this specification is suitable for very constrained devices, including those where memory is very limited, all operations on unbounded amounts of data allow multipart processing, as long as the calculations on the data are performed in a streaming manner. This means that the application does not need to store the whole message in memory at one time.
Memory outside the keystore boundary is managed by the application. An implementation of the interface is not required to retain any state between function calls, apart from the content of the keystore and other data that must be kept inside the keystore security boundary.
The interface does not expose the representation of keys and intermediate data, except when required for interchange. This allows each implementation to choose optimal data representations. Implementations with multiple components are also free to choose which memory area to use for internal data.
A keystore interface
The specification allows cryptographic operations to be performed on a key to which the application does not have direct access. Except where required for interchange, applications access all keys indirectly, by a handle. The key material corresponding to that handle can reside inside a security boundary that prevents it from being extracted, except as permitted by a policy that is defined when the key is created.
Optional isolation
Implementations can isolate the cryptoprocessor from the calling application, and can further isolate multiple calling applications. The interface allows the implementation to be separated between a frontend and a backend. In an isolated implementation, the frontend is the part of the implementation that is located in the same isolation boundary as the application, which the application accesses by function calls. The backend is the part of the implementation that is located in a different environment, which is protected from the frontend. Various technologies can provide protection, for example:
- Process isolation in an operating system.
- Partition isolation, either with a virtual machine or a partition manager.
- Physical separation between devices.
Communication between the frontend and backend is beyond the scope of this specification.
In an isolated implementation, the backend can serve more than one implementation instance. In this case, a single backend communicates with multiple instances of the frontend. The backend must enforce caller isolation: it must ensure that assets of one frontend are not visible to any other frontend. How callers are identified is beyond the scope of this specification. An implementation that provides caller isolation must document how callers are identified. An implementation that provides isolation must document any implementation-specific extension of the API that enables frontend instances to share data in any form.
In summary, there are three types of implementations:
- No isolation: there is no security boundary between the application and the cryptoprocessor. For example, a statically or dynamically linked library is an implementation with no isolation.
- Cryptoprocessor isolation: there is a security boundary between the application and the cryptoprocessor, but the cryptoprocessor does not communicate with other applications. For example, a cryptoprocessor chip that is a companion to an application processor is an implementation with cryptoprocessor isolation.
- Caller isolation: there are multiple application instances, with a security boundary between the application instances among themselves, as well as between the cryptoprocessor and the application instances. For example, a cryptography service in a multiprocess environment is an implementation with caller and cryptoprocessor isolation.
Choice of algorithms
The specification defines a low-level cryptographic interface, where the caller explicitly chooses which algorithm and which security parameters they use. This is necessary to implement protocols that are inescapable in various use cases. The design of the interface enables applications to implement widely-used protocols and data exchange formats, as well as custom ones.
As a consequence, all cryptographic functionality operates according to the precise algorithm specified by the caller. However, this does not apply to device-internal functionality, which does not involve any form of interoperability, such as random number generation. The specification does not include generic higher-level interfaces, where the implementation chooses the best algorithm for a purpose. However, higher-level libraries can be built on top of the PSA Crypto API.
Another consequence is that the specification permits the use of algorithms, key sizes and other parameters that, while known to be insecure, may be necessary to support legacy protocols or legacy data. Where major weaknesses are known, the algorithm description give applicable warnings. However, the lack of a warning does not and cannot indicate that an algorithm is secure in all circumstances. Application developers should research the security of the algorithms that they plan to use to determine if the algorithms meet their requirements.
The interface facilitates algorithm agility. As a consequence, cryptographic primitives are presented through generic functions with a parameter indicating the specific choice of algorithm. For example, there is a single function to calculate a message digest, which takes a parameter that identifies the specific hash algorithm.
Ease of use
The interface is designed to be as user-friendly as possible, given the aforementioned constraints on suitability for various types of devices and on the freedom to choose algorithms.
In particular, the code flows are designed to reduce the chance of dangerous misuse. The interface makes it harder to misuse than to use correctly, and typical mistakes result in test failures, rather than subtle security issues. Implementations avoid leaking data when a function is called with invalid parameters, to the extent allowed by the C language and by implementation size constraints.
Example use cases
This section lists some of the use cases that were considered while designing this API. This list is not exhaustive, nor are all implementations required to support all use cases.
Network Security (TLS)
The API provides everything needed to establish TLS connections on the device side: asymmetric key management inside a key store, symmetric ciphers, MAC, HMAC, message digests, and AEAD.
Secure Storage
The API provides all primitives related to storage encryption, block or file-based, with master encryption keys stored inside a key store.
Network Credentials
The API provides network credential management inside a key store, for example, for X.509-based authentication or pre-shared keys on enterprise networks.
Device Pairing
The API provides support for key agreement protocols that are often used for secure pairing of devices over wireless channels. For example, the pairing of an NFC token or a Bluetooth device could make use of key agreement protocols upon first use.
Secure Boot
The API provides primitives for use during firmware integrity and authenticity validation, during a secure or trusted boot process.
Attestation
The API provides primitives used in attestation activities. Attestation is the ability for a device to sign an array of bytes with a device private key and return the result to the caller. There are several use cases: from attestation of the device state to the ability to generate a key pair and prove that it has been generated inside a secure key store. The API provides access to the algorithms commonly used for attestation.
Factory Provisioning
Most IoT devices receive a unique identity during the factory provisioning process, or once deployed to the field. This API provides the APIs necessary for populating a device with keys that represent that identity.
Functionality overview
This section provides a high-level overview of the functionality provided by the interface defined in this specification. Refer to the API definition for a detailed description.
Due to the modularity of the interface, almost every part of the library
is optional. The only mandatory function is psa_crypto_init
.
Library management
Before any use, applications must call psa_crypto_init
to initialize
the library.
Key management
Applications always access keys via a handle. This allows keys to be non-extractable, that is, an application can perform operations using a key without having access to the key material. Non-extractable keys are bound to the device, can be rate-limited and can have their usage restricted by policies.
Each key has a set of attributes that describe the key and the policy
for using the key. A psa_key_attributes_t
object contains all of the
attributes, which is used when creating a key and when querying key
attibutes.
Each key has a lifetime that determines when the key material is destroyed. There are two types of lifetimes: volatile and persistent.
Volatile keys
A volatile key is destroyed as soon as the application closes the
handle to the key. When the application terminates, it conceptually
closes all of its key handles. Conceptually, a volatile key is stored in
RAM. Volatile keys have the lifetime PSA_KEY_LIFETIME_VOLATILE
.
To create a volatile key:
- Populate a
psa_key_attributes_t
object with the key’s type, size, policy and other attributes. - Create the key with
psa_import_key
,psa_generate_key
,psa_key_derivation_output_key
orpsa_copy_key
.
To destroy a volatile key, call psa_close_key
or psa_destroy_key
(these functions are equivalent when called on a volatile key).
Persistent keys
A persistent key exists until it explicitly destroyed with
psa_destroy_key
or until it is wiped by the reset or destruction of
the device.
Each persistent key has a key identifier, which acts as a name for the key. Within an application, the key identifier corresponds to a single key. The application specifies the key identifier when the key is created, and uses the key identifier to obtain a handle to a persistent key that has already been created. If the implementation provides caller isolation, then key identifiers are local to each application: the same key identifier in two applications corresponds to different keys.
Persistent keys may be stored in different storage areas; this is
indicated through different lifetime values. This specification defines
a single lifetime value PSA_KEY_LIFETIME_PERSISTENT
which
corresponds to a default storage area. Implementations may define
alternative lifetime values corresponding to different storage areas
with different retention policies, or to secure elements with different
security characteristics.
To create a persistent key:
- Populate a
psa_key_attributes_t
object with the key’s type, size, policy and other attributes. - In the attributes object, set the desired lifetime and persistent identifier for the key.
- Create the key with
psa_import_key
,psa_generate_key
,psa_key_derivation_output_key
orpsa_copy_key
.
To release memory resources associated with a key but keep the key in
storage, call psa_close_key
. To access an existing persistent key,
call psa_open_key
with the same key identifier used when creating
the key.
To destroy a persistent key, open it (if it isn’t already open) and call
psa_destroy_key
.
The key lifetime and identifier are set when the key is created and cannot be changed without destroying the key first. If the original key permits copying, then the application can specify a different lifetime for the copy of the key.
Recommendations of minimum standards for key management
Most implementations provide the function psa_import_key
. The only
exceptions are implementations that only give access to a key or keys
that are provisioned by proprietary means, and do not allow the main
application to use its own cryptographic material.
Most implementations provide psa_get_key_attributes
and the
psa_get_key_xxx
accessor functions, as they are easy to implement,
and it is difficult to write applications and to diagnose issues without
being able to check the metadata.
Most implementations also provide psa_export_public_key
if they
support any asymmetric algorithm, since public-key cryptography often
requires the delivery of a public key that is associated with a
protected private key.
Most implementations provide psa_export_key
. However, highly
constrained implementations that are designed to work only with
short-term keys (no non-volatile storage), or only with long-term
non-extractable keys, may omit this function.
Usage policies
All keys have an associated policy that regulates which operations are
permitted on the key. Each key policy is a set of usage flags and a
specific algorithm that is permitted with the key. The policy is part of
the key attributes that are managed by a psa_key_attributes_t
object.
The usage flags are encoded in a bitmask, which has the type
psa_key_usage_t
. Three kinds of usage flag can be specified: * The
extractable flag PSA_KEY_USAGE_EXPORT
determines whether the key
material can be extracted. * The copyable flag PSA_KEY_USAGE_COPY
determines whether the key material can be copied into a new key, which
can have a different lifetime or a more restrictive policy. * The usage
flags PSA_KEY_USAGE_ENCRYPT
, PSA_KEY_USAGE_SIGN
, and so on
determine whether the corresponding operation is permitted on the key.
In addition to the usage bitmask, a policy specifies which algorithm is permitted with the key. This specification only defines policies that restrict keys to a single algorithm, which is in keeping with common practice and with security good practice.
A highly constrained implementation may not be able to support all the policies that can be expressed through this interface. If an implementation cannot create a key with the required policy, it must return an appropriate error code when the key is created.
Symmetric cryptography
This specification defines interfaces for message digests (hash functions), MAC (message authentication codes), symmetric ciphers and authenticated encryption with associated data (AEAD). For each type of primitive, the API includes two standalone functions (compute and verify, or encrypt and decrypt) as well as a series of functions that permit multipart operations.
The standalone functions are:
psa_hash_compute
andpsa_hash_compare
to calculate the hash of a message or compare the hash of a message with a reference value.psa_mac_compute
andpsa_mac_verify
to calculate the MAC of a message of compare the MAC with a reference value.psa_cipher_encrypt
andpsa_cipher_decrypt
to encrypt or decrypt a message using an unauthenticated symmetric cipher. The encryption function generates a random IV; to use a deterministic IV (which is not secure in general, but can be secure in some conditions that depend on the algorithm), use the multipart API.psa_aead_encrypt
andpsa_aead_decrypt
to encrypt/decrypt and authenticate a message using an AEAD algorithm. These functions follow the interface recommended by RFC 5116.
Multipart operations
The API provides a multipart interface to hash, MAC, symmetric cipher and AEAD primitives. These interfaces process messages one chunk at a time, with the size of chunks determined by the caller. This allows the processing of messages that cannot be assembled in memory. To perform a multipart operation:
- Allocate an operation object of the appropriate type. You can use any allocation strategy: stack, heap, static, etc.
- Initialize the operation object by one of the following methods:
- Set it to all-bits-zero.
- Initialize it to logical zero.
- Assign the value of the associated macro
PSA_xxx_INIT
. - Assign the result of calling the associated function
psa_xxx_init
.
- Specify a key for the operation using the associated setup function:
psa_hash_setup
,psa_mac_sign_setup
,psa_mac_verify_setup
,psa_cipher_encrypt_setup
,psa_cipher_decrypt_setup
,psa_aead_encrypt_setup
orpsa_aead_decrypt_setup
. - Provide additional parameters:
- When encrypting data, generate or set an initialization vector (IV), nonce, or similar initial value such as an initial counter value.
- When decrypting, set the IV or nonce.
- For a symmetric cipher, to generate a random IV, which is
recommended in most protocols, call
psa_cipher_generate_iv
. To set the IV, callpsa_cipher_set_iv
. - For AEAD, call
psa_aead_generate_nonce
orpsa_aead_set_nonce
.
- Call the associated update function on successive chunks of the
message:
psa_hash_update
,psa_mac_update
,psa_cipher_update
,psa_aead_update_ad
orpsa_aead_update
. - At the end of the message, call the applicable finishing function.
There are three kinds of finishing function, depending on what to do
with the verification tag.
- Unauthenticated encryption and decryption does not involve a
verification tag. Call
psa_cipher_finish
. - To calculate the digest or MAC or authentication tag of a message,
call the associated function to calculate and output the
verification tag:
psa_hash_finish
,psa_mac_sign_finish
orpsa_aead_finish
. - To verify the digest or MAC of a message against a reference value
or to verify the authentication tag at the end of AEAD decryption,
call the associated function to compare the verification tag with
the reference value:
psa_hash_verify
,psa_mac_verify_finish
orpsa_aead_verify
.
- Unauthenticated encryption and decryption does not involve a
verification tag. Call
Calling the setup function allocates resources inside the
implementation. These resources are freed when calling the associated
finishing function. In addition, each family of functions defines a
function psa_xxx_abort
, which can be called at any time to free the
resources associated with an operation.
Authenticated encryption
Having a multipart interface to authenticated encryption raises specific issues.
Multipart authenticated decryption produces partial results that are not
authenticated. Applications must not use or expose partial results of
authenticated decryption until psa_aead_verify
has returned a
success status, and must destroy all partial results without revealing
them if psa_aead_verify
returns a failure status. Revealing partial
results (directly, or indirectly through the application’s behavior) can
compromise the confidentiality of all inputs that are encrypted with the
same key.
For encryption, some common algorithms cannot be processed in a
streaming fashion. For SIV mode, the whole plaintext must be known
before the encryption can start; the multipart AEAD API is not meant to
be usable with SIV mode. For CCM mode, the length of the plaintext must
be known before the encryption can start; the application can call the
function psa_aead_set_lengths
to provide these lengths before
providing input.
Key derivation
The specification defines a mechanism for key derivation that allows the output of the derivation to be split into multiple keys, as well as non-key outputs.
In an implementation with isolation, the intermediate state of the key derivation is not visible to the caller, and if an output of the derivation is a non-exportable key, then this output cannot be recovered outside the isolation boundary.
Key derivation operations
A key derivation operation encodes a deterministic method to generate a finite stream of bytes. This data stream is computed by the cryptoprocessor and extracted in chunks. If two key derivation operations are constructed with the same parameters, then they should produce the same outputs.
Some example uses of key derivation operations are:
- A key derivation function: initialized with a secret, a salt and other parameters.
- A key agreement function: initialized with a public key (peer key), a key pair (own key) and other parameters.
Applications use the psa_key_derivation_operation_t
type to create
key derivation operations.
The lifecycle of a key derivation operation is as follows:
- Setup: construct a
psa_key_derivation_operation_t
object, and set its parameters and inputs. The setup phase determines the key derivation operation’s capacity, which is the maximum number of bytes that can be output from this key derivation operation. - Output: read bytes from the stream defined by the key derivation
operation. This can be done any number of times, until the stream is
exhausted when its capacity has been reached. Each output step can
either be used to populate a key object
(
psa_key_derivation_output_key
), or to read some bytes and extract them as cleartext (psa_key_derivation_output_bytes
). - Terminate: clear the key derivation operation and release associated
resources (
psa_key_derivation_abort
).
A key derivation operation cannot be rewound. Once a part of the stream has been output, it cannot be output again. This ensures that the same part of the output will not be used for different purposes.
Key derivation function
This specification defines functions to set up a key derivation. A key derivation consists of two parts:
- Input collection. This is sometimes known as extraction: the operation “extracts” information from the inputs to generate a pseudorandom intermediate secret value.
- Output generation. This is sometimes known as expansion: the operation “expands” the intermediate secret value to the desired output length.
To perform a key derivation:
- Initialize a
psa_key_derivation_operation_t
object to zero or toPSA_KEY_DERIVATION_OPERAITON_INIT
. - Call
psa_key_derivation_setup
to select a key derivation algorithm. - Call the functions
psa_key_derivation_input_bytes
andpsa_key_derivation_input_key
, orpsa_key_derivation_key_agreement
to provide the inputs to the key derivation algorithm. Many key derivation algorithms take multiple inputs; the “step” parameter to these functions indicates which input is being passed. The documentation for each key derivation algorithm describes the expected inputs for that algorithm. - Call
psa_key_derivation_output_key
to create a derived key, orpsa_key_derivation_output_bytes
to export the derived data. These functions may be called multiple times to read successive output from the key derivation. - Call
psa_key_derivation_abort
to release the key derivation operation memory.
Here is an example of a use case where a master key is used to generate both a message encryption key and an IV for the encryption, and the derived key and IV are then used to encrypt a message.
- Derive the message encryption material from the master key.
- Initialize a
psa_key_derivation_operation_t
object to zero or toPSA_KEY_DERIVATION_OPERATION_INIT
. - Call
psa_key_derivation_setup
withPSA_ALG_HKDF
as the algorithm. - Call
psa_key_derivation_input_key
with the stepPSA_KEY_DERIVATION_INPUT_SECRET
and the master key. - Call
psa_key_derivation_input_bytes
with the stepPSA_KEY_DERIVATION_INPUT_INFO
and a public value that uniquely identifies the message. - Populate a
psa_key_attributes_t
object with the derived message encryption key’s attributes. - Call
psa_key_derivation_output_key
to create the derived message key. - Call
psa_key_derivation_output_bytes
to generate the derived IV. - Call
psa_key_derivation_abort
to release the key derivation operation memory.
- Initialize a
- Encrypt the message with the derived material.
- Initialize a
psa_cipher_operation_t
object to zero or toPSA_CIPHER_OPERATION_INIT
. - Call
psa_cipher_encrypt_setup
with the derived message encryption key. - Call
psa_cipher_set_iv
using the derived IV retrieved above. - Call
psa_cipher_update
one or more times to encrypt the message. - Call
psa_cipher_finish
at the end of the message.
- Initialize a
- Call
psa_destroy_key
to clear the generated key.
Asymmetric cryptography
The asymmetric cryptography part of this interface defines functions for asymmetric encryption, asymmetric signature and two-way key agreement.
Asymmetric encryption
Asymmetric encryption is provided through the functions
psa_asymmetric_encrypt
and psa_asymmetric_decrypt
.
Hash-and-sign
The signature and verification functions psa_asymmetric_sign
and
psa_asymmetric_verify
take a hash as one of their inputs. This hash
should be calculated with psa_hash_setup
, psa_hash_update
and
psa_hash_finish
before calling psa_asymmetric_sign
or
psa_asymmetric_verify
. To determine which hash algorithm to use,
call the macro PSA_ALG_SIGN_GET_HASH
on the corresponding signature
algorithm.
Key agreement
This specification defines two functions for a Diffie-Hellman-style key agreement where each party combines its own private key with the peer’s public key.
The recommended approach is to use a key derivation
operation with the
psa_key_derivation_key_agreement
input function, which calculates a
shared secret for the key derivation function.
In case an application needs direct access to the shared secret, it can
call psa_raw_key_agreement
instead. Note that in general the shared
secret is not directly suitable for use as a key because it is biased.
Randomness and key generation
We strongly recommended that implementations include a random generator, consisting of a cryptographically secure pseudo-random generator (CSPRNG), which is adequately seeded with a cryptographic-quality hardware entropy source, commonly referred to as a true random number generator (TRNG). Constrained implementations may omit the random generation functionality if they do not implement any algorithm that requires randomness internally, and they do not provide a key generation functionality. For example, a special-purpose component for signature verification can omit this.
Applications should use psa_generate_key
,
psa_encrypt_generate_iv
or psa_aead_generate_iv
to generate
suitably-formatted random data, as applicable. In addition, the API
includes a function psa_generate_random
to generate and extract
arbitrary random data.
Future additions
We plan to cover the following features in future drafts and editions of this specification:
- Single-shot functions for symmetric operations.
- Multi-part operations for hybrid cryptography. For example, this includes hash-and-sign for EdDSA, and hybrid encryption for ECIES.
- Key exchange and a more general interface to key derivation. This would enable an application to derive a non-extractable session key from non-extractable secrets, without leaking the intermediate material.
- Key wrapping mechanisms to extract and import keys in a protected form (encrypted and authenticated).
- Key discovery mechanisms. This would enable an application to locate a key by its name or attributes.
- Implementation capability description. This would enable an application to determine the algorithms, key types and storage lifetimes that the implementation provides.
- An ownership and access control mechanism allowing a multi-client implementation to have privileged clients that are able to manage keys of other clients.
Sample architectures
This section describes some example architectures that can be used for implementations of the interface described in this specification. This list is not exhaustive and the section is entirely non-normative.
Single-partition architecture
In this architecture, there is no security boundary inside the system. The application code may access all the system memory, including the memory used by the cryptographic services described in this specification. Thus, the architecture provides no isolation.
This architecture does not conform to the Arm Platform Security Architecture Security Model. However, it may be useful for providing cryptographic services that use the same interface, even on devices that cannot support any security boundary. So, while this architecture is not the primary design goal of the API defined in the present specification, it is supported.
The functions in this specification simply execute the underlying algorithmic code. Security checks can be kept to a minimum, since the cryptoprocessor cannot defend against a malicious application. Key import and export copy data inside the same memory space.
This architecture also describes a subset of some larger systems, where the cryptographic services are implemented inside a high-security partition, separate from the code of the main application, though it shares this high-security partition with other platform security services.
Cryptographic token and single-application processor
This system is composed of two partitions: one is a cryptoprocessor and the other partition runs an application. There is a security boundary between the two partitions, so that the application cannot access the cryptoprocessor, except through its public interface. Thus, the architecture provides cryptoprocessor isolation. The cryptoprocessor has some nonvolatile storage, a TRNG, and possibly, some cryptographic accelerators.
There are a number of potential physical realizations: the cryptoprocessor may be a separate chip, a separate processor on the same chip, or a logical partition using a combination of hardware and software to provide the isolation. These realizations are functionally equivalent in terms of the offered software interface, but they would typically offer different levels of security guarantees.
The PSA crypto API in the application processor consists of a thin layer of code that translates function calls to remote procedure calls in the cryptoprocessor. All cryptographic computations are, therefore, performed inside the cryptoprocessor. Non-volatile keys are stored inside the cryptoprocessor.
Cryptoprocessor with no key storage
As in the previous example, this system is also composed of two partitions separated by a security boundary. Thus, this architecture also provides cryptoprocessor isolation. However, unlike the previous architecture, in this system, the cryptoprocessor does not have any secure, persistent storage that could be used to store application keys.
If the cryptoprocessor is not capable of storing cryptographic material, then there is little use for a separate cryptoprocessor, since all data would have to be imported by the application.
The cryptoprocessor can provide useful services if it is able to store at least one key. This may be a hardware unique key that is burnt to one-time programmable memory during the manufacturing of the device. This key can be used for one or more purposes:
- Encrypt and authenticate data stored in the application processor.
- Communicate with a paired device.
- Allow the application to perform operations with keys that are derived from the hardware unique key.
Multi-client cryptoprocessor
This is an expanded variant of the cryptographic token plus application architecture. In this variant, the cryptoprocessor serves multiple applications that are mutually untrustworthy. This architecture provides caller isolation.
In this architecture, API calls are translated to remote procedure calls, which encode the identity of the client application. The cryptoprocessor carefully segments its internal storage to ensure that a client’s data is never leaked to another client.
Multi-cryptoprocessor architecture
This system includes multiple cryptoprocessors. There are several reasons to have multiple cryptoprocessors:
- Different compromises between security and performance for different keys. Typically, this means a cryptoprocessor that runs on the same hardware as the main application and processes short-term secrets, a secure element or a similar separate chip that retains long-term secrets.
- Independent provisioning of certain secrets.
- A combination of a non-removable cryptoprocessor and removable ones, for example, a smartcard or HSM.
- Cryptoprocessors managed by different stakeholders who do not trust each other.
The keystore implementation needs to dispatch each request to the correct processor. For example: * All requests involving a non-extractable key must be processed in the cryptoprocessor that holds that key. * Requests involving a persistent key must be processed in the cryptoprocessor that corresponds to the key’s lifetime value. * Requests involving a volatile key may target a cryptoprocessor based on parameters supplied by the application, or based on considerations such as performance inside the implementation.
Library conventions
Error handling
Return status
Almost all functions return a status indication of type
psa_status_t
. This is an enumeration of integer values, with 0
(PSA_SUCCESS
) indicating successful operation and other values
indicating errors. The exception is data structure accessor functions,
which cannot fail. Such functions may return void
or a data value.
Unless specified otherwise, if multiple error conditions apply, an implementation is free to return any of the applicable error codes. The choice of error code is considered an implementation quality issue. Different implementations may make different choices, for example to favor code size over ease of debugging or vice versa.
Note that if the behavior is undefined (for example, if a function receives an invalid pointer as a parameter), this specification makes no guarantee that the function will return an error. Implementations are encouraged to return an error or halt the application in a manner that is appropriate for the platform if the undefined behavior condition can be detected. However, application programmers should be aware that undefined behavior conditions cannot be detected in general.
Behavior on error
All function calls must be implemented atomically:
- When a function returns a type other than
psa_status_t
, the requested action has been carried out. - When a function returns the status
PSA_SUCCESS
, the requested action has been carried out. - When a function returns another status of type
psa_status_t
, no action has been carried out. The content of the output parameters is undefined, but otherwise the state of the system has not changed, except as described below.
In general, functions that modify the system state, for example, creating or destroying a key, must leave the system state unchanged if they return an error code. There are specific conditions that can result in different behavior:
- The status
PSA_ERROR_BAD_STATE
indicates that a parameter was not in a valid state for the requested action. This parameter may have been modified by the call and is now in an undefined state. The only valid action on an object in an undefined state is to abort it with the appropriatepsa_abort_xxx
function. - The status
PSA_ERROR_INSUFFICIENT_CAPACITY
indicates that a key derivation object has reached its maximum capacity. The key derivation operation may have been modified by the call. Any further attempt to obtain output from the key derivation operation will returnPSA_ERROR_INSUFFICIENT_CAPACITY
. - The status
PSA_ERROR_COMMUNICATION_FAILURE
indicates that the communication between the application and the cryptoprocessor has broken down. In this case, the cryptoprocessor must either finish the requested action successfully, or interrupt the action and roll back the system to its original state. Because it is often impossible to report the outcome to the application after a communication failure, this specification does not provide a way for the application to determine whether the action was successful. - The statuses
PSA_ERROR_STORAGE_FAILURE
,PSA_ERROR_HARDWARE_FAILURE
andPSA_ERROR_TAMPERING_DETECTED
may indicate data corruption in the system state. When a function returns one of these statuses, the system state may have changed from its previous state before the function call, even though the function call failed. - Some system states cannot be rolled back, for example, the internal state of the random number generator or the content of access logs.
Unless otherwise documented, the content of output parameters is not
defined when a function returns a status other than PSA_SUCCESS
.
Implementations should set output parameters to safe defaults to avoid
leaking confidential data and limit risk, in case an application does
not properly handle all errors.
Parameter conventions
Pointer conventions
Unless explicitly stated in the documentation of a function, all pointers must be valid pointers to an object of the specified type.
A parameter is considered a buffer if it points to an array of
bytes. A buffer parameter always has the type uint8_t *
or
const uint8_t *
, and always has an associated parameter indicating
the size of the array. Note that a parameter of type void *
is never
considered a buffer.
All parameters of pointer type must be valid non-null pointers, unless
the pointer is to a buffer of length 0 or the function’s documentation
explicitly describes the behavior when the pointer is null.
Implementations where a null pointer dereference usually aborts the
application, passing NULL
as a function parameter where a null
pointer is not allowed, should abort the caller in the habitual manner.
Pointers to input parameters may be in read-only memory. Output parameters must be in writable memory. Output parameters that are not buffers must also be readable, and the implementation must be able to write to a non-buffer output parameter and read back the same value, as explained in the “Stability of parameters” section.
Input buffer sizes
For input buffers, the parameter convention is:
const uint8_t *foo
: pointer to the first byte of the data. The pointer may be invalid if the buffer size is 0.size_t foo_length
: size of the buffer in bytes.
The interface never uses input-output buffers.
Output buffer sizes
For output buffers, the parameter convention is:
uint8_t *foo
: pointer to the first byte of the data. The pointer may be invalid if the buffer size is 0.size_t foo_size
: the size of the buffer in bytes.size_t *foo_length
: on successful return, contains the length of the output in bytes.
The content of the data buffer and of *foo_length
on errors is
unspecified, unless explicitly mentioned in the function description.
They may be unmodified or set to a safe default. On successful
completion, the content of the buffer between the offsets
*foo_length
and foo_size
is also unspecified.
Functions return PSA_ERROR_BUFFER_TOO_SMALL
if the buffer size is
insufficient to carry out the requested operation. The interface defines
macros to calculate a sufficient buffer size for each operation that has
an output buffer. These macros return compile-time constants if their
arguments are compile-time constants, so they are suitable for static or
stack allocation. Refer to an individual function’s documentation for
the associated output size macro.
Some functions always return exactly as much data as the size of the output buffer. In this case, the parameter convention changes to:
uint8_t *foo
: pointer to the first byte of the output. The pointer may be invalid if the buffer size is 0.size_t foo_length
: the number of bytes to return infoo
if successful.
Overlap between parameters
Output parameters that are not buffers must not overlap with any input buffer or with any other output parameter. Otherwise, the behavior is undefined.
Output buffers may overlap with input buffers. If this happens, the implementation must return the same result, as if the buffers did not overlap. In other words, the implementation must behave as if it had copied all the inputs into temporary memory, as far as the result is concerned. However, application developers should note that overlap between parameters may affect the performance of a function call. Overlap may also affect memory management security if the buffer is located in memory that the caller shares with another security context, as described in the “Stability of parameters” section.
Stability of parameters
In some environments, it is possible for the content of a parameter to change while a function is executing. It may also be possible for the content of an output parameter to be read before the function terminates. This can happen if the application is multithreaded. In some implementations, memory can be shared between security contexts, for example, between tasks in a multitasking operating system, between a user land task and the kernel, or between the non-secure world and the secure world of a trusted execution environment. This section describes what implementations need or need not guarantee in such cases.
Parameters that are not buffers are assumed to be under the caller’s full control. In a shared memory environment, this means that the parameter must be in memory that is exclusively accessible by the application. In a multithreaded environment, this means that the parameter may not be modified during the execution, and the value of an output parameter is undetermined until the function returns. The implementation may read an input parameter that is not a buffer multiple times and expect to read the same data. The implementation may write to an output parameter that is not a buffer and expect to read back the value that it last wrote. The implementation has the same permissions on buffers that overlap with a buffer in the opposite direction.
In an environment with multiple threads or with shared memory, the implementation carefully accesses non-overlapping buffer parameters in order to prevent any security risk resulting from the content of the buffer being modified or observed during the execution of the function. In an input buffer that does not overlap with an output buffer, the implementation reads each byte of the input once, at most. The implementation does not read from an output buffer that does not overlap with an input buffer. Additionally, the implementation does not write data to a non-overlapping output buffer if this data is potentially confidential and the implementation has not yet verified that outputting this data is authorized.
Key types and algorithms
Types of cryptographic keys and cryptographic algorithms are encoded
separately. Each is encoded by using an integral type:
psa_key_type_t
and psa_algorithm_t
, respectively.
There is some overlap in the information conveyed by key types and
algorithms. Both types contain enough information, so that the meaning
of an algorithm type value does not depend on what type of key it is
used with, and vice versa. However, the particular instance of an
algorithm may depend on the key type. For example, the algorithm
PSA_ALG_GCM
can be instantiated as any AEAD algorithm using the GCM
mode over a block cipher. The underlying block cipher is determined by
the key type.
Key types do not encode the key size. For example, AES-128, AES-192 and
AES-256 share a key type PSA_KEY_TYPE_AES
.
Structure of key and algorithm types
Both types use a partial bitmask structure, which allows the analysis and building of values from parts. However, the interface defines constants, so that applications do not need to depend on the encoding, and an implementation may only care about the encoding for code size optimization.
The encodings follows a few conventions:
- The highest bit is a vendor flag. Current and future versions of this specification will only define values where this bit is clear. Implementations that wish to define additional implementation-specific values must use values where this bit is set, to avoid conflicts with future versions of this specification.
- The next few highest bits indicate the corresponding algorithm category: hash, MAC, symmetric cipher, asymmetric encryption, and so on.
- The following bits identify a family of algorithms in a category-dependent manner.
- In some categories and algorithm families, the lowest-order bits indicate a variant in a systematic way. For example, algorithm families that are parametrized around a hash function encode the hash in the 8 lowest bits.
Concurrent calls
In some environments, an application can make calls to the PSA crypto API in separate threads. In such an environment, concurrent calls are performed correctly, as if the calls were executed in sequence, provided that they obey the following constraints:
- There is no overlap between an output parameter of one call and an input or output parameter of another call. Overlap between input parameters is permitted.
- If a call modifies a key, then no other call must modify or use that key. Using, in this context, includes all functions of multipart operations using the key. Concurrent calls that merely use the same key are permitted.
- Concurrent calls must not use the same operation object.
If any of these constraints are violated, the behavior is undefined.
Individual implementations may provide additional guarantees.
Implementation considerations
Implementation-specific aspects of the interface
Implementation profile
Implementations may implement a subset of the API and a subset of the available algorithms. The implemented subset is known as the implementation’s profile. The documentation for each implementation must describe the profile that it implements. This specification’s companion documents also define a number of standard profiles.
Implementation-specific types
This specification defines a number of platform-specific types, which
represent data structures whose content depends on the implementation.
These are C struct
types. In the associated header files,
crypto.h
declares the struct
tags and crypto_struct.h
provides a definition for the structures.
Implementation-specific macros
Some macros compute a result based on an algorithm or key type. This specification provides a sample implementation of these macros, which works for all standard types. If an implementation defines vendor-specific algorithms or key types, then it must provide an implementation for such macros that takes all relevant algorithms and types into account. Conversely, an implementation that does not support a certain algorithm or key type can define such macros in a simpler way that does not take unsupported argument values into account.
Some macros define the minimum sufficient output buffer size for certain functions. In some cases, an implementation is allowed to require a buffer size that is larger than the theoretical minimum. An implementation must define minimum-size macros in such a way that it guarantees that the buffer of the resulting size is sufficient for the output of the corresponding function. Refer to each macro’s documentation for the applicable requirements.
Porting to a platform
Platform assumptions
This specification is designed for a C89 platform. The interface is defined in terms of C macros, functions and objects.
The specification assumes 8-bit bytes, and “byte” and “octet” are used synonymously.
Platform-specific types
The specification makes use of some platform-specific types, which
should be defined in crypto_platform.h
or by a header included in
this file. crypto_platform.h
must define the following types:
uint8_t
,uint16_t
,uint32_t
: unsigned integer types with 8, 16 and 32 value bits respectively. These may be the types defined by the C99 headerstdint.h
.psa_key_handle_t
: an unsigned integer type of the implementation’s choice.
Cryptographic hardware support
Implementations are encouraged to make use of hardware accelerators where available. A future version of this specification will define a function interface that calls drivers for hardware accelerators and external cryptographic hardware.
Security requirements and recommendations
Error detection
Implementations that provide isolation between the caller and the cryptography processing environment must validate parameters to ensure that the cryptography processing environment is protected from attacks caused by passing invalid parameters.
Even implementations that do not provide isolation should strive to detect bad parameters and fail-safe as much as possible.
Memory cleanup
Implementations must wipe all sensitive data from memory when it is no longer used. They should wipe this sensitive data as soon as possible. In any case, all temporary data used during the execution of a function, such as stack buffers, must be wiped before the function returns. All data associated with an object, such as a multipart operation, must be wiped, at the latest, when the object becomes inactive, for example, when a multipart operation is aborted.
The rationale for this non-functional requirement is to minimize impact if the system is compromised. If sensitive data is wiped immediately after use, only data that is currently in use can be leaked. It does not compromise past data.
Safe outputs on error
Implementations must ensure that confidential data is not written to output parameters before validating that the disclosure of this confidential data is authorized. This requirement is especially important for implementations where the caller may share memory with another security context, as described in the “Stability of parameters” section.
In most cases, the specification does not define the content of output parameters when an error occurs. Implementations should try to ensure that the content of output parameters is as safe as possible, in case an application flaw or a data leak causes it to be used. In particular, Arm recommends that implementations avoid placing partial output in output buffers when an action is interrupted. The meaning of “safe as possible” depends on the implementation, as different environments require different compromises between implementation complexity, overall robustness and performance. Some common strategies are to leave output parameters unchanged, in case of errors, or zeroing them out.
Attack resistance
Cryptographic code tends to manipulate high-value secrets, from which other secrets can be unlocked. As such, it is a high-value target for attacks. There is a vast body of literature on attack types, such as side channel attacks and glitch attacks. Typical side channels include timing, cache access patterns, branch-prediction access patterns, power consumption, radio emissions and more.
This specification does not specify particular requirements for attack resistance. Therefore, implementers should consider the attack resistance desired in each use case and design their implementation accordingly. Security standards for attack resistance for particular targets may be applicable in certain use cases.
Other implementation considerations
Philosophy of resource management
The specification allows most functions to return
PSA_ERROR_INSUFFICIENT_MEMORY
. This gives implementations the
freedom to manage memory as they please.
Alternatively, the interface is also designed for conservative strategies of memory management. An implementation may avoid dynamic memory allocation altogether by obeying certain restrictions:
- Pre-allocate memory for a predefined number of keys, each with sufficient memory for all key types that can be stored.
- For multipart operations, in an implementation without isolation, place all the data that needs to be carried over from one step to the next in the operation object. The application is then fully in control of how memory is allocated for the operation.
- In an implementation with isolation, pre-allocate memory for a predefined number of operations inside the cryptoprocessor.
Usage considerations
Security recommendations
Always check for errors
Most functions in this API can return errors. All functions that can
fail have the return type psa_status_t
. A few functions cannot fail,
and thus, return void
or some other type.
If an error occurs, unless otherwise specified, the content of the output parameters is undefined and must not be used.
Some common causes of errors include:
- In implementations where the keys are stored and processed in a separate environment from the application, all functions that need to access the cryptography processing environment may fail due to an error in the communication between the two environments.
- If an algorithm is implemented with a hardware accelerator, which is logically separate from the application processor, the accelerator may fail, even when the application processor keeps running normally.
- All functions may fail due to a lack of resources. However, some implementations guarantee that certain functions always have sufficient memory.
- All functions that access persistent keys may fail due to a storage failure.
- All functions that require randomness may fail due to a lack of
entropy. Implementations are encouraged to seed the random generator
with sufficient entropy during the execution of
psa_crypto_init
. However, some security standards require periodic reseeding from a hardware random generator, which can fail.
Cleaning up after use
To minimize impact if the system is compromised, applications should wipe all sensitive data from memory when it is no longer used. That way, only data that is currently in use may be leaked, and past data is not compromised.
Wiping sensitive data includes:
- Clearing temporary buffers in the stack or on the heap.
- Aborting operations if they will not be finished.
- Destroying keys that are no longer used.


Gecode::Search::Seq::Probe< Tracer > Class Template Reference
Probe engine for LDS More...
#include <lds.hh>
Classes | |
| class | Node |
| Node in the search tree for LDS More... | |
Public Member Functions | |
| Probe (const Options &opt) | |
| Initialize. | |
| void | init (Space *s) |
| Initialize with space s. | |
| void | reset (Space *s, unsigned int d) |
| Reset with space s and discrepancy d. | |
| Statistics | statistics (void) const |
| Return statistics. | |
| ~Probe (void) | |
| Destructor. | |
| Space * | next (const Options &o) |
| Search for next solution | |
| bool | done (void) const |
| Test whether probing is done. | |
Protected Types | |
| typedef Tracer::ID | ID |
| Node identity type. | |
Protected Attributes | |
| Tracer | tracer |
| Search tracer. | |
| Support::DynamicStack< Node, Heap > | ds |
| Stack storing current path in search tree | |
| Space * | cur |
| Current space. | |
| unsigned int | d |
| Current discrepancy. | |
| bool | exhausted |
| Whether entire search space has been exhausted. |
Detailed Description
template<class Tracer>
class Gecode::Search::Seq::Probe< Tracer >
Probe engine for LDS
Definition at line 45 of file lds.hh.
Member Typedef Documentation
template<class Tracer >
typedef Tracer::ID Gecode::Search::Seq::Probe< Tracer >::ID [protected] |
Constructor & Destructor Documentation
template<class Tracer >
| Gecode::Search::Seq::Probe< Tracer >::Probe | ( | const Options & | opt | ) | [inline] |
template<class Tracer >
| Gecode::Search::Seq::Probe< Tracer >::~Probe | ( | void | ) | [inline] |
Member Function Documentation
template<class Tracer >
| void Gecode::Search::Seq::Probe< Tracer >::init | ( | Space * | s | ) | [inline] |
template<class Tracer >
| void Gecode::Search::Seq::Probe< Tracer >::reset | ( | Space * | s, | |
| unsigned int | d | |||
| ) | [inline] |
template<class Tracer >
| Statistics Gecode::Search::Seq::Probe< Tracer >::statistics | ( | void | ) | const [inline] |
template<class Tracer >
| Space * Gecode::Search::Seq::Probe< Tracer >::next | ( | const Options & | o | ) | [inline] |
template<class Tracer >
| bool Gecode::Search::Seq::Probe< Tracer >::done | ( | void | ) | const [inline] |
Member Data Documentation
template<class Tracer >
Tracer Gecode::Search::Seq::Probe< Tracer >::tracer [protected] |
template<class Tracer >
Support::DynamicStack<Node,Heap> Gecode::Search::Seq::Probe< Tracer >::ds [protected] |
template<class Tracer >
Space* Gecode::Search::Seq::Probe< Tracer >::cur [protected] |
template<class Tracer >
unsigned int Gecode::Search::Seq::Probe< Tracer >::d [protected] |
template<class Tracer >
bool Gecode::Search::Seq::Probe< Tracer >::exhausted [protected] |
The documentation for this class was generated from the following files:


Kernel Discriminant Analysis
Yongmin Li,
Shaogang
Gong and Heather Liddell
Department of Computer Science
Queen Mary, University of London
1. Introduction
For most pattern recognition problems, selecting
an appropriate representation to extract the most significant features
is crucially important. Principal Component Analysis (PCA) [8,10] has been widely adopted to
extract abstract features and to reduce dimensionality in many pattern
recognition problems. But the features extracted by PCA are actually
"global" features for all pattern classes, thus they are not
necessarily much representative for discriminating one class from
others. Linear Discriminant Analysis (LDA) [2,3,9], which seeks to find a linear
transformation by maximising the between-class variance and minimising
the within-class variance, has proved to be a suitable technique for
discriminating different pattern classes. However, both the PCA and
LDA are linear techniques which may be less efficient when severe
non-linearity is involved. To extract the non-linear principal
components, Kernel PCA (KPCA) [7] was developed using the
popular kernel technique [11,12]. However, similar to the linear
PCA, KPCA captures the overall variance of all patterns which are not
necessary significant for discriminant purpose. To extract the
nonlinear discriminant features, Kernel Discriminant Analysis (KDA)
[6,1,4], a nonlinear discriminating method
based on kernel techniques [11,12], was developed.
2. Kernel Discriminant Analysis
The principle of KDA can be
illustrated in Figure 1. Owing
to the severe non-linearity, it is difficult to directly compute the
discriminating features between the two classes of patterns in the
original input space (left). By defining a non-linear mapping from the
input space to a high-dimensional feature space (right), we (expect
to) obtain a linearly separable distribution in the feature
space. Then LDA, the linear technique, can be performed in the feature
space to extract the most significant discriminating
features. However, the computation may be problematic or even
impossible in the feature space owing to the high dimensionality. By
introducing a kernel function which corresponds to the non-linear
mapping, all the computation can conveniently be carried out in the
input space. The problem can be finally solved as an
eigen-decomposition problem like PCA, LDA and KPCA.
|
|
Figure 1: Kernel Discriminant Analysis.
3. A Toy Problem
We use a toy problem to illustrate the
characteristics of KDA as shown in Figure 2. Two classes of patterns
denoted by circles and crosses respectively have a significant
non-linear distribution. To make the results comparable among
different representations (PCA, LDA, KPCA and KDA), we try to separate
them with a one dimensional feature, i.e. the most significant
mode of PCA, LDA, KPCA or KDA. The first row shows the patterns and
the discriminating boundaries computed by each of the four different
methods. The second row illustrates the intensity of the
one-dimensional features given by PCA, LDA, KPCA and KDA on the region
covered by the training patterns.
|
|
Figure 2: Solving a nonlinear
classification problem with, from left to right, PCA, LDA, KPCA and
KDA. The first row shows the patterns and the discriminating
boundaries computed by each of the four methods. The second row
illustrates the intensity of the computed one-dimensional features on
the region covered by the training patterns.
4. Representing Multi-View Faces Using KDA
Face images with large pose variation demonstrate significant
nonlinearity, which makes face recognition a challenging problem. To
address this problem, we apply KDA to represent multi-view face
patterns.
In the following example (Figure 3), 540 multi-view
face patterns from 12 subjects, 45 of each, were used to train
KDA. For the sake of clarity, only the patterns of first four face
classes are shown here. To compare the performance of KDA, we also
applied PCA, LDA and KPCA to the same set of face patterns.
|
Figure 3: Distribution of multi-view
face patterns in PCA, LDA, KPCA and KDA spaces (only the first two
dimensions).
It is noted that
-
the pattern distributions using PCA and KPCA are not satisfactorily separable,
or more precisely, the variation from different subjects is even overshadowed
by that of other sources, since these two techniques are not designed for
discriminating purpose;
-
LDA performs better than PCA and KPCA, but not as good as KDA;
-
KDA provides the best discriminating performance among the four
methods.
Yongmin Li 2001-10-14


Mr Key is taking a brief break from Hooting Yard duties to attend to a number of matters in the mundane world. Rather than wailing and gnashing your teeth and rending your garments in the extremity of despair, you should pop round to Diana Sudyka's Tiny Aviary. I am most grateful to reader Richard Carter for telling me about it. Don't miss the plaster monster loon!


melissa wimberly |
web developer
back to top
home
chefs in the kitchen.
i don't 'git' it.
learning styles.
tackling css.
arrays vs hashes.
no one like me in tech
enumerable ways to solve it
feedback DUN DUN DUN...
ruby classes
stereotype threat
you down with OOP
positive thinking
ohhh JavaScript
good conflict
from Ruby to Rails
good questions
website journey


B.I.G make long-awaited comeback with MV for new single 'Illusion'
by danisurstB.I.G has released their first single in roughly 2 years!
On November 4 KST, the group unveiled the music video for their song "Illusion." While the music video is for the Korean version of the song, the boys have also recorded the single in Arabic ahead of their upcoming Abu Dhabi concert.
The lyrics of "Illusion" deal with the feeling of running into someone you had previously broken up with, finding yourself still infatuated with them and comparing them to a mirage in the loveless desert of your heart.
Check out the music video for "Illusion" above!


16.1. Installing GeoMesa Kudu¶
16.1.1. Installing the Binary Distribution¶
GeoMesa Kudu artifacts are available for download or can be built from source. The easiest way to get started is to download the most recent binary version (2.2.0-SNAPSHOT) from GitHub.
Extract it somewhere convenient:
# download and unpackage the most recent distribution:
$ wget "https://github.com/locationtech/geomesa/releases/download/geomesa_2.11-$VERSION/geomesa-kudu_2.11-$VERSION-bin.tar.gz"
$ tar xvf geomesa-kudu_2.11-$VERSION-bin.tar.gz
$ cd geomesa-kudu_2.11-$VERSION
$ ls
bin/ conf/ dist/ docs/ examples/ lib/ LICENSE.txt logs/
16.1.2. Building from Source¶
GeoMesa Kudu may also be built from source. For more information refer to Building from Source
in the developer manual, or to the README.md
file in the the source distribution.
The remainder of the instructions in this chapter assume the use of the binary GeoMesa Kudu
distribution. If you have built from source, the distribution is created in the target
directory of
geomesa-kudu/geomesa-kudu-dist
.
More information about developing with GeoMesa may be found in the Developer Manual.
16.1.3. Setting up the Kudu Command Line Tools¶
GeoMesa comes with a set of command line tools for managing Kudu features located in
geomesa-kudu_2.11-$VERSION/bin/
of the binary distribution.
In order to run distributed ingest from the command-line tools, Hadoop must be available on the classpath.
By default, GeoMesa will attempt to read Hadoop related environment variables to build the classpath. You can
configure environment variables and classpath settings in
geomesa-kudu_2.11-$VERSION/conf/geomesa-env.sh
or in your external env (e.g. bashrc file). The logic GeoMesa
uses to determine which external entries to include on the classpath is:
1. If the environmental variable
GEOMESA_HADOOP_CLASSPATH
is set then GeoMesa will use it as the classpath and skip all other logic.2. Next, if
$HADOOP_HOME
is set then GeoMesa will attempt to build the classpath by searching for JAR and configuration files in standard locations. Note that this is very specific to the installation or distribution of Hadoop you are using and may not be reliable.3. If no environmental variables are set but the
hadoop
command is available then GeoMesa will generate the classpath by runninghadoop classpath
. This method of classpath determination may be slow, so it is recommended that you manually set these variables in your environment or theconf/geomesa-env.sh
file.
If installing on a system without Hadoop, the install-hadoop.sh
scripts in the bin
directory may be used to
download the required Hadoop JARs into the lib
directory. You should edit this script to match the versions
used by your installation.
In addition, geomesa-kudu
will pull any additional entries from the GEOMESA_EXTRA_CLASSPATHS
environment variable.
Note that the GEOMESA_EXTRA_CLASSPATHS
and GEOMESA_HADOOP_CLASSPATH
variables both follow standard
Java Classpath conventions, which
generally means that entries must be directories, JAR, or zip files. Individual XML files will be ignored. For example,
to add a core-site.xml
file to the classpath you must either include a directory on the
classpath or add the file to a zip or JAR archive to be included on the classpath.
Use the geomesa-kudu classpath
command in order to see what JARs are being used.
Due to licensing restrictions, dependencies for shape file support must be separately installed. Install them with the following scripts:
$ bin/install-jai.sh
$ bin/install-jline.sh
If desired, you may use the included script bin/geomesa-kudu configure
to help set up the environment variables
used by the tools. Otherwise, you may invoke the geomesa-kudu
script using the fully-qualified path, and
use the default configuration.
Note
See Logging Configuration for information about configuring the SLF4J implementation.
Test the command that invokes the GeoMesa Tools:
$ bin/geomesa-kudu
INFO Usage: geomesa-kudu [command] [command options]
Commands:
...
For more details, see Using the Kudu Command-Line Tools.
16.1.4. Installing GeoMesa Kudu in GeoServer¶
The Kudu GeoServer plugin is bundled by default in a GeoMesa binary distribution. To install, extract
$GEOMESA_KUDU_HOME/dist/gs-plugins/geomesa-kudu-gs-plugin_2.11-$VERSION-install.tar.gz
into GeoServer’s
WEB-INF/lib
directory.
Restart GeoServer after the JARs are installed.
<IP_ADDRESS>. Jackson Version¶
Warning
Some GeoMesa functions (in particular Arrow conversion) requires jackson-core-2.6.x
. Some versions
of GeoServer ship with an older version, jackson-core-2.5.0.jar
. After installing the GeoMesa
GeoServer plugin, be sure to delete the older JAR from GeoServer’s WEB-INF/lib
folder.


Institute
Instructor
Course
Student
Certificate
Institute
Instructor
Instructor National Id:
Instructor National Id:
Course
Course Id:
Your National Id:
Course Id:
Student
Student National Id:
Certificate
Student National Id:
Certificate Id:


!= include("client/Stylesheet"); ?>
{{ generatedHTML }}
Copy to clip bord
!= include("client/Javascript"); ?>


Categories
Our Features
Free Online Courses
We link you to several online courses based on you own choices.
An Opportunity For Knowledge Exchange
You can exchange your Knowledge with another user.
Internship Opportunities
After you finish your course we can help you practice what you have learned by offer you a training.
Free Events With Public Speakers
There are always free event with our speakers to talk about different topics.


Task Feed
Boomerang
Newest
Available Tasks
Price
{{ (project.aux_attributes.median_price ? project.aux_attributes.median_price: project.price) | currency:"$":2}}
Average price
{{ project.aux_attributes.min_price | currency: "$":2}}-
${{ project.aux_attributes.min_price | number:0}}-
{{ project.aux_attributes.max_price | currency: "$":2}}
${{ project.aux_attributes.max_price | number:0}}
{{ project.name }}
{{ project.requester_handle }}
{{ project.requester_handle }}
trending_up
This requester's tasks appear at the top of your task feed.
trending_down
This requester's tasks appear at the bottom of your task feed.
{{ project.requester_handle }}
trending_up
This requester's tasks appear at the top of your task feed.
trending_down
This requester's tasks appear at the bottom of your task feed.
No tasks available


Answer the true or false questions about yourself below to find out which Programing Language is right for you


Real-time "bleeping and blurring" of web video based on dynamic configuration. Select options below, and the sample video will be scrubbed accordingly. HTML embed code is available to embed player with your configuration.
This should work in Chrome (broken due to Web Audio API bugs in Firefox and Safari). Code by POV Technology Fellow Brian Chirls is available on GitHub. Read more about this experiment on the POV blog.
Thanks to filmmaker Heather Courtney and Quincy Hill Films for allowing us to use a clip from Where Soldiers Come From. Watch the film at http://www.wheresoldierscomefrom.com/dvd/.


Below is a list of tools which might be useful in solving lessons. You will need a proxy like ZAP to solve most of the lessons.
The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
ZAP can be download from here. After installing, configure your web browser to use it as a proxy (Instructions).
Firebug is an add-on for the Firefox browser. We can use it to inspect, edit and monitor CSS, HTML and JavaScript.
Wireshark is a network protocol analyzer. You can sniff network traffic and gather useful informations this way.
There are many vulnerability scanners for your own web applications. They can find XSS, Injection Flaws and other vulnerabilities. Below are links to two open source scanner


| Institution | Years Attended | Category of School | Grades |
|---|---|---|---|
| St. Joseph's Catholic School | 1996-2006 | Elementary | X |
| Nicholson Catholic College | 2006-2010 | Secondary | Y |
| Queen's University | 2010-2015 | Post-secondary | Z |
| OnTechU (UOIT) | 2018-Present | Post-secondary | W |
This is where I would put the description for Project 1. Things included would be the team members, tools implemented, what was learned etc.
Same deal as Project 1 description, but with Project 2 instead.
This is where I would write a paragraph about myself.


Table of Contents
Previous: AN EXAMPLE
INTERPRETING THE OUTPUT
The messages given by
ftnchek include not only
syntax errors but also warnings and informational messages
about things that are legal Fortran but that may indicate errors or
carelessness.
Most of these messages can be turned off by
command-line options. Which option controls each message
depends on
the nature of the condition being warned about. See the
descriptions of the command-line flags in the previous sections,
and of individual messages below.
Each message is prefixed with a word or phrase indicating the nature
of the condition and its severity.
``Error'' means a syntax error. The simplest
kind of syntax errors are typographical errors, for example unbalanced
parentheses or misspelling of a keyword. This type of error is caught
by the parser and appears with the description ``parse error'' or
``syntax error'' (depending on whether the parser was built using GNU
bison or UNIX yacc respectively).
This type of error message cannot be
suppressed. Be aware that this type of error often means
that ftnchek has not properly interpreted the statement where the
error occurs, so that its subsequent checking operations will be
compromised. You should eliminate all syntax errors before proceeding to
interpret the other messages ftnchek gives.
``Warning: Nonstandard syntax'' indicates an extension to Fortran that
ftnchek supports but that is not according to the Fortran 77 Standard.
The extensions that ftnchek accepts
are described in the section on Extensions below.
One example is the DO ... ENDDO construction.
If a program uses these extensions, warnings will be
given according to specifications under the -f77 setting.
The default behavior is to give no warnings.
``Warning'' in other cases
means a condition that is suspicious but that may or may not
be a programming error. Frequently these conditions are legal under
the standard. Some are illegal but do not fall under the heading
of syntax errors.
Usage errors are one example.
These refer to the possibility that a variable may be used before
it has been assigned a value (generally an error),
or that a variable is declared but never used (harmless but may
indicate carelessness).
The amount of checking for usage errors is controlled by
the -usage flag, which specifies
the maximum amount of checking by default.
Truncation warnings cover situations in which accuracy may be lost
unintentionally, for example when a double precision value is assigned
to a real variable. These warnings are controlled by the
-truncation setting, which is on by default.
``Nonportable usage'' warns about some feature that may not be
accepted by some compilers even though it is not contrary
to the Fortran 77 Standard, or that may cause the program to perform
differently on different platforms.
For example, equivalencing real
and integer variables is usually a non-portable practice.
The use of extensions to the standard language is, of course, another
source of non-portability, but this is handled as a separate case. To
check a program for true portability, both the -portability and
the -f77 flags should be used. They are both turned off by
default. The -wordsize setting is provided to check only those
nonportable usages that depend on a particular machine wordsize.
``Possibly misleading appearance'' is used for legal constructions that may not
mean what they appear to mean at first glance. For example, Fortran is
insensitive to blank space, so extraneous space within variable names
or the lack of space between a keyword and a variable can convey the wrong
impression to the reader.
These messages can be suppressed by turning off the -pretty
flag, which is on by default.
Other messages that are given after all the files are processed,
and having to do with agreement between modules, do not use the word
``warning'' but generally fall into that category.
Examples include type mismatches between corresponding variables in
different COMMON
block declarations, or between dummy and actual arguments of a
subprogram.
These warnings are controlled by the -common and
-arguments settings respectively. By default both are set for
maximum strictness of checking.
Another group of warnings about conditions that are often harmless
refer to cases where the array properties of a variable
passed as a subprogram argument differ between the two routines.
For instance, an array element might be passed to a subroutine that
expects a whole array. This is a commonly-used technique for
processing single rows or columns of two-dimensional arrays.
However, it could also indicate a programming error. The
-array setting allows the user to adjust the degree of
strictness to be used in checking this kind of agreement between
actual and dummy array arguments. By default
the strictness is maximum.
``Oops'' indicates a technical
problem, meaning either a bug in ftnchek or that its resources have
been exceeded.
The syntax error messages and warnings include
the filename along with the line number and column
number. ftnchek has two different options for the
appearance of these error messages. If -novice is in effect,
which is the default,
the messages are in a style approximating
normal English. (In default style, the filename is
not printed in messages within the body of the program if -list is in
effect.) The other style of error messages is selected by the
-nonovice option. In this
style, the appearance of the messages is similar to that of the
UNIX lint program.
ftnchek is still blind to some kinds of syntax errors.
The two most important ones are detailed checking of FORMAT statements,
and almost anything to do with control of execution
flow by means of IF, DO,
and GOTO statements: namely correct nesting of control structures,
matching of opening statements such as IF ... THEN with
closing statements such as ENDIF, and the proper use of
statement labels (numbers). Most compilers will catch these errors.
See the section on Limitations for a more detailed discussion.
If ftnchek gives you a syntax error message when the compiler does
not, it may be because your program contains an extension to
standard Fortran which is accepted by the compiler but not by
ftnchek. (See the section on Extensions.)
On a VAX/VMS system, you can use the compiler option /STANDARD
to cause the compiler to accept only standard Fortran.
On most UNIX or UNIX-like systems, this can be accomplished by
setting the flag -ansi.
Many of the messages given by ftnchek are self-explanatory.
Those that need some additional explanation are listed below in
alphabetical order.
- Common block NAME: data type mismatch at position n
-
The n-th variable in the COMMON block differs in data type
in two different declarations of the COMMON block. By default
(-common strictness level 3), ftnchek is very picky about
COMMON blocks: the variables listed in them must match exactly
by data type and array dimensions. That is, the legal pair of
declarations in different modules:
COMMON /COM1/ A,B
and
COMMON /COM1/ A(2)
will cause ftnchek to give warnings at strictness level 3. These
two declarations are legal in Fortran since they both declare two real
variables. At strictness level 1 or 2, no warning would be given in
this example, but the warning would
be given if there were a data type mismatch, for instance, if B
were declared INTEGER.
Controlled by -common setting.
- Common block NAME has long data type following short data type
-
Some compilers require alignment of multi-byte items so that each item
begins at an address that is a multiple of the item size. Thus if a
short (e.g. single-precision real) item is followed by a long (e.g.
double precision real) item, the latter may not be aligned correctly.
Controlled by -portability=common-alignment option.
- Common block NAME has mixed character and non-character variables
-
The ANSI standard requires that if any variable in a COMMON
block is of type CHARACTER, then all other variables in the
same COMMON block must also be of type CHARACTER.
Controlled by -f77=mixed-common option.
- Common block NAME: varying length
-
For -common setting level 2, this message means that
a COMMON block is declared to have different numbers of words in two
different subprograms. A word is the amount of storage occupied by
one integer or real variable.
For -common setting level 3, it means that the two declarations
have different numbers of variables, where an array of any size is
considered one variable.
This is not
necessarily an error, but it may indicate that a variable is missing
from one of the lists. Note that according to the Fortran 77 Standard,
it is an error for named COMMON blocks (but not blank COMMON) to differ
in number of words in declarations in different modules.
Given for -common setting 2 or 3.
- Error: Badly formed logical/relational operator or constant
-
- Error: Badly formed real constant
-
The syntax analyzer has found the start of
one of the special words that begin and
end with a period (e.g. .EQ.), or the start of a numeric constant,
but did not succeed in finding a complete item of that kind.
- Error: cannot be adjustable size in module NAME
-
A character variable cannot be declared with a size that is an
asterisk in parentheses unless it is a dummy argument, a parameter, or
the name of the function defined in the module.
- Error: cannot be declared in SAVE statement in module NAME
-
Only local variables and common blocks can be declared in a
SAVE statement.
- Error: No path to this statement
-
ftnchek will detect statements which are ignored or by-passed because
there is no foreseeable route to the statement. For example, an
unnumbered statement (a statement without a statement label), occurring
immediately after a GOTO
statement, cannot possibly be executed.
- Error: Parse error
-
This means that the parser, which analyzes the Fortran
program into expressions,
statements, etc., has been unable to find a valid interpretation for some
portion of a statement in the program. If your compiler does not report a
syntax error at the same place, the most common explanations are: (1) use of an
extension to ANSI standard Fortran that is not recognized by
ftnchek, or (2) the statement requires more lookahead than
ftnchek uses (see section on Bugs).
-
NOTE: This message means that the affected statement is not interpreted.
Therefore, it is possible that ftnchek's
subsequent processing will be in error, if it depends on any matters
affected by this statement (type declarations, etc.).
- Error: Syntax error
-
This is the same as ``Error: Parse error'' (see above). It is generated
if your version of ftnchek was built using the UNIX yacc
parser generator rather than GNU bison.
- Identifiers which are not unique in first six chars
-
Warns that two identifiers which are longer than 6 characters do not
differ in the first 6 characters. This is for portability: they may not
be considered distinct by some compilers.
Controlled by -sixchar option.
- Nonportable usage: argument precision may not be correct for intrinsic function
-
The precision of an argument passed to an intrinsic function may be
incorrect on some computers. Issued when a numeric variable declared
with explicit precision (e.g. REAL*8 X) is passed to a
specific intrinsic function (e.g. DSQRT(X)).
Controlled by -portability=mixed-size and -wordsize.
- Nonportable usage: character constant/variable length exceeds 255
-
Some compilers do not support character strings more than 255
characters in length.
Controlled by -portability=long-string.
- Nonportable usage: File contains tabs
-
ftnchek expands tabs to be equivalent to spaces up to the next column
which is a multiple of 8. Some compilers treat tabs differently, and
also it is possible that files sent by electronic mail will have the tabs
converted to blanks in some way. Therefore files containing tabs may not
be compiled correctly after being transferred. ftnchek does not give
this message if tabs only occur within comments or character constants.
Controlled by -portability=tab.
- Nonportable usage: non-integer DO loop bounds
-
This warning is only given when the DO index and bounds are
non-integer.
Use of non-integer quantities in a DO statement may cause
unexpected errors, or different results on different machines, due to
roundoff effects.
Controlled by -portability=real-do.
- Possibly it is an array which was not declared
-
This message is appended to warnings related to
a function invocation or to an argument type
mismatch, for which the possibility exists that what appears to be a
function is actually meant to be an array. If the programmer forgot to
dimension an array, references to the array will be interpreted as
function invocations. This message will be suppressed if the name in
question appears in an EXTERNAL or INTRINSIC statement.
Controlled by the -novice option.
- Possibly misleading appearance: characters past 72 columns
-
The program is being processed with the statement field width at its
standard value of 72, and some nonblank characters have been found
past column 72. In this case,
ftnchek is not processing the characters past column 72, and is
notifying the user that the statement may not have the meaning that it
appears to have. These characters might be intended by the programmer to be
significant, but they will be ignored by the compiler. Controlled by
-pretty=long-line.
- Possibly misleading appearance: Common block declared in more than one statement
-
Such multiple declarations are legal and have the same effect as
a continuation of the original declaration of the block.
This warning is only given if the two declarations are separated by
one or more intervening statements.
Controlled by -pretty=multiple-common.
- Possibly misleading appearance: Continuation follows comment or blank line
-
ftnchek issues this warning message to alert the user that a
continuation of a statement is interspersed with comments, making it easy
to overlook.
Controlled by -pretty=continuation.
- Possibly misleading appearance: Extraneous parentheses
-
Warns about parentheses surrounding a variable by itself in an
expression. When a parenthesized variable is passed as an argument to
a subprogram, it is treated as an expression, not as a variable whose
value can be modified by the called routine.
Controlled by -pretty=parentheses.
- Subprogram NAME: argument data type mismatch at position n
-
The subprogram's
n-th actual argument (in the CALL or the
usage of a function) differs in datatype or precision from the n-th dummy
argument (in the SUBROUTINE or FUNCTION
declaration). For instance, if the user defines a
subprogram by
SUBROUTINE SUBA(X)
REAL X
and elsewhere invokes SUBA by
CALL SUBA(2)
ftnchek will detect the error. The reason here
is that the number 2 is integer, not real. The user should have written
CALL SUBA(2.0)
-
When checking an argument which is a subprogram, ftnchek must be
able to determine whether it is a function or a subroutine. The rules
used by ftnchek to do this are as follows: If the subprogram,
besides being passed as an actual argument, is also invoked directly
elsewhere in the same module, then its type is determined by that
usage. If not, then if the name of the subprogram does not appear in
an explicit type declaration, it is assumed to be a subroutine; if it
is explicitly typed it is taken as a function. Therefore, subroutines
passed as actual arguments need only be declared by an EXTERNAL
statement in the calling module, whereas functions must also be
explicitly typed in order to avoid generating this error message.
Controlled by -arguments setting.
- Subprogram NAME: argument arrayness mismatch at position n
-
Similar to the preceding situation, but
the subprogram dummy argument differs from the corresponding actual
argument in its number of dimensions or number of elements.
Controlled by -array together with -arguments settings.
- Subprogram NAME: argument mismatch at position n
-
A character dummy argument is larger than the corresponding actual
argument, or a Hollerith dummy argument is larger than the
corresponding actual argument. Controlled by -arguments setting.
- Subprogram NAME: argument usage mismatch
-
ftnchek detects a possible conflict between the way a subprogram uses
an argument and the way in which the argument is supplied to the
subprogram. The conflict can be one of two types, as outlined below.
-
Dummy arg is modified, Actual arg is const or expr
A dummy argument is an argument as named in a SUBROUTINE or
FUNCTION statement and used within the subprogram. An actual
argument is an argument as passed to a subroutine or function by the
caller. ftnchek is saying that a dummy argument is modified by
the subprogram, implying that its value is changed in the calling module.
The corresponding actual argument should not be a constant or
expression, but rather a variable or array element which can be
legitimately assigned to.
Controlled by the -usage=arg-const-modified option.
-
Dummy arg used before set, Actual arg not set
Here a dummy argument may be used in the subprogram
before having a value assigned to it by the subprogram. The
corresponding actual argument should have a value assigned to it by the
caller prior to invoking the subprogram.
Controlled by the -usage=var-uninitialized option.
-
This warning is not affected by the -arguments setting.
- Subprogram NAME invoked inconsistently
-
Here the mismatch is between the datatype of the subprogram itself as
used and as defined. For instance, if the user declares
INTEGER FUNCTION COUNT(A)
and invokes COUNT in another module as
N = COUNT(A)
without declaring its datatype, it will default to real type, based on
the first letter of its name. The calling module should have included
the declaration
INTEGER COUNT
-
Given for -arguments setting 2 or 3.
- Subprogram NAME: varying length argument lists:
-
An inconsistency has been found between the number of dummy arguments
(parameters) a subprogram has and the number of actual arguments given it
in an invocation.
ftnchek keeps track of all invocations of subprograms
(CALL
statements and expressions using functions) and compares them with
the definitions of the subprograms elsewhere in the source code. The
Fortran compiler normally does not catch this type of error.
Given for -arguments setting 1 or 3.
- Variable not declared. Type has been implicitly defined
-
When printing the symbol table for a module,
ftnchek will flag with an asterisk
all identifiers that are not explicitly typed
and will show the datatype that was assigned through implicit typing.
This provides support for users who wish to declare all variables as
is required in Pascal or some other languages.
This message appears only when the -symtab option is in effect.
Alternatively, use the -declare flag if you want to get a list of all
undeclared variables.
- Variables declared but never referenced
-
Detects any identifiers that were declared in your program but were
never used, either to be assigned a value or to have their value
accessed. Variables in COMMON are excluded.
Controlled by the -usage=var-unused option.
- Variables set but never used
-
ftnchek will notify the user when a variable has been assigned a
value, but the variable is not otherwise used in the program. Usually
this results from an oversight.
Controlled by the -usage=var-set-unused option.
- Variables used before set
-
This message indicates that an identifier is used to compute a value
prior to its initialization. Such usage may lead to an incorrect value
being computed, since its initial value is not controlled.
Controlled by the -usage=var-uninitialized option.
- Variables may be used before set
-
Similar to used before set except that ftnchek is not able to
determine its status with certainty. ftnchek assumes a variable
may be used before set if the first usage of the variable occurs prior
in the program text to its assignment.
Controlled by the -usage=var-uninitialized option.
- Warning: DO index is not integer
-
This warning is only given when the DO bounds are integer, but
the DO index is not. It may indicate a failure to declare the
index to be an integer.
Controlled by -truncation=real-do option.
- Warning: integer quotient expr ... converted to real
-
The quotient of two integers results in an integer type result, in
which the fractional part is dropped. If such an integer expression
involving division is later converted to a real datatype, it may be that
a real type division had been intended.
Controlled by -truncation=int-div-real option.
- Warning: Integer quotient expr ... used in exponent
-
The quotient of two integers results in an integer type result, in
which the fractional part is dropped. If such an integer expression
is used as an exponent, it is quite likely that a real type division was
intended.
Controlled by -truncation=int-div-exponent option.
- Warning: NAME not set when RETURN encountered
-
The way that functions in Fortran return a value is by assigning the
value to the name of the function. This message indicates that the
function was not assigned a value before the point where a
RETURN statement was found. Therefore it is possible that the
function could return an undefined value.
- Warning: Nonstandard syntax: adjustable size cannot be concatenated here
-
The Fortran 77 Standard (sec. 6.2.2) forbids concatenating character variables
whose size is an asterisk in parentheses, except in an assignment
statement. Controlled by -f77=mixed-expr.
- Warning: Nonstandard syntax : significant characters past 72 columns
-
This warning is given under the -f77=long-line setting if the
-columns setting has been used to increase the statement field width,
and a statement has meaningful program text beyond column 72.
Standard Fortran ignores all text in those columns, but some compilers
do not. Thus the program may be treated differently by different
compilers.
- Warning: Nonstandard syntax : Statement out of order.
-
ftnchek will detect statements that are out of the
sequence specified for ANSI standard Fortran 77. Table 1 illustrates the
allowed sequence of statements in the Fortran language. Statements which are
out of order are nonetheless interpreted by
ftnchek,
to prevent ``cascades'' of error messages.
The sequence counter is also rolled back to prevent
repetition of the error message for a block of similar statements.
Controlled by the -f77=statement-order option.
-
--------------------------------------------------------
| | implicit
| parameter |---------------------
| | other specification
format |---------------|---------------------
and | | statement-function
entry | data |---------------------
| | executable
--------------------------------------------------------
Table 1
- Warning: Possible division by zero
-
This message is printed out wherever division is done (except division
by a constant). Use it to
help locate a runtime division by zero problem.
Controlled by -division option.
- Warning: real truncated to intg
-
ftnchek has detected an assignment statement which has a real
expression on the right, but an integer variable on the left. The
fractional part of the real value will be lost. If you explicitly
convert the real expression to integer using the INT or
NINT intrinsic function, no warning will be printed. A similar
message is printed if a double precision expression is assigned to a
single precision variable, etc.
Controlled by -truncation=demotion option.
- Warning: subscript is not integer
-
Since array subscripts are normally integer quantities, the use of a
non-integer expression here may signal an error.
Controlled by -truncation=real-subscript option.
- Warning: Unknown intrinsic function
-
This message warns the user that a name declared in an
INTRINSIC statement is unknown to ftnchek. Probably it is
a nonstandard intrinsic function, and so the program will not be
portable. The function will be treated by ftnchek as a
user-defined function. This warning is not suppressed by any
option, since it affects ftnchek's analysis of
the program. However, if the intrinsic function is in one of the
supported sets of nonstandard intrinsics, you can use the
-intrinsic setting to cause ftnchek to recognize it.
Next: LIMITATIONS AND EXTENSIONS


Name: Nishkarsh Raj
House Number: 180
Sector: J
Colony: Aashiana Colony
Road: Kanpur
City: Lucknow
State: Uttar Pradesh


The first idea can be to list the languages with |
in-between.
But that doesn’t work right:
```js run let regexp = /Java|JavaScript|PHP|C|C++/g;
let str = “Java, JavaScript, PHP, C, C++”;
alert( str.match(regexp) ); // Java,Java,PHP,C,C ```
The regular expression engine looks for alternations one-by-one. That is: first it checks if we have match:Java
, otherwise – looks for match:JavaScript
and so on.
As a result, match:JavaScript
can never be found, just because match:Java
is checked first.
The same with match:C
and match:C++
.
There are two solutions for that problem:
pattern:JavaScript|Java|C\+\+|C|PHP
.pattern:Java(Script)?|C(\+\+)?|PHP
.In action:
```js run let regexp = /Java(Script)?|C(++)?|PHP/g;
let str = “Java, JavaScript, PHP, C, C++”;
alert( str.match(regexp) ); // Java,JavaScript,PHP,C,C++ ```