Editing Endianness (section)

== Software ==

=== Logic design ===

[[Hardware description language]]s (HDLs) used to express digital logic often support arbitrary endianness, with arbitrary granularity. For example, in [[SystemVerilog]], a word can be defined as little-endian or big-endian.{{cn|date=November 2023}}

=== Files and filesystems ===

The recognition of endianness is important when reading a file or filesystem created on a computer with different endianness.

Fortran sequential unformatted files created with one endianness usually cannot be read on a system using the other endianness because Fortran usually implements a [[storage record|record]] (defined as the data written by a single Fortran statement) as data preceded and succeeded by count fields, which are integers equal to the number of bytes in the data. An attempt to read such a file using Fortran on a system of the other endianness results in a run-time error, because the count fields are incorrect.

[[Unicode]] text can optionally start with a [[byte order mark]] (BOM) to signal the endianness of the file or stream. Its code point is U+FEFF. In [[UTF-32]] for example, a big-endian file should start with {{code|00 00 FE FF|class=nowrap}}; a little-endian should start with {{code|FF FE 00 00|class=nowrap}}.

Application binary data formats, such as [[MATLAB]] ''.mat'' files, or the ''.bil'' data format, used in topography, are usually endianness-independent. This is achieved by storing the data always in one fixed endianness or carrying with the data a switch to indicate the endianness. An example of the former is the binary [[XLS file]] format that is portable between Windows and Mac systems and always little-endian, requiring the Mac application to swap the bytes on load and save when running on a big-endian Motorola 68K or PowerPC processor.<ref>{{cite web |url=http://download.microsoft.com/download/0/B/E/0BE8BDD7-E5E8-422A-ABFD-4342ED7AD886/Excel97-2007BinaryFileFormat(xls)Specification.xps |title=Microsoft Office Excel 97 - 2007 Binary File Format Specification (*.xls 97-2007 format) |year=2007 |publisher=Microsoft Corporation |access-date=2014-08-18 |archive-date=2008-12-22 |archive-url=https://web.archive.org/web/20081222093136/http://download.microsoft.com/download/0/B/E/0BE8BDD7-E5E8-422A-ABFD-4342ED7AD886/Excel97-2007BinaryFileFormat(xls)Specification.xps |url-status=live }}</ref>

[[TIFF]] image files are an example of the second strategy, whose header instructs the application about the endianness of their internal binary integers. If a file starts with the signature {{code|MM}} it means that integers are represented as big-endian, while {{code|II}} means little-endian. Those signatures need a single 16-bit word each, and they are [[palindrome]]s, so they are endianness independent. {{code|I}} stands for [[Intel]] and {{code|M}} stands for [[Motorola]]. Intel CPUs are little-endian, while Motorola 680x0 CPUs are big-endian. This explicit signature allows a TIFF reader program to swap bytes if necessary when a given file was generated by a TIFF writer program running on a computer with a different endianness.

As a consequence of its original implementation on the Intel 8080 platform, the operating system-independent [[File Allocation Table]] (FAT) file system is defined with little-endian byte ordering, even on platforms using another endianness natively, necessitating byte-swap operations for maintaining the FAT on these platforms.

[[ZFS]], which combines a [[filesystem]] and a [[logical volume manager]], is known to provide adaptive endianness and to work with both big-endian and little-endian systems.<ref>{{cite AV media |url=http://open-zfs.org/wiki/Documentation/Read_Write_Lecture |title=FreeBSD Kernel Internals: An Intensive Code Walkthrough |author=Matt Ahrens |year=2016 |publisher=OpenZFS Documentation/Read Write Lecture |access-date=2016-03-30 |archive-date=2016-04-14 |archive-url=https://web.archive.org/web/20160414051047/http://open-zfs.org/wiki/Documentation/Read_Write_Lecture |url-status=live }}</ref>

=== Networking ===

Many [[IETF RFC]]s use the term ''network order'', meaning the order of transmission for bytes ''over the wire'' in [[network protocols]]. Among others, the historic {{IETF RFC|1700|link=no}} defines the network order for protocols in the [[Internet protocol suite]] to be big-endian.<ref>{{ cite IETF | title = Assigned Numbers | rfc = 1700 | std = 2 | sectionname = Data Notations | page = 3 | last1 = Reynolds | first1 = J. | author-link1 = Joyce K. Reynolds | last2 = Postel | first2 = J. | author-link2 = Jon Postel | date=October 1994 | publisher = [[IETF]] | access-date = 2012-03-02 }}</ref>

However, not all protocols use big-endian byte order as the network order. The [[Server Message Block]] (SMB) protocol uses little-endian byte order. In [[CANopen]], multi-byte parameters are always sent [[least significant byte]] first (little-endian). The same is true for [[Ethernet Powerlink]].<ref>Ethernet POWERLINK Standardisation Group (2012), ''EPSG Working Draft Proposal 301: Ethernet POWERLINK Communication Profile Specification Version 1.1.4'', chapter 6.1.1.</ref>

The [[Berkeley sockets]] [[API]] defines a set of functions to convert 16- and 32-bit integers to and from network byte order: the {{code|htons}} (host-to-network-short) and {{code|htonl}} (host-to-network-long) functions convert 16- and 32-bit values respectively from machine (''host'') to network order; the {{code|ntohs}} and {{code|ntohl}} functions convert from network to host order.<ref>{{cite book | title = The Open Group Base Specifications Issue 7 | author = IEEE and The Open Group | date = 2018 | volume = 2 | chapter = 3. System Interfaces | page = 1120 | url = https://pubs.opengroup.org/onlinepubs/9699919799/functions/htonl.html | access-date = 2021-04-09 | archive-date = 2021-04-18 | archive-url = https://web.archive.org/web/20210418041546/https://pubs.opengroup.org/onlinepubs/9699919799/functions/htonl.html | url-status = live }}</ref><ref>{{Cite web|title=htonl(3) - Linux man page|url=https://linux.die.net/man/3/htonl|access-date=2021-04-09|website=linux.die.net|archive-date=2021-04-18|archive-url=https://web.archive.org/web/20210418054331/https://linux.die.net/man/3/htonl|url-status=live}}</ref> These functions may be a [[no-op]] on a big-endian system.

While the high-level network protocols usually consider the byte (mostly meant as ''[[octet (computing)|octet]]'') as their atomic unit, the lowest layers of a [[network stack]] may deal with ordering of bits within a byte.