[fpc-pascal] Writing floating points to steams

Sven Barth pascaldragon at googlemail.com
Wed Jan 13 11:20:34 CET 2016

Am 13.01.2016 10:40 schrieb "Mark Morgan Lloyd" <
markMLl.fpc-pascal at telemetry.co.uk>:
> Torsten Bonde Christiansen wrote:
>> On 2016-01-13 10:06, Mark Morgan Lloyd wrote:
>>> Serguei TARASSOV wrote:
>>>> On 13/01/2016 08:47, fpc-pascal-request at lists.freepascal.org wrote:
>>>>> On 2016-01-12 10:45, Torsten Bonde Christiansen wrote:
>>>>>> Since TStream doesn't have any native WriteFloat/Double and the
>>>>>> some conversion is needed - but what is a good strategy for this?
>>>> Depends on size constraints.
>>>> In the simple case you should convert float to locale-independent
string value (no spaces, no commas separators) then write it.
>>>> If the size does matter, you may convert float to corresponding byte
array then write it.
>>> Can I ask a naive question here please: does a binary stream store
endianness anywhere? In other words, is there any indication that something
running on ARM is about to get into trouble by reading something written by
(big-endian) MIPS?
>> Not that I'm aware of - i would think of it as a stream of bytes.
Endianess is defined by the CPU not by the file.
> Thanks, I assumed that was the case but thought it worth checking.
> I suppose that one could stream variants, i.e. the enumeration saying
what one was followed by a value.

That's not the task of TStream however. For that you should use a custom
class that uses TStream under the hood.

>>> Should writing binary floating point to a stream note that it's IEEE
format, just in case anybody ever tries to process it on a platform that
supports alternatives?
>> It would be great if storing floating point could be in IEEE, to have a
standard as reference.
> I'm not at all sure about this, but I think I've seen something that
suggested that byte ordering in external representations was covered by the

I've checked recently due to big endian problems in the Castle game engine
and found out that endianess isn't really covered for floating points...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20160113/b859156e/attachment.html>

More information about the fpc-pascal mailing list