In general as programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Statements that are removed from a language are usually replaced by newer counterparts that perform the same task in somewhat different and hopefully better way.

In particular, SAP ABAP evolved to include ABAP Objects - the object oriented extension of ABAP and to operate in a Unicode compatible environment. As a result, stricter syntax is enforced in classes or in Unicode programs. Obsolete constructs are still available only for reasons of compatibility with older releases and they can only be used outside of classes or in non-Unicode programs. There are replacement constructions for all obsolete language elements, which improve the efficiency and readability of programs. Many implicit, ambiguous type/length/memory specifications in the obsolete syntax are required to be specified in a more precise and explicit way in the newer syntax. It is recommended to adopt the newer syntax to make programs easier to understand, more robust and easier to maintain.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations


Functions that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example 1: The following code constructs a new SqlClientPermission object, which regulates how users are allowed to connect to a database. In this example, the program passes false as the second parameter to the constructor, which controls whether users are allowed to connect with blank passwords. Passing false to this parameter indicates that blank passwords should not be allowed.

...
SCP = new SqlClientPermission(pstate, false);
...

However, because the PermissionState object passed as the first parameter supersedes any value passed to the second parameter, the constructor allows blank passwords for database connections, which contradicts the second argument. To disallow blank passwords, the program should pass PermissionState.None to the first parameter of the constructor. Because of the ambiguity in its functionality, the two-parameter version of the SqlClientPermission constructor has been deprecated in favor of the single parameter version, which conveys the same degree of information without the risk of misinterpretation.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language.
- Improved understanding of how operations should be performed effectively and securely.
- Changes in the conventions that govern certain operations.

Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.
Example 1: The following code uses the deprecated function getpw() to verify that a plain text password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0.

	...
	getpw(uid, pwdline);
	for (i=0; i<3; i++){
	cryptpw=strtok(pwdline, ":");
		pwdline=0;
	}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
	...

Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations.

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example 1: The following code uses the Digest::HMAC stdlib, which use of is explicitly discouraged in the documentation due to accidental involvement within a release.

require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...

In this example the Digest::HMAC class was deprecated immediately upon involvement due to accidental inclusion within a release. Due to possibility of this not working as expected because of experimental and not properly tested code, use of this is highly discouraged, especially considering the relation HMACs have in relation to cryptographic functionality.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

Due to the fast-paced nature of smart contracts, functions and operators may become deprecated with newer compiler versions and using them may lead to low quality code, unintended side effects and/or compilation errors.

Example 1: The following code obtains the hash of the current block using block.blockhash(), which has been deprecated since version 0.5.0 of the Solidity compiler.

bytes32 blockhash = block.blockhash(0);