View Issue Details

IDProjectCategoryView StatusLast Update
0031119FPCRTLpublic2018-02-04 19:40
ReporterThaddy de Koning Assigned ToFlorian  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionwon't fix 
Product Version3.1.1 
Summary0031119: FEATURE REQUEST hiword,loword,hibyte,lobyte etc.
DescriptionThe hiword,loword,hibyte etc functions(essentially macro's) are atm windows only.
It occurred today, however, that these functions have also cross-platform application. I therefor suggest it may be a good idea to include them in the RTL, so that they are available to all platforms.
Additional InformationE.g.:,35123.msg231836.html#msg231836
TagsNo tags attached.
Fixed in Revision
Attached Files


has duplicate 0033128 resolvedMichael Van Canneyt Compiler does not respect evaluation order with HI/LO 


Adriaan van Os

2016-12-15 10:56

developer   ~0096800

Note that the following functions are also in univint/ToolUtils.pas for Mac OS X

function HiWord(arg: SInt32): SInt16; inline; overload;
function HiWord(arg: UInt32): UInt16; inline; overload;
function LoWord(arg: SInt32): SInt16; inline; overload;
function LoWord(arg: UInt32): UInt16; inline; overload;

Thaddy de Koning

2016-12-15 11:06

reporter   ~0096801

Yes, these also show up in a grep over the sourcecode. But this only shows it is not universal. Where it can be.

Adriaan van Os

2016-12-15 11:16

developer   ~0096802

I mean, if they are added to the FPC runtime, they should be removed from univint/ToolUtils.pas

Sergei Gorelkin

2016-12-15 11:34

developer   ~0096803

These are in system unit since ages, called hi(x) and lo(x).

Thaddy de Koning

2016-12-15 11:48

reporter   ~0096804

I totally forgot about that. Plz close.

Note, however, that in that case I do not understand the inclusion of different implementations of existing functionality in MAC OSxX and Windows.....

Adriaan van Os

2016-12-15 12:03

developer   ~0096805

From the FPC Units Reference Guide:

function hi(b: Byte) : Byte
function hi(i: Integer) : Byte
function hi(w: Word) : Byte
function hi(l: LongInt) : Word
function hi(l: DWord) : Word
function hi(i: Int64) : DWord
function hi(q: QWord) : DWord

I find that asking for trouble, returning a Byte, Word or DWord depending on the context. Also, the result can be signed or unsigned.

An explicit LoByte/LoWord/LoDWord and HiByte/HiWord/HiDWord would be definitely better.

Thaddy de Koning

2016-12-15 12:11

reporter   ~0096806

Last edited: 2016-12-15 12:16

View 3 revisions

No, what Sergei wrote is perfectly correct. Hi/Lo returns a variable half the size of the input. Which is completely logical.

@Adriaan if you want to pursue it, plz do, but I ask for close.

(Maybe the nibbles are a bit off ;) )

As far as I am concerned, harking into the darker side of the language surprises me every time, even if I knew I used a feature before.

Adriaan van Os

2016-12-15 12:58

developer   ~0096808

1. With implicit type conversions, it is not always clear what the type is. Therefore, as always, EXPLICIT is better than IMPLICIT. With Hi and Lo you can run into surprising bugs. If you don't see that, then I am sorry for your Pascal skills.

2. As I wrote, we have to distinguish between signed and unsigned output.

Thaddy de Koning

2016-12-15 13:06

reporter   ~0096809

Last edited: 2016-12-15 20:36

View 4 revisions

@Adriaan: of course I see the bugs, but those bugs are not part of my report.
Open a new one, if required.

Also note that signed integers can not be processed using hi/lo and that has never been possible without a programmer that has sufficient knowledge to see the sign bit ........
[edit]signed from unsigned.

Adriaan van Os

2016-12-15 21:45

developer   ~0096821


procedure test;
        theInt : SmallInt;
      theInt := 257;
        ( Lo( theInt));
        ( Lo( theInt * 1));
      theInt := -257;
        ( Lo( theInt));
        ( Lo( theInt * 1))

This will print


For me, Lo and Hi are evil functions, typical for Delphi. So, we do need HiWord, LoWord, HiByte, LoByte etc, which is what this bug report is about.


2016-12-15 22:41

administrator   ~0096823

Overloading lo/hi was probably not the best choice, but it can be easily solved by a cast of the argument if it is really needed.

The MacOS ones are not unique either btw.

Issue History

Date Modified Username Field Change
2016-12-15 10:36 Thaddy de Koning New Issue
2016-12-15 10:56 Adriaan van Os Note Added: 0096800
2016-12-15 11:06 Thaddy de Koning Note Added: 0096801
2016-12-15 11:16 Adriaan van Os Note Added: 0096802
2016-12-15 11:34 Sergei Gorelkin Note Added: 0096803
2016-12-15 11:48 Thaddy de Koning Note Added: 0096804
2016-12-15 12:03 Adriaan van Os Note Added: 0096805
2016-12-15 12:11 Thaddy de Koning Note Added: 0096806
2016-12-15 12:13 Thaddy de Koning Note Edited: 0096806 View Revisions
2016-12-15 12:16 Thaddy de Koning Note Edited: 0096806 View Revisions
2016-12-15 12:58 Adriaan van Os Note Added: 0096808
2016-12-15 13:06 Thaddy de Koning Note Added: 0096809
2016-12-15 13:12 Thaddy de Koning Note Edited: 0096809 View Revisions
2016-12-15 20:35 Thaddy de Koning Note Edited: 0096809 View Revisions
2016-12-15 20:36 Thaddy de Koning Note Edited: 0096809 View Revisions
2016-12-15 21:45 Adriaan van Os Note Added: 0096821
2016-12-15 22:41 Florian Note Added: 0096823
2016-12-15 22:41 Florian Status new => resolved
2016-12-15 22:41 Florian Resolution open => won't fix
2016-12-15 22:41 Florian Assigned To => Florian
2018-02-04 19:40 Florian Relationship added has duplicate 0033128