# Steam IO endianess for Read and Write attributes
**URL:** https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270
**Category:** General
**Tags:** linux, ada, gnat
**Created:** [March 18, 2026, 2:44pm UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270 "2026-03-18T14:44:59Z")
**Posts on this page:** 6
**Page:** 2
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [March 21, 2026, 9:57am UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270/21 "2026-03-21T09:57:11Z")
> [@Nordic\_Dogsledding](#):
>
> Is there really a _universal concept of type_? I strongly doubt this claim.
Sure.
_Type is a set of values and operations defined on it._
Ada uses this definition too:
> **type**
>
> defining characteristic of each object and expression of the language, with an associated set of values, and a set of primitive operations that implement the fundamental aspects of its semantics
It is only Ada subtype where Ada suddenly forgets that and invents _not-a-type which is yet a type and a constraint_. 😀 This is more or less Ada 83 heritage when the language had no related types, that is types the language routinely implicitly converts. So in Ada 83 a subtype is “same” type for the sake of purity, though semantically it is evidently not. Ada 95 changed that by adding tagged types which are implicitly converted (per introducing overloaded primitive operations.) But the wording regarding subtypes remained same.
In a discussion regarding software or language design this word play is irrelevant. Ada subtype is just a type.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [March 21, 2026, 8:00pm UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270/22 "2026-03-21T20:00:52Z")
> [@dmitry-kazakov](#):
>
> It is only Ada subtype where Ada suddenly forgets that and invents _not-a-type which is yet a type and a constraint_. 😀 This is more or less Ada 83 heritage when the language had no related types, that is types the language routinely implicitly converts. So in Ada 83 a subtype is “same” type for the sake of purity, though semantically it is evidently not.
Ada was designed that way so that you could have freedom within constraints (ie subsets) without having to have full-on separate types: just as mathematics has `Integer`, `Natural`, & `Counting` numbers to section into useful properties. (e.g. any `Natural` multiplied by a `Natural` is `Natural`; this sort of property doesn’t hold with certain sets like, say, `Negative`.) — Also, it would be a pain in the ass to require full-on type-conversions for these constrained subsets.
> [@dmitry-kazakov](#):
>
> In a discussion regarding software or language design this word play is irrelevant. Ada subtype is just a type.
This is arguable.
Is _“All values of type `X` that conform to a given constraint”_ a new type, or is it simply working with a subset of the set-of-values of a type. You are arguing that it **must** be a separate type, but this is not necessarily so.
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [March 21, 2026, 8:39pm UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270/23 "2026-03-21T20:39:20Z")
> [@OneWingedShark](#):
>
> Ada was designed that way so that you could have freedom within constraints (ie subsets) without having to have full-on separate types
Yes, a subtype is implicitly converted forth and back as necessary.
> [@OneWingedShark](#):
>
> Also, it would be a pain in the ass to require full-on type-conversions for these constrained subsets.
It is not because Ada subtype representation is same and most operations are defined in terms of the base type (S’Base) anyway. A conversion is at most a constraint check. Moreover it is exactly so when you clone a type rather than subtype it:
` type X is new Integer [range ...];` – Does this incur “pain?”
It does not mean that extending this model would not be useful. One could allow representation change in order to have things Ada cannot now:
- Enumeration type extension
- String encoding support
- Class-wide objects of small types and arrays
- nD subarrays, columns, diagonals, planes …
- Placing existing types up into the hierarchy of types (ad-hoc supertypes), e.g. you could create a common ancestor _Field_ for _Float_ and _Complex_ and write subprograms working on both
- Discriminant expressions:
```ada
type Buffer (L : Natural) is record
Data : Stream_Element_Array (0..L - 1);
end record;
```
etc. Yes, it would require full conversion, but one would have it manually anyway.
> [@OneWingedShark](#):
>
> You are arguing that it **must** be a separate type, but this is not necessarily so.
Not I, the type definition does.
---
### Author:  [@HawkerFrake](https://forum.ada-lang.io/u/HawkerFrake)
#### Post date: [March 28, 2026, 12:41pm UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270/24 "2026-03-28T12:41:50Z")
This changes the order for storage on the machine the program is running on. I would like to change the byte order of the serialization operation. Personally, I treat little endian as a machine detail and big endian as the natural representation. Big endian is how I prefer to serialize data for storage and transmission.
When I wrote my Modbus software I dealt with devices who’s developers think memcpy(buf, &float, sizeof (float)) is how to serialize. I use portable bit shifting operations.
---
### Author:  [@kevlar700](https://forum.ada-lang.io/u/kevlar700)
#### Post date: [March 28, 2026, 6:20pm UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270/25 "2026-03-28T18:20:19Z")
> [@HawkerFrake](#):
>
> This changes the order for storage on the machine the program is running on.
Scalar\_Storage\_Order is applicable to arrays and records etc. where you use it?
“Existing code for a big-endian system can thus be ported to a little-endian system without any fuss, and without any change of data representation, just by adding appropriate attribute definitions on relevant record type declarations”
Needs testing but no code that could have mistakes in it.
For example I believe you could have two procedures that unchecked\_convert to arrays with different scalar storage orders.
---
### Author:  [@dmitry-kazakov](https://forum.ada-lang.io/u/dmitry-kazakov)
#### Post date: [March 28, 2026, 6:56pm UTC](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270/26 "2026-03-28T18:56:10Z")
> [@kevlar700](#):
>
> > [@HawkerFrake](#):
> >
> > This changes the order for storage on the machine the program is running on.
>
> Scalar\_Storage\_Order is applicable to arrays and records etc. where you use it?
Representation clauses in Ada are meant for interfacing hardware or software on the **same** machine.
[Previous page](https://forum.ada-lang.io/t/steam-io-endianess-for-read-and-write-attributes/4270.md?page=1)