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

Groups > comp.lang.c > #150928

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

Show all headers | View raw

On 3/31/20 2:28 AM, wyniijj@gmail.com wrote:
> Richard Damon於 2020年3月31日星期二 UTC+8上午8時04分55秒寫道：
>> On 3/30/20 2:42 PM, wyniijj@gmail.com wrote:
>>> I'd like to read the value a.value in the following program as 0x78563412 in a 
>>> portable way, none of hton or ntoh is useful. How should I do? 
>>>
>>> #include <stdio.h>
>>> #include <arpa/inet.h>
>>>
>>> int main()
>>> {
>>>  union {
>>>    char str[4]; 
>>>    uint32_t value;
>>>  } a;
>>>
>>>  a.str[0]=0x12;
>>>  a.str[1]=0x34;
>>>  a.str[2]=0x56;
>>>  a.str[3]=0x78;
>>>
>>>  printf("host= %08x\n",a.value);
>>>  printf("hton= %08x\n",htonl(a.value));
>>>  printf("ntoh= %08x\n",ntohl(a.value));
>>>  return 0;
>>> }
>>>
>>> -------
>>> [me@localhost]$ gcc t6.c
>>> [me@localhost]$ ./a.out 
>>> host= 78563412
>>> hton= 12345678
>>> ntoh= 12345678
>>>
>>
>>
>> Network order is Big Endian, your problem statement defines decoding
>> little endian, so the network order functions won't work.
>>
>> In my mind the simplest is:
>>
>> a.ser[0] | (a.str[1] << 8) | (a.str[2] << 16) | (a.str[3] << 24)
>>
>> i.e., be explicit and access by bytes in the order you want.
>>
>> You could write some 'magic' routine that is the opposite of the network
>> order functions, which know if they can do the quick cheat because you
>> are on a little endian machine, but then if you want the code to be
>> 'portable' you need some magic to enable that short cut (some #define
>> that tells you its ok).
> 
> What is actually stored in str[4] is one utf8 character, unused bytes are 
> filled with zeros. I'd like to access it faster, as uint32_t.
> 

Are you, by any chance, trying to convert from UTF-8 to UTF-32 (aka UCS-4)?

An implementation of C is free to define the encoding used for both it's
source and execution charater sets. It is, in particular, allowed to
define an encoding which uses multiple bytes to represent an extended
character. Therefore, most of things that the C standard says about
characters are written in terms of multibyte character encodings.

On most systems where it makes sense to worry about UTF-8 encodings,
there's a pretty good chance that UTF-8 will be the encoding defined by
the implementation for the source or execution character sets; probably
both.

Character constants and string literals prefixed with "u8" produce
characters encoded in UTF-8, even if UTF-8 is not the encoding used by
the implementation for the execution character set.

The <uchar.h> header typedefs char32_t as a synonym for uint_least32_t,
which should be compatible uint32_t on any system which can support
uint32_t (such compatibility is not actually required by the standard).
If __STDC_UTF_32__ is pre#defined by the implementation, values of that
type are UTF-32 encoded.

You can create char32_t character constants and string literals
directly, by using a U prefix: U'b' is a char32_t character, and U"James
Kuyper" defines an unnamed array of type char32_t containing my name.
Such string literals may be used to initialize a char32_t array. In most
other contexts, a char32_t string literal gets implicitly converted into
a pointer to the first element of the unnamed array.

On any such system where UTF-8 is the encoding used for the execution
character set, and which pre#defined __STDC_UTF_32__, mbrtoc32() can be
used to covert from UTF-8 and UTF-32, and c32tomb() can be used to
perform the reverse conversion. These functions are declared in <uchar.h>.

The behaviors of mbrtoc32() and c32tomb() are locale-dependent. The
creation of char32_t characters from char32_t character constants and
string literals is defined in terms of calls to mbrtoc32() with an
implementation-defined locale.

Back to comp.lang.c | Previous | Next — Previous 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