HEX2OCT Function (Gnumeric)
Convert hexadecimal text to octal with Gnumeric HEX2OCT, with reproducible native examples, padded fields, parser behavior and range restrictions.
Verification status: 18 reference, boundary and advanced-check formulas were recalculated through Gnumeric 1.12.57 ssconvert with retained native formula identities and ODF results. Independent arithmetic and 1.12.62 source were also checked; 1.12.62 was not executed. How formula examples are checked
Quick answer: =HEX2OCT("FF",4) returns 0377 in Gnumeric 1.12.57. The result is text, so leading zeroes are significant for its displayed representation.
Availability and version history
- Introduced: First release not established.
- Supported in: Gnumeric 1.12.62, with no retirement established.
- Scope: Desktop Gnumeric with the Engineering plugin; English comma-separated formulas are used below.
- Checked: October 14, 2026. The reference and boundary tables plus the explicit roundtrip or recurrence were recalculated through 1.12.57 ssconvert and compared with native formula records, source and independent arithmetic. 1.12.62 is source-checked only.
What HEX2OCT returns
HEX2OCT decodes hexadecimal input and returns octal text. Hexadecimal FF means decimal 255, so the octal result is 377. Changing the representation does not change the underlying integer. Versioned function help.
Syntax and arguments
=HEX2OCT(x[,places])
x is required. Use a quoted hexadecimal string or a text cell, especially for identifiers that contain only digits or leading zeroes. Optional places pads a positive result up to ten digits; a smaller-than-required width fails rather than discarding digits. Brackets mark optional arguments and are not typed into the formula. Function implementation.
Reproducible examples
Backticks preserve the exact digits and padding; text encodings are not decimal quantities. All eight reference rows below were recalculated in the stated 1.12.57 build.
| Formula | Gnumeric 1.12.57 result |
|---|---|
=HEX2OCT("0") |
0 |
=HEX2OCT("A") |
12 |
=HEX2OCT("f") |
17 |
=HEX2OCT("FF",4) |
0377 |
=HEX2OCT("1CD") |
715 |
=HEX2OCT("1FF") |
777 |
=HEX2OCT("200") |
1000 |
=HEX2OCT("FFFFFFF") |
1777777777 |
Practical worksheet
Place the hexadecimal text FF in A2. =HEX2OCT(A2,4) gives 0377, a four-character octal representation of 255. Keep the original field, decoded meaning and target field width in separate columns when exchanging data with another system.
Octal output uses only digits 0 through 7. Numeric-looking text such as 0377 can be accidentally converted to decimal 377 on import, so the target system must know the field is octal.
Advanced checks and interpretation
The executed roundtrip =OCT2HEX(HEX2OCT("01CD"),4) returns 01CD. Its intermediate value is octal 715, representing decimal 461. Explicitly restoring four hexadecimal places checks the chosen field convention as well as the value.
The larger reference FFFFFFF represents decimal 268435455 and becomes octal 1777777777. It is still below the signed octal threshold of 4000000000.
Boundaries and troubleshooting
The native string FFFFFFFFFF was rejected with #NUM!. Do not import a generic ten-digit hexadecimal complement rule from another spreadsheet and assume it applies to this quoted-input path. The shared parser checks a decoded-value maximum of 9999999999 before sign conversion.
Lowercase “f” is accepted, and the shown “0xFF” prefix also works through the integer parser. Spaces around “FF”, a literal minus sign and an invalid G digit fail. Quote the exact input format you intend to support; accepting one prefix does not establish every prefix or suffix convention.
In the following tests F5 is an actually empty cell. The empty string "", when present, is an explicit string argument.
| Formula | Gnumeric 1.12.57 result |
|---|---|
=HEX2OCT("G") |
#NUM! |
=HEX2OCT("-1") |
#NUM! |
=HEX2OCT(" FF ") |
#NUM! |
=HEX2OCT("0xFF") |
377 |
=HEX2OCT("") |
0 |
=HEX2OCT(F5) |
#NUM! |
=HEX2OCT("FF",2) |
#NUM! |
=HEX2OCT("FFFFFFFFFF") |
#NUM! |
=HEX2OCT("A",3.9) |
012 |
Conversion and version limits
The shared conversion helper controls parsing, complement handling and width checks. The individual function entry is unchanged between the inspected 1.12.57 and 1.12.62 sources, but the shared digit-extraction helper changed. These native results therefore establish 1.12.57, not automatic equivalence for every 1.12.62 boundary. A stale SUM cache and an uncached SUM formula both recalculated correctly, with original function identities retained. Other locales, GUI entry and extreme values beyond the listed cases were not tested.