Skip to content

FormatFloat wrong result on macOS / FPC trunk

Summary

SysUtils FormatFloat function produces zeros irrespective of the passed value (FPC trunk / macOS).

It does work correctly with FPC 3.2.2 on the very same machine.

Also works fine on Linux/amd64 FPC trunk.

System Information

  • Operating system: macOS Sequoia 15.3.1
  • Processor architecture: AARCH64 (Apple M2)
  • Compiler version: Free Pascal Compiler version 3.3.1-17610-gd91be468da [2025/03/07] for aarch64
  • Device: MacBook Air

Steps to reproduce

program FFloat;
 
uses
  SysUtils;
 
begin
  WriteLn(FormatFloat('#.##', 3.1416));
end.

Example Project

https://gist.github.com/olatov/747c6e32b23c11de4b8fcb02f30b8f2e

What is the current bug behavior?

Prints 0.00

What is the expected (correct) behavior?

Prints 3.14

Possible fixes

The debugger got me to this line

https://gitlab.com/freepascal.org/fpc/source/-/blob/d91be468dadc5cf2c66efb2596ba4f45d31dc80b/rtl/objpas/sysutils/sysstr.inc?page=3#L2450

and it looks like the PChar cast mangles Value somehow. I've no idea how though.

It has something to do with TFormatSettings record passed to FloatToTextFmt underline call. I can see this invokes Move procedure (alias FPC_MOVE) - copying to the procedure's stack, I assume? So on most platforms FPC has the implementation in assembly, though in macOS/aarch64 it's delegated to external clib name 'bcopy'. Which is either doing not exactly what's needed - or perhaps is called incorrectly.

https://gitlab.com/freepascal.org/fpc/source/-/blob/2ff7f45a362c7fd592206c17ba5a789c5353cb22/rtl/inc/cgeneric.inc#L31

Edited by Oleg Latov
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information