The Wiert Corner – irregular stream of stuff

Quite some time ago, I was researching spurious exceptions in a Delphi application, then finally replicated them in a unit test suite.

One of them was occurring almost all of the time: EInvalidOp.

It is one of the floating point exceptions (incidentally exampled at [WayBack] Exceptions: Declaring Exception Types) all inheriting from the [WayBack] EMathError Class:

EMathError is the base class for floating-point math exception classes. EMathError itself is never raised.

The following exceptions descend from EMathError:

[WayBack] Exception	Meaning
[WayBack] EInvalidArgument	Parameter out of range
[WayBack] EInvalidOp	Processor encountered an undefined instruction
[WayBack] EOverflow	Floating-point operation produced result too large to store
[WayBack] EUnderflow	Floating-point operation produced result with no precision
[WayBack] EZeroDivide	Attempt to divide by zero

Run-time exception information is saved in fields provided by [WayBack] EExternal.

Use-after-free

In my first case (which I described in delphi – Invalid floating point operation calling Trunc()), not all input scenarios had been tested in a certain scenario. In a production environment, one of the inputs was really high.

In a later case, the actual cause was not a floating point problem at all, but a use-after-free scenario that overwrite a floating point value with something not so compatible also causing a simple Trunc statement to fail in the same way.

In that case, the production data could never reach the big numbers that failed, so no new tests were needed.

–jeroen

(Tagged FastMM4 as that’s the first code I saw these warnings to be turned off)

Delphi 7 introduced introduced warnings for unsafe constructs like W1047 and W1048 so you could prepare your code for the first Delphi .NET compilers .

The oldest online documentation on this is in Delphi 2007:

• [WayBack] Unsafe Code (Delphi for .NET)
  

  Type	Switch
  Syntax	{$UNSAFECODE ON} or {$UNSAFECODE OFF}
  Default	{$UNSAFECODE OFF}
  Scope	Local

• [WayBack] W1046: Unsafe type ‘%s%s%s’
  

  You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. In a secured execution environment such as .NET, such code is assumed to be unsafe and a potential security risk.

• [WayBack] W1047: Unsafe code ‘%s’
  

  You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. In a secured execution environment such as .NET, such code is assumed to be unsafe and a potential security risk.

• [WayBack] W1048: Unsafe typecast of ‘%s’ to ‘%s’
  

  You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. In a secured execution environment such as .NET, such code is assumed to be unsafe and a potential security risk.

• [WayBack] E2395: Unsafe procedure only allowed if compiling with {$UNSAFECODE ON}
• [WayBack] E2396: Unsafe code only allowed in unsafe procedure
• [WayBack] E2397: Unsafe pointer only allowed if compiling with {$UNSAFECODE ON}
• [WayBack] E2406: EXPORTS section allowed only if compiling with {$UNSAFECODE ON}
• [WayBack] E2410: Unsafe pointer variables, parameters or consts only allowed in unsafe procedure
• [WayBack] Delphi 2007 help Index

After Delphi 2007, the .NET compiler got shelved, but the errors and warning stayed as they serve a good purpose for native code as well.

Delphi 2007 did not document any of the other directives.

Unlike the D2007 documentation, however, the UNSAFECODE should be written UNSAFE_CODE as with using {$WARN UNSAFECODE ON}, you will get this error:

E1030 Invalid compiler directive: 'UNSAFECODE'

Looking at the library code and example code that ships with Delphi, these are the valid $WARN compiler directives having to do with UNSAFE:

• UNSAFE_CAST (since Delphi 7, but only used in Vcl.WinXPanels.pas introduced in Delphi 10.2 Tokyo and up)
• UNSAFE_CODE (since Delphi 7, but still documented as UNSAFECODE)
• UNSAFE_TYPE (since Delphi 7)
• UNSAFE_VOID_POINTER (since Delphi XE3, as precursor to the NEXTGEN compilers)

The ultimate source for these is the file DCCStrs.pas that has shipped since Delphi 2009: [WayBack] warnings – Identifiers for Delphi’s $WARN compiler directive – Stack Overflow.

A problem is that current documentation still lists the wrong name in many places:

• [WayBack] Table Of Contents – RAD Studio
• [WayBack] IDEIds05 – RAD Studio
• [WayBack] IDEIds08 – RAD Studio
• [WayBack] IDEIds20 – RAD Studio although this also contains the right one:
  

  • UNSAFE_TYPE
    • W1046 Unsafe type ‘%s%s%s’ (Delphi)
  • UNSAFE_CODE
    • W1047 Unsafe code ‘%s’ (Delphi)
  • UNSAFE_CAST
    • W1048 Unsafe typecast of ‘%s’ to ‘%s’ (Delphi)

• [WayBack] E2395 Unsafe procedure only allowed if compiling with {$UNSAFECODE ON} (Delphi) – RAD Studio
• [WayBack] E2397 Unsafe pointer only allowed if compiling with {$UNSAFECODE ON} (Delphi) – RAD Studio
• [WayBack] E2406 EXPORTS section allowed only if compiling with {$UNSAFECODE ON} (Delphi) – RAD Studio

This one finally got it right: [WayBack] Warning messages (Delphi) – RAD Studio

UNSAFE_TYPE	W1046
UNSAFE_CODE	W1047
UNSAFE_CAST	W1048

Note it also documented UNSAFE_VOID_POINTER:

UNSAFE_VOID_POINTER

W1070

[WayBack] W1070 Use of untype pointer can disrupt instance reference counts (Delphi) – RAD Studio

And these warning messages still do not contain the directives, but do explain the underlying code construct better:

• [WayBack] W1046 Unsafe type ‘%s%s%s’ (Delphi) – RAD Studio
  

  You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. For example, you might receive this warning if you declare something as absolute. Such code can be considered a security risk.

• [WayBack] W1047 Unsafe code ‘%s’ (Delphi) – RAD Studio
  

  You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. Such code can be considered a security risk.For example, using GetMem can elicit this warning because a block of memory has no associated type.

• [WayBack] W1048 Unsafe typecast of ‘%s’ to ‘%s’ (Delphi) – RAD Studio
  

  You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. For example, you might have cased one record to another or one instance to another.

You have to use these directives:

// Get rid of "W1047 Unsafe code 'ASM'", "W1047 Unsafe code '^ operator'", "W1047 Unsafe code '@ operator'" and similar

{$WARN UNSAFE_CODE OFF}

// Get rid of "W1048 Unsafe typecast of 'TFreedObject' to 'PByte'" and similar

{$WARN UNSAFE_CAST OFF}

Back in the days, some people were not amused and disabled the warnings, for instance in [Archive.is] Re: How can I eliminate these warnings in Delphi 7 which did not appear in Delphi 5. – Google Groups:

Dennis Passmore:

I have one include file that I usually include in all projects as follows—– WarningsOff.inc —————-
{$IFDEF CONDITIONALEXPRESSIONS}
  {$IF CompilerVersion >= 14}
{$WARN SYMBOL_PLATFORM OFF}
{$WARN SYMBOL_DEPRECATED OFF}
{$WARN SYMBOL_LIBRARY OFF}
{$WARN UNIT_DEPRECATED OFF}
{$WARN UNIT_LIBRARY OFF}
{$WARN UNIT_PLATFORM OFF}

{$WARN UNSAFE_TYPE OFF}
{$WARN UNSAFE_CODE OFF}
{$WARN UNSAFE_CAST OFF}

  {$IFEND}
{$ENDIF}
———————and it gets ride of all unwanted warnings in the IDE or even DCC32.exe when compiling the project
from the command line.

I just add the following line to the project .dpr file and do not worry about the rest.

{$I WarningsOff.inc}

Dennis Passmore

“If you cannot conceive the idea you
will never achieve the desired results”

I disagree with such an approach, as those warnings have their purpose.

Knowing how to selectively disable/enable them however, is important.

–jeroen