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

Groups > comp.lang.c > #150913 > unrolled thread

Protable way of reading str[4] as uint32_t

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 2  [1] 2  Next page →

#150913 — Protable way of reading str[4] as uint32_t

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

[toc] | [next] | [standalone]

#150915

wyniijj@gmail.com writes:

> 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?

You need to say how portable you need this to be.  There are some really
odd machines still out there.

> #include <stdio.h>
> #include <arpa/inet.h>

The fact that print "host=" and are including this header suggests that
maybe you need to use htonl and ntohl.  In what way do they appear not
to work?

> int main()
> {
>  union {
>    char str[4]; 
>    uint32_t value;
>  } a;

This is one way to do it, though unsigned char is safer.  What's not
right about it?

>  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;
> }

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150917

On Mon, 2020-03-30, Ben Bacarisse wrote:
> wyniijj@gmail.com writes:
>
>> 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?
>
> You need to say how portable you need this to be.  There are some really
> odd machines still out there.

>> #include <stdio.h>
>> #include <arpa/inet.h>
>
> The fact that print "host=" and are including this header suggests that
> maybe you need to use htonl and ntohl.  In what way do they appear not
> to work?

There's something weird going on; if these are IPv4 addresses, why do
they appear in little-endian order in the code?

Another thing I note is that if you use POSIX getaddrinfo(),
inet_ntop() and friends -- available for two decades by now -- you
don't need to micro-manage the addresses like this, and you're not
tied to an obsolete IP version.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150918

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).

[toc] | [prev] | [next] | [standalone]

#150919

Richard Damon <Richard@Damon-Family.org> writes:
> 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;
[...]
> 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.

And definitely use unsigned char rather than char, and test with values
exceeding 0x7f.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#150921

Keith Thompson於 2020年3月31日星期二 UTC+8上午10時04分43秒寫道：
> Richard Damon <Richard@Damon-Family.org> writes:
> > 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;
> [...]
> > 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.
> 
> And definitely use unsigned char rather than char, and test with values
> exceeding 0x7f.
> 
> [...]
> 
> -- 
> Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
> Working, but not speaking, for Philips Healthcare
> void Void(void) { Void(); } /* The recursive call of the void */

Yes, the type str should be uint8_t. Should I write it

 union {
   uint8_t str[4];
   uint32_t value;
 } a;

 a.str[0]='\x12';
 a.str[1]='\x34';
 a.str[2]='\x56';
 a.str[3]='\x78';

uint32_t b=(uint32_t)a.str[0] | ((uint32_t)a.str[1]<<8) | ((uint32_t)a.str[2] << 16) | ((uint32_t)a.str[3] << 24);

 a.value is useless.

[toc] | [prev] | [next] | [standalone]

#150930

wyniijj@gmail.com writes:
> Keith Thompson於 2020年3月31日星期二 UTC+8上午10時04分43秒寫道：
[...]
>> And definitely use unsigned char rather than char, and test with values
>> exceeding 0x7f.
[...]
> Yes, the type str should be uint8_t. Should I write it
>
>  union {
>    uint8_t str[4];
>    uint32_t value;
>  } a;
>
>  a.str[0]='\x12';
>  a.str[1]='\x34';
>  a.str[2]='\x56';
>  a.str[3]='\x78';
>
> uint32_t b=(uint32_t)a.str[0] | ((uint32_t)a.str[1]<<8) | ((uint32_t)a.str[2] << 16) | ((uint32_t)a.str[3] << 24);
>
>  a.value is useless.

No.

You've said elsewhere that the str array contains a UTF-8
encoding of a character (something you didn't initially mention).
The code above would be a way of interpreting the byte sequence
{ 0x12, 0x34, 0x56, 0x78 } as the integer value 0x12345678 --
but the way UTF-8 characters are encoded is very different from that.

https://en.wikipedia.org/wiki/UTF-8

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#150934

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> wyniijj@gmail.com writes:
>> Keith Thompson於 2020年3月31日星期二 UTC+8上午10時04分43秒寫道：
> [...]
>>> And definitely use unsigned char rather than char, and test with values
>>> exceeding 0x7f.
> [...]
>> Yes, the type str should be uint8_t. Should I write it
>>
>>  union {
>>    uint8_t str[4];
>>    uint32_t value;
>>  } a;
>>
>>  a.str[0]='\x12';
>>  a.str[1]='\x34';
>>  a.str[2]='\x56';
>>  a.str[3]='\x78';
>>
>> uint32_t b=(uint32_t)a.str[0] | ((uint32_t)a.str[1]<<8) | ((uint32_t)a.str[2] << 16) | ((uint32_t)a.str[3] << 24);
>>
>>  a.value is useless.
>
> No.
>
> You've said elsewhere that the str array contains a UTF-8
> encoding of a character (something you didn't initially mention).
> The code above would be a way of interpreting the byte sequence
> { 0x12, 0x34, 0x56, 0x78 } as the integer value 0x12345678 --
> but the way UTF-8 characters are encoded is very different from that.

My mistake, I got the byte order wrong.  Your code would interpret the
byte sequence { 0x12, 0x34, 0x56, 0x78 } as the integer value 0x78563412 .
(That's still not what you want if you're trying to decode UTF-8.)

> https://en.wikipedia.org/wiki/UTF-8

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#150942

Keith Thompson於 2020年4月1日星期三 UTC+8上午3時19分29秒寫道：
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > wyniijj@gmail.com writes:
> >> Keith Thompson於 2020年3月31日星期二 UTC+8上午10時04分43秒寫道：
> > [...]
> >>> And definitely use unsigned char rather than char, and test with values
> >>> exceeding 0x7f.
> > [...]
> >> Yes, the type str should be uint8_t. Should I write it
> >>
> >>  union {
> >>    uint8_t str[4];
> >>    uint32_t value;
> >>  } a;
> >>
> >>  a.str[0]='\x12';
> >>  a.str[1]='\x34';
> >>  a.str[2]='\x56';
> >>  a.str[3]='\x78';
> >>
> >> uint32_t b=(uint32_t)a.str[0] | ((uint32_t)a.str[1]<<8) | ((uint32_t)a.str[2] << 16) | ((uint32_t)a.str[3] << 24);
> >>
> >>  a.value is useless.
> >
> > No.
> >
> > You've said elsewhere that the str array contains a UTF-8
> > encoding of a character (something you didn't initially mention).
> > The code above would be a way of interpreting the byte sequence
> > { 0x12, 0x34, 0x56, 0x78 } as the integer value 0x12345678 --
> > but the way UTF-8 characters are encoded is very different from that.
> 
> My mistake, I got the byte order wrong.  Your code would interpret the
> byte sequence { 0x12, 0x34, 0x56, 0x78 } as the integer value 0x78563412 .
> (That's still not what you want if you're trying to decode UTF-8.)
> 
> > https://en.wikipedia.org/wiki/UTF-8
> 
> -- 
> Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
> Working, but not speaking, for Philips Healthcare
> void Void(void) { Void(); } /* The recursive call of the void */

I understand what you are talking about.

[toc] | [prev] | [next] | [standalone]

#150920

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.

[toc] | [prev] | [next] | [standalone]

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

On Mon, 30 Mar 2020 23:28:33 -0700 (PDT)
wyniijj@gmail.com wrote:
> Richard Damon
> > 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;
> > > }

[...]

> 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.

How was the UTF-8 character stored there ? Can you show us some example code
which does the storing ? What do you want to do with it when accessing it
as  uint32_t ? The code you have in your opening post is one way to do the
accessing but whether it's useful for what further processing you need to
do , I don't know.

I note also that to have  uint32_t  you need
#include <stdint.h>

-- 
vlaho.ninja/prog

[toc] | [prev] | [next] | [standalone]

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

Spiros Bousbouras於 2020年3月31日星期二 UTC+8下午7時29分19秒寫道：
> On Mon, 30 Mar 2020 23:28:33 -0700 (PDT)
> wyniijj@gmail.com wrote:
> > Richard Damon
> > > 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;
> > > > }
> 
> [...]
> 
> > 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.
> 
> How was the UTF-8 character stored there ? Can you show us some example code
> which does the storing ? What do you want to do with it when accessing it
> as  uint32_t ? The code you have in your opening post is one way to do the
> accessing but whether it's useful for what further processing you need to
> do , I don't know.
> 
No real code yet. I'm designing a struct like

struct SNode {
  struct SNode *m_parent;
  int m_xtype;      // the real type of m_xptr
  void *m_xptr;
};

where m_xptr might store an utf8 character if m_xtype says so.
If so, this 'uint32_t' value may be passed among many functions.
some function might check its uint32_t argument being less than 128(or more) and
can use it as an array index. Therefore, I need a consistent way that convert
uint8_t[4] to uint32_t and latin1 characters is required to convert to equal value.

> I note also that to have  uint32_t  you need
> #include <stdint.h>
> 
> -- 
> vlaho.ninja/prog

[toc] | [prev] | [next] | [standalone]

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

On Tue, 31 Mar 2020 09:59:03 -0700 (PDT)
wyniijj@gmail.com wrote:
> Spiros Bousbouras於 2020年3月31日星期二 UTC+8下午7時29分19秒寫道：
> > On Mon, 30 Mar 2020 23:28:33 -0700 (PDT)
> > wyniijj@gmail.com wrote:
> > > 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.
> > 
> > How was the UTF-8 character stored there ? Can you show us some example code
> > which does the storing ? What do you want to do with it when accessing it
> > as  uint32_t ? The code you have in your opening post is one way to do the
> > accessing but whether it's useful for what further processing you need to
> > do , I don't know.

> No real code yet.

Still , you must have some idea how the UTF-8 (representation of a)
character will be stored in the array. For example the UTF-8 sequence
for  A  has 1 element with the value 65. What will the contents of
uint8_t[4]  be for this ? The UTF-8 sequence for  於  has 3 elements which
are  230 150 188 .What will the contents of uint8_t[4]  be for this ?

> I'm designing a struct like
> 
> struct SNode {
>   struct SNode *m_parent;
>   int m_xtype;      // the real type of m_xptr
>   void *m_xptr;
> };
> 
> where m_xptr might store an utf8 character if m_xtype says so.
> If so, this 'uint32_t' value may be passed among many functions.

But you still need to specify what correspondence you want between the UTF-8
representation and the  uint32_t  value. Based on what you say below , I'm
guessing that you want to get the unicode codepoint from the UTF-8 represen-
tation but I'm not sure. You also need to specify whether the  uint8_t[4]
array will be guaranteed to have a valid UTF-8 sequence or whether you want
your code to also check for that.

> some function might check its uint32_t argument being less than 128(or more) and
> can use it as an array index. Therefore, I need a consistent way that convert
> uint8_t[4] to uint32_t and latin1 characters is required to convert to equal value.
> 
> > I note also that to have  uint32_t  you need
> > #include <stdint.h>

-- 
vlaho.ninja/prog

[toc] | [prev] | [next] | [standalone]

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

Spiros Bousbouras <spibou@gmail.com> writes:

> On Mon, 30 Mar 2020 23:28:33 -0700 (PDT)
> wyniijj@gmail.com wrote:
>
>> Richard Damon
>>
>>> 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;
>>>> }

[...]

> 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().

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

On 4/3/20 1: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.

Which doesn't make it any less real, which is all that's relevant.

[toc] | [prev] | [next] | [standalone]

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

In article <r66gg1$v0i$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 4/3/20 1: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.
>
>Which doesn't make it any less real, which is all that's relevant.
>

In the context of this particular newsgroup, saying something is not part
of standard C *IS* *EXACTLY* *THE* *SAME* *THING* as saying that it does
not exist.

You've been around long enough now to know that.

BTW, the problem is that I might have a "inet.h" file on my system that
does something entirely different from whatever "inet.h" file you have on
your system - and still be entirely compliant with the C standards.  In
fact, the "inet.h" file on my system seems to have something to do with
fishing - specifically with catching salmon.

Or maybe it has to do with playing volleyball.  I'll have to check.

-- 
So to cure the problem of arrogant incompetent rich people we should turn
the government over to an arrogant incompetent trust fund billionaire
who knows nothing about government and who has never held a job in his
entire spoiled life?

[toc] | [prev] | [next] | [standalone]

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

On Fri, 3 Apr 2020 01:10:25 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 4/3/20 1:02 AM, Spiros Bousbouras wrote:
> > <arpa/inet.h>  is not part of standard C.
> 
> Which doesn't make it any less real,

That's a philosophical matter. In my view only the C Standard is real and
the rest of the universe is an illusion.

> which is all that's relevant.

[toc] | [prev] | [next] | [standalone]

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

In article <Wj9rrpquwOGUnkN2Ml@bongo-ra.co>,
Spiros Bousbouras  <spibou@gmail.com> wrote:
>On Fri, 3 Apr 2020 01:10:25 -0400
>James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/3/20 1:02 AM, Spiros Bousbouras wrote:
>> > <arpa/inet.h>  is not part of standard C.
>> 
>> Which doesn't make it any less real,
>
>That's a philosophical matter. In my view only the C Standard is real and
>the rest of the universe is an illusion.

That's certainly the dogmatically correct view in this newsgroup.
You are on safe theological ground.

-- 
People who say they'll vote for someone else because Obama couldn't fix
*all* of Bush's messes are like people complaining that he couldn't cure
cancer, so they'll go and vote for (more) cancer.

[toc] | [prev] | [next] | [standalone]

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

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, ...

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web