Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #150988

Re: Portable way of reading str[4] as uint32_t

Show all headers | View raw

On 4/3/2020 11:09 AM, Richard Damon wrote:
> On 4/3/20 10:51 AM, Malcolm McLean wrote:
>> On Friday, 3 April 2020 15:41:20 UTC+1, BGB  wrote:
>>> On 4/3/2020 12:02 AM, Spiros Bousbouras wrote:
>>>> On Thu, 02 Apr 2020 19:09:07 -0700
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>> Spiros Bousbouras <spibou@gmail.com> writes:
>>>>>> I note also that to have  uint32_t  you need
>>>>>> #include <stdint.h>
>>>>>
>>>>> Actually not, because <arpa/inet.h> was already #include'd.
>>>>> See for example the man page for htonl().
>>>>
>>>> <arpa/inet.h>  is not part of standard C.
>>>>
>>>
>>> Yes, and <winsock.h> is better anyways... (satire)
>>>
>>>
>>> Thought: it is kind of an annoyance sometimes that there is no standard
>>> way to efficiently do things like endian swapping and loading/storing
>>> misaligned values (with a particular size and endianess). This stuff
>>> generally ends up as a mess of boilerplate being copied from one project
>>> to another...
>>>
>>>
>>> Then again, this is about like asking for "__packed" or
>>> "__attribute__((packed))" to be promoted (support for packed structs not
>>> exactly being free on many targets, ...).
>>>
>>> But, as-is, one has to do things like FAT drivers and similar with
>>> struct's filled with byte arrays, and then using wrapper
>>> functions/macros to get/set the values for the various fields, ...
>>>
>> More broadly, C isn't good at serialisation and deserialisation.
>> It's a fundamental feature that needs to be built into the language,
>> but it doesn't play well with different sizes of basic type, even
>> different numbers of bits in a byte, floating point values, undefined
>> endianness, padding bytes, and pointers.
>>
> 
> Yes, the C language as currently defined admits too broad a class of
> machines to attempt to define a portable serialization format (other
> than as character strings). The issue is how does a machine with a 9 bit
> byte transfer at all portably and efficiently with a machine with an 8
> bit byte.
> 

Can mostly be ignored as hardly anything anymore uses a byte size other 
than 8 bits.


> 
> Even endianness gets tough to define.  While there are only two main
> options for storing a two byte object (ignoring the real pathological
> cases), either most or least significant byte first, when we get to four
> byte objects there are 24 reasonably possible combinations, and that can
> be reduced to 4 likely orders, all of which HAVE been used. The two
> 'mixed-endian' where the order of the bytes in the 16 bit word are in
> the opposite order of the ordering of the two 16 bits words in the 32
> bit word.
> 

Or, more than 2 cases for endianess...


It would mostly just be nice if I could have something like:
   uint32_t getuint32le(void *ptr);
   void setuint32le(void *ptr, uint32_t value);

Rather than needing to supply a header with a whole bunch of compiler 
and target specific #ifdef's in order to get decent performance at these 
sorts of tasks.


Nevermind, eg, if FAT has the extra fun of some amount of its fields 
being broken up into multiple parts and needing to be glued back 
together (as a result of its FAT12 -> FAT16 -> FAT32 evolution).

More so, there is some extra hackery and bit-twiddly if one wants to 
support compatibility with a few FreeDOS extensions, or in my case there 
is also a system for crudely gluing some Unix-like metadata on top of 
FAT (while trying not to break compatibility with Windows); ...

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Protable way of reading str[4] as uint32_t wyniijj@gmail.com - 2020-03-30 11:42 -0700
  Re: Protable way of reading str[4] as uint32_t Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-30 20:14 +0100
    Re: Protable way of reading str[4] as uint32_t Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-30 20:11 +0000
  Re: Protable way of reading str[4] as uint32_t Richard Damon <Richard@Damon-Family.org> - 2020-03-30 20:04 -0400
    Re: Protable way of reading str[4] as uint32_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-30 19:04 -0700
      Re: Protable way of reading str[4] as uint32_t wyniijj@gmail.com - 2020-03-30 23:30 -0700
        Re: Protable way of reading str[4] as uint32_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-31 10:59 -0700
          Re: Protable way of reading str[4] as uint32_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-31 12:19 -0700
            Re: Protable way of reading str[4] as uint32_t wyniijj@gmail.com - 2020-04-01 06:37 -0700
    Re: Protable way of reading str[4] as uint32_t wyniijj@gmail.com - 2020-03-30 23:28 -0700
      Re: Portable way of reading str[4] as uint32_t Spiros Bousbouras <spibou@gmail.com> - 2020-03-31 11:29 +0000
        Re: Portable way of reading str[4] as uint32_t wyniijj@gmail.com - 2020-03-31 09:59 -0700
          Re: Portable way of reading str[4] as uint32_t Spiros Bousbouras <spibou@gmail.com> - 2020-03-31 18:03 +0000
        Re: Portable way of reading str[4] as uint32_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:09 -0700
          Re: Portable way of reading str[4] as uint32_t Spiros Bousbouras <spibou@gmail.com> - 2020-04-03 05:02 +0000
            Re: Portable way of reading str[4] as uint32_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 01:10 -0400
              Re: Portable way of reading str[4] as uint32_t gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-03 08:18 +0000
              Re: Portable way of reading str[4] as uint32_t Spiros Bousbouras <spibou@gmail.com> - 2020-04-03 09:48 +0000
                Re: Portable way of reading str[4] as uint32_t gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-03 11:07 +0000
            Re: Portable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-04-03 09:41 -0500
              Re: Portable way of reading str[4] as uint32_t Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 07:51 -0700
                Re: Portable way of reading str[4] as uint32_t Richard Damon <Richard@Damon-Family.org> - 2020-04-03 12:09 -0400
                Re: Portable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-04-03 13:19 -0500
                Re: Portable way of reading str[4] as uint32_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 14:52 -0400
                Re: Portable way of reading str[4] as uint32_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 12:10 -0700
                Re: Portable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-04-03 15:17 -0500
                Re: Portable way of reading str[4] as uint32_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:39 -0400
                Re: Portable way of reading str[4] as uint32_t Spiros Bousbouras <spibou@gmail.com> - 2020-04-03 21:28 +0000
            Re: Portable way of reading str[4] as uint32_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 19:28 -0700
      Re: Protable way of reading str[4] as uint32_t Richard Damon <Richard@Damon-Family.org> - 2020-03-31 08:05 -0400
        Re: Protable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-03-31 09:12 -0500
          Re: Protable way of reading str[4] as uint32_t Philipp Klaus Krause <pkk@spth.de> - 2020-03-31 17:27 +0200
            Re: Protable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-03-31 18:26 -0500
              Re: Protable way of reading str[4] as uint32_t Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-01 06:03 +0000
                Re: Protable way of reading str[4] as uint32_t Richard Damon <Richard@Damon-Family.org> - 2020-04-01 08:17 -0400
                Re: Protable way of reading str[4] as uint32_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-01 09:57 -0400
                Re: Protable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-04-01 09:47 -0500
                Re: Protable way of reading str[4] as uint32_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-01 11:48 -0400
                Re: Protable way of reading str[4] as uint32_t BGB <cr88192@gmail.com> - 2020-04-01 12:37 -0500
      Re: Protable way of reading str[4] as uint32_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-31 12:56 -0400

csiph-web