I am a beginner with qnx.
My question is:
1.what is uint16_t?
2.Is it a struct? if it’s a struct what is its content?
3.where is its define?
4.Can I use uint8_t,uint16_t,uint32_t,uint64_t as same as
“unsigned char”,“unsigned short”,“unsigned long” .
Thanks for any help
Zhang Hongzhi
“zhz_zhang” <zhz_zhang@263.net> wrote in message
news:aa8aqs$ij$1@inn.qnx.com…
I am a beginner with qnx.
My question is:
1.what is uint16_t?
2.Is it a struct? if it’s a struct what is its content?
3.where is its define?
4.Can I use uint8_t,uint16_t,uint32_t,uint64_t as same as
“unsigned char”,“unsigned short”,“unsigned long” .
It’s a typedef that defines a unsigned 16 bit variable.
Problem with unsigned short is it can have different size
depending on the CPU type/mode. Using uint16_t will ensure
size of the variable is the same on all platforms.
Thanks for any help
Zhang Hongzhi
Mario Charest <goto@nothingness.com> wrote:
Problem with unsigned short is it can have different size
depending on the CPU type/mode. Using uint16_t will ensure
size of the variable is the same on all platforms.
More accurately, on all platforms that define uint16_t… 
–
Wojtek Lerch QNX Software Systems Ltd.
Zhang Hongzhi wrote:
1.what is uint16_t?
2.Is it a struct? if it’s a struct what is its content?
3.where is its define?
4.Can I use uint8_t,uint16_t,uint32_t,uint64_t as same as
“unsigned char”,“unsigned short”,“unsigned long” .
The latest C standard (C99) defines these integers in stdint.h (if they
exist on a particular implementation). Their purpose is to improve
portability among different processors. As an example, on QNX for a x86
CPU, you have:
typedef unsigned short uint16_t;
Also take a look at inttypes.h if you want to print these integers. Here
is a code snippet to illustrate their use:
#include <stdint.h> /* to obtain unit32_t /
#include <inttypes.h> / to obtain PRIu32 */
…
uint32_t quadlet = 0x12345678;
printf(“Quadlet = %“PRIu32”\n”);
Note that PRIu32 is a macro that expands to a character string with the
proper format for a 32-bit unsigned integer.
For instance, on one CPU we might have:
typedef unsigned int uint32_t;
#define PRIu32 “u”
while on another CPU, we could have:
typedef long unsigned int uint32_t;
#define PRIu32 “lu”
This is why your code has to use uint32_t and PRIu32 if you want to be
sure your quadlet has exactly 32 bits.
–bl
“Bernard Leclerc” <whittom-leclerc@sympatico.ca> wrote in message
news:aaag7d$hdq$1@inn.qnx.com…
Also take a look at inttypes.h if you want to print these integers. Here
is a code snippet to illustrate their use:#include <stdint.h> /* to obtain unit32_t /
#include <inttypes.h> / to obtain PRIu32 */
…
uint32_t quadlet = 0x12345678;
printf(“Quadlet = %“PRIu32”\n”);Note that PRIu32 is a macro that expands to a character string with the
proper format for a 32-bit unsigned integer.Boy I could have used this knowledge a few months ago. I always prefer
using the “standard” way than creating my own. I didn’t know so I created
my own. My issue was a printf string for 64 bit ints.
Is uint8_t,uint16_t ,uint32_t, uint64_t are thread-safety?
I think that the system 8bit-char as one work unit.
So if I use uint8_t to define variable as global data ,
without mutexs in Multi-threads ,program can still correctly
read from or write to the variable.
That is to say,without mutex,threads can correctly read or write char
variable.
But to the uint16_t ,uint32_t, uint64_t variable,
I think that
without mutex If I use uint16_t ,uint32_t or uint64_t to define
some variable as global data in Multi-threads or Multi-process,
suppose that one thread is reading a uint32_t variable,but at
the same time ,another thread is writing the same variable,something
would be happened. Maybe the reading thread read wrong data of uint32_t
variable because the writing thread is changing the variable.
So In the environment ,if I want to use uint16_t ,uint32_t
or uint64_t safety ,I must use mutexs.
I don’t know whether what I think above is right?
It is really going to depend on your CPU architecture and compiler for
any operation on a single variable to be atomic. Generally you should
use the atomic*() API for manipulating variables without mutexes.
chris
zhz_zhang <zhz_zhang@263.net> wrote:
Is uint8_t,uint16_t ,uint32_t, uint64_t are thread-safety?
I think that the system 8bit-char as one work unit.
So if I use uint8_t to define variable as global data ,
without mutexs in Multi-threads ,program can still correctly
read from or write to the variable.
That is to say,without mutex,threads can correctly read or write char
variable.But to the uint16_t ,uint32_t, uint64_t variable,
I think that
without mutex If I use uint16_t ,uint32_t or uint64_t to define
some variable as global data in Multi-threads or Multi-process,
suppose that one thread is reading a uint32_t variable,but at
the same time ,another thread is writing the same variable,something
would be happened. Maybe the reading thread read wrong data of uint32_t
variable because the writing thread is changing the variable.
So In the environment ,if I want to use uint16_t ,uint32_t
or uint64_t safety ,I must use mutexs.I don’t know whether what I think above is right?
\
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
I have seen the atomic* in the qnx lib,but the variable must be volatile
style.
such as
void atomic_set( volatile unsigned * loc,
unsigned bits );
what is volatile,it seems to be associated with the compiler,now I still
cannot understand what the meaning of “volatile”.
if I want to use global uint32_t variable without mutex,must I define all
the variables as volatile style?
“Chris McKillop” <cdm@qnx.com> wrote in message
news:aactet$drc$1@nntp.qnx.com…
It is really going to depend on your CPU architecture and compiler for
any operation on a single variable to be atomic. Generally you should
use the atomic*() API for manipulating variables without mutexes.chris
zhz_zhang <> zhz_zhang@263.net> > wrote:
Is uint8_t,uint16_t ,uint32_t, uint64_t are thread-safety?I think that the system 8bit-char as one work unit.
So if I use uint8_t to define variable as global data ,
without mutexs in Multi-threads ,program can still correctly
read from or write to the variable.
That is to say,without mutex,threads can correctly read or write char
variable.But to the uint16_t ,uint32_t, uint64_t variable,
I think that
without mutex If I use uint16_t ,uint32_t or uint64_t to define
some variable as global data in Multi-threads or Multi-process,
suppose that one thread is reading a uint32_t variable,but at
the same time ,another thread is writing the same variable,something
would be happened. Maybe the reading thread read wrong data of uint32_t
variable because the writing thread is changing the variable.
So In the environment ,if I want to use uint16_t ,uint32_t
or uint64_t safety ,I must use mutexs.I don’t know whether what I think above is right?
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
I have seen the atomic* in the qnx lib,but the variable must be volatile
style.
such as
void atomic_set( volatile unsigned * loc,
unsigned bits );
what is volatile,it seems to be associated with the compiler,now I still
cannot understand what the meaning of “volatile”.
if I want to use global uint32_t variable without mutex,must I define all
the variables as volatile style?
“Chris McKillop” <cdm@qnx.com> wrote in message
news:aactet$drc$1@nntp.qnx.com…
It is really going to depend on your CPU architecture and compiler for
any operation on a single variable to be atomic. Generally you should
use the atomic*() API for manipulating variables without mutexes.chris
zhz_zhang <> zhz_zhang@263.net> > wrote:
Is uint8_t,uint16_t ,uint32_t, uint64_t are thread-safety?I think that the system 8bit-char as one work unit.
So if I use uint8_t to define variable as global data ,
without mutexs in Multi-threads ,program can still correctly
read from or write to the variable.
That is to say,without mutex,threads can correctly read or write char
variable.But to the uint16_t ,uint32_t, uint64_t variable,
I think that
without mutex If I use uint16_t ,uint32_t or uint64_t to define
some variable as global data in Multi-threads or Multi-process,
suppose that one thread is reading a uint32_t variable,but at
the same time ,another thread is writing the same variable,something
would be happened. Maybe the reading thread read wrong data of uint32_t
variable because the writing thread is changing the variable.
So In the environment ,if I want to use uint16_t ,uint32_t
or uint64_t safety ,I must use mutexs.I don’t know whether what I think above is right?
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
“zhz_zhang” <zhz_zhang@263.net> wrote in message
news:aadglh$o25$1@inn.qnx.com…
I have seen the atomic* in the qnx lib,but the variable must be volatile
style.
such asvoid atomic_set( volatile unsigned * loc,
unsigned bits );what is volatile,it seems to be associated with the compiler,now I still
cannot understand what the meaning of “volatile”.
if I want to use global uint32_t variable without mutex,must I define all
the variables as volatile style?
volatile informs the compiler not to optimized this variable, take for
example:
if ( *loc == 10 ) {
}
if ( *loc == 11 ) {
}
What the compiler might do is for the first if, read the variable
from *loc and then store it in a CPU register and then the
second if is performed on the the content of the register
and not the content of the memory location. volatile would tell
the compiler to be less agressive about optimisation.
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:aactet$drc$> 1@nntp.qnx.com> …
It is really going to depend on your CPU architecture and compiler for
any operation on a single variable to be atomic. Generally you should
use the atomic*() API for manipulating variables without mutexes.chris
zhz_zhang <> zhz_zhang@263.net> > wrote:
Is uint8_t,uint16_t ,uint32_t, uint64_t are thread-safety?I think that the system 8bit-char as one work unit.
So if I use uint8_t to define variable as global data ,
without mutexs in Multi-threads ,program can still correctly
read from or write to the variable.
That is to say,without mutex,threads can correctly read or write char
variable.But to the uint16_t ,uint32_t, uint64_t variable,
I think that
without mutex If I use uint16_t ,uint32_t or uint64_t to define
some variable as global data in Multi-threads or Multi-process,
suppose that one thread is reading a uint32_t variable,but at
the same time ,another thread is writing the same variable,something
would be happened. Maybe the reading thread read wrong data of
uint32_t
variable because the writing thread is changing the variable.
So In the environment ,if I want to use uint16_t ,uint32_t
or uint64_t safety ,I must use mutexs.I don’t know whether what I think above is right?
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\
“Wojtek Lerch” <wojtek_l@yahoo.ca> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:aa96vs$gvb$1@nntp.qnx.com…
Mario Charest <> goto@nothingness.com> > wrote:
Problem with unsigned short is it can have different size
depending on the CPU type/mode. Using uint16_t will ensure
size of the variable is the same on all platforms.More accurately, on all platforms that define uint16_t… >
–
Wojtek Lerch QNX Software Systems Ltd.
Even more accurately, on all platforms that define uint16_t the same way
“Dmitri Ivanov” <ivdal@yahoo.com> wrote in message news:<ahm5fb$9tn$1@inn.qnx.com>…
“Wojtek Lerch” <> wojtek_l@yahoo.ca> > ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:aa96vs$gvb$> 1@nntp.qnx.com> …
Mario Charest <> goto@nothingness.com> > wrote:
Problem with unsigned short is it can have different size
depending on the CPU type/mode. Using uint16_t will ensure
size of the variable is the same on all platforms.More accurately, on all platforms that define uint16_t… >
Even more accurately, on all platforms that define uint16_t the same way >
Actually, no. On all platforms that define uint16_t correctly. The
C Standard requires that uint16_t, if defined at all, must be an
unsigned type with 16 value bits and no padding bits. That pretty
much defines its size, even though different machines and compilers
can defined it differently, for instance as “unsigned short”,
“unsigned int” (on a machine with 16-bit ints), “unsigned char” (on a
machine with 16-bit chars), or something magical like “unsigned
attribute( width = 16 )” (I admit I made this one up).