From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26600 invoked by alias); 30 Dec 2012 06:20:08 -0000 Received: (qmail 26378 invoked by uid 48); 30 Dec 2012 06:19:41 -0000 From: "majic.one at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug network/14988] New: Add ntohd(), ntohf(), ntohll(), htond(), htonf(), htonll() for sending/receiving IEEE 754-formatted floats/doubles/long-longs Date: Sun, 30 Dec 2012 06:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: majic.one at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00298.txt.bz2 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.