[Bug network/14988] New: Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[Bug network/14988] New: Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[majic.one at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14988

             Bug #: 14988
           Summary: Add ntohd(), ntohf(), ntohll(), htond(), htonf(),
                    htonll() for sending/receiving IEEE 754-formatted
                    floats/doubles/long-longs
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: network
        AssignedTo: unassigned@sourceware.org
        ReportedBy: majic.one@gmail.com
    Classification: Unclassified


I am currently working on a socket library for the Lua scripting language and I
noticed while making bindings for htons(), htonl(), ntohs(), and ntohl() that
while Windows and Linux both support these functions identically, Windows
contains these additional ones for working with floats and doubles:

ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll()

You see, Lua represents numbers (with its default configuration) as doubles,
and it would be *lovely* if I could transmit these values encoded according to
the IEEE-754 standard for single and double precision?  (not sure if I'm
phrasing this right, please forgive)

I'm not a math person. :(  I don't exactly understand how NaN is represented,
every case where Inf is returned, and how denormalized numbers fit into all of
this... I barely understand the significand.  I just wish I could transmit
doubles safely across the internet without inefficiently "stringifying" them or
resorting to encapsulating JSON/msgpack/protobuf/BSON...  If it were at all
possible for the glibc crowd to feel sympathy for this, I would be greatly
appreciative.  I believe that the accessibility of these functions across both
glibc-using systems and Windows would help them to become standard like the
already available short and long variants. :x

I was more than a little surprised that it wasn't already part of some
relatively current POSIX addition (perhaps these don't get released with the
same frequency of Twilight film installments?).

Beej's Guide to Network Programming has a relevant portion on doing the ntohd()
and htond() portion (I think?):

http://beej.us/guide/bgnet/examples/ieee754.c

Thank you for taking the time to read this, have a nice day all!

PS: I was told Windows 8 uses IEEE-754 floats for the network format of those
number types, someone might need to double-check though..

PPS: I hope I did not upset anyone by calling for feature parody with Windows
or otherwise having the "gall" to believe standards could be coaxed into being
by using glibc as a "precedent setter"..  I just happen to believe that
IEEE-754 format floats are fairly common these days (especially on ARM?) and
the network portion of glibc could benefit from recognizing a standard like
this among the ntoh/hton-related stuff.

PPPS: I LOVE MATH PEOPLE -- Euler bless! :o)

Sources:
[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/jj710197(v=vs.85).aspx

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/14988] Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[majic.one at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14988

Majic <majic.one at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://msdn.microsoft.com/e
                   |                            |n-us/library/windows/deskto
                   |                            |p/jj710197(v=vs.85).aspx
   Target Milestone|---                         |2.19

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/14988] Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[fweimer at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14988

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> 2013-01-14 14:50:48 UTC ---
Are these functions purely Microsoft-isms, or are they available on actual
implementations of the BSD sockets API?

(I'm asking because we're not goint to add CreateFile etc., either. 8-)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/14988] Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[majic.one at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14988

--- Comment #2 from Majic <majic.one at gmail dot com> 2013-03-07 04:52:25 UTC ---
(In reply to comment #1)
> Are these functions purely Microsoft-isms, or are they available on actual
> implementations of the BSD sockets API?
> 
> (I'm asking because we're not goint to add CreateFile etc., either. 8-)

As far as I am aware, these are only found on Windows (8) atm. :>  I have not
seen them anywhere else.  I would also not be interested in a CreateFile(), but
I do feel like Microsoft has met a need here.  Using snprintf() with its %a
conversion specifier to go from a double to a hex string and then later
converting it back is unnecessarily costly..  I hope this is not too
presumptuous to say, but glibc (being a major player) could add these and
encourage their acceptance into POSIX. Microsoft didn't exactly do anything
strange extending beyond htons() with these.  I know the focus of glibc isn't
to set standards but to adhere to them.  I just feel like in 2013 there should
be at least a glibc-standard way of sending network floats (and receiving
them).

Again, I hope I'm not expecting too much :>

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/14988] Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[allan at archlinux dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14988

Allan McRae <allan at archlinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allan at archlinux dot org
   Target Milestone|2.19                        |---

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/14988] Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14988

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.