Hi

I have an assignment that is in C and, for an API call, asks for a
uint_16 and uint_32 in one of its functions.

In my C++ code i've been using uint16_t and uint32_t for fixed length
integers. Are these two Types compatible?


Also, if i make a struct of a few variables of type uint_xxx_t, can I
be assured that this struct will be the same size on either end of the
wire when sent over a network (note, the hosts may not be the same
platform). I know that some architecture's treat int's as different
lengths, but I thought that is why we use uint_xxx_t, to solve that
poblem.

Thanks

"darren" <minofifa@gmail.com> wrote in message
news:20f8c39a-7fa2-466d-b933-b2ab90df516b@i18g2000prn.googlegroups.com...
> Hi
>
> I have an assignment that is in C and, for an API call, asks for a
> uint_16 and uint_32 in one of its functions.
>
> In my C++ code i've been using uint16_t and uint32_t for fixed length
> integers. Are these two Types compatible?

There are no guarantees, but most likely, yes, they are the same. To find
out search through your code where uint32_t and uint_32 are defined and make
sure they are the same. For all likelyhood they will be the same. It's a
good idea to check though.

> Also, if i make a struct of a few variables of type uint_xxx_t, can I
> be assured that this struct will be the same size on either end of the
> wire when sent over a network (note, the hosts may not be the same
> platform). I know that some architecture's treat int's as different
> lengths, but I thought that is why we use uint_xxx_t, to solve that
> poblem.

Well, is it your code on the other end of the network also? If it's your
code then it will be what you set it to. If it's not your code, you'll need
to check the documentation to see what they expect the size of their ints to
be.

But, yes, uint_xxx_t should be the the same size on each architecture. I'm
not positive it's declared in the standard, however, I don't have a copy of
the standard handy.

On Mon, 30 Jun 2008 15:25:51 -0700 (PDT), darren <minofifa@gmail.com>
wrote in comp.lang.c++:

> Hi
>
> I have an assignment that is in C and, for an API call, asks for a
> uint_16 and uint_32 in one of its functions.

These are not standard C data types, so we can only guess at what they
are. They are some types defined by the author(s) of the library you
are using.

> In my C++ code i've been using uint16_t and uint32_t for fixed length
> integers. Are these two Types compatible?

The types int#_t and uint#_t are standard C data types, added in the
1999, and later, versions of the C language standard. They will be
added to the next revision of the C++ standard, most likely finalized
in the next year or so. But they are not part of standard C++ yet.

As Jim Langston already suggested, find the headers with the typedefs
for the non-standard uint_16, etc., and those for the standard
C/semi-standard C++ uint16_t, etc., and see if they are aliases for
the same underlying types.

On today's common 32-bit desktop platforms, it is quite possible that
uint_32 could be an alias for "unsigned int" but uint32_t an alias for
"unsigned long". Or vice versa. That could result in a large number
of complaints from the compiler, depending on which headers were
included with which source code.

> Also, if i make a struct of a few variables of type uint_xxx_t, can I
> be assured that this struct will be the same size on either end of the
> wire when sent over a network (note, the hosts may not be the same
> platform). I know that some architecture's treat int's as different
> lengths, but I thought that is why we use uint_xxx_t, to solve that
> poblem.

You can't ever assume binary layout compatibility across a network,
especially if different platform are involved. Even if the sizes of
the individual members were the same, structure alignment and padding
could result in the structure being two different sizes on the
different platforms.

And the representation of the integer types could be different, even
if they have the same number of bits. The most common difference is
big- versus little-endian.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

On Jul 1, 3:13 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> "darren" <minof...@gmail.com> wrote in message

> news:20f8c39a-7fa2-466d-b933-b2ab90df516b@i18g2000prn.googlegroups.com...

> > I have an assignment that is in C and, for an API call, asks for a
> > uint_16 and uint_32 in one of its functions.

> > In my C++ code i've been using uint16_t and uint32_t for fixed length
> > integers. Are these two Types compatible?

> There are no guarantees, but most likely, yes, they are the same.

The C standard guarantees that uint16_t and uint32_t are two's
complement integers of exactly the given length, with no
padding. The next version of the C++ standard will make the
same guarantee. Presumably, the byte order could differ between
C and C++, but really, I don't see that happening.

> To find out search through your code where uint32_t and
> uint_32 are defined and make sure they are the same. For all
> likelyhood they will be the same. It's a good idea to check
> though.

In C, they're defined in <stdint.h>. In the next version of the
C++ compiler, they will be defined in <cstdint> (and in
namespace std:; until then, just use the C header.

> > Also, if i make a struct of a few variables of type
> > uint_xxx_t, can I be assured that this struct will be the
> > same size on either end of the wire when sent over a network
> > (note, the hosts may not be the same platform). I know that
> > some architecture's treat int's as different lengths, but I
> > thought that is why we use uint_xxx_t, to solve that poblem.

> Well, is it your code on the other end of the network also?
> If it's your code then it will be what you set it to. If it's
> not your code, you'll need to check the documentation to see
> what they expect the size of their ints to be.

But you can't send struct's over the wire. Or even int's. Only
bytes. So you have to define a format, and conform to it (or
use an existing format, like XDR).

> But, yes, uint_xxx_t should be the the same size on each
> architecture. I'm not positive it's declared in the standard,
> however, I don't have a copy of the standard handy.

Same size and same representation. But perhaps different byte
order.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"darren" <minofifa@gmail.com> wrote:
>
> I have an assignment that is in C and, for an API call, asks for a
> uint_16 and uint_32 in one of its functions.
>
> In my C++ code i've been using uint16_t and uint32_t for fixed length
> integers. Are these two Types compatible?
>
> Also, if i make a struct of a few variables of type uint_xxx_t, can I
> be assured that this struct will be the same size on either end of the
> wire when sent over a network (note, the hosts may not be the same
> platform). I know that some architecture's treat int's as different
> lengths, but I thought that is why we use uint_xxx_t, to solve that
> poblem.

See the other replies.
The easiest method IMO would be to convert all numbers to
string format and transfer the string over the wire,
and at the other side convert back to native format,
ie. using sprintf() and sscanf() in C/C++ or using cout and cin in C++.
So, for each struct type you would need also a unique id in stringformat.
Transfer the uid and then the data...
See also 'serialization' in your C++ documentation.

On Tue, 1 Jul 2008 01:13:23 -0700 (PDT), James Kanze
<james.kanze@gmail.com> wrote in comp.lang.c++:

> On Jul 1, 3:13 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> > "darren" <minof...@gmail.com> wrote in message
>
> > news:20f8c39a-7fa2-466d-b933-b2ab90df516b@i18g2000prn.googlegroups.com...
>
> > > I have an assignment that is in C and, for an API call, asks for a
> > > uint_16 and uint_32 in one of its functions.
>
> > > In my C++ code i've been using uint16_t and uint32_t for fixed length
> > > integers. Are these two Types compatible?
>
> > There are no guarantees, but most likely, yes, they are the same.
>
> The C standard guarantees that uint16_t and uint32_t are two's
> complement integers of exactly the given length, with no
> padding. The next version of the C++ standard will make the
> same guarantee. Presumably, the byte order could differ between
> C and C++, but really, I don't see that happening.

I know you know this...

uint16_t and uint32_t are unsigned types, therefore they are not 2's
complement. The corresponding signed equivalents, int16_t and
int32_t, must use 2's complement representation for negative values.


> > To find out search through your code where uint32_t and
> > uint_32 are defined and make sure they are the same. For all
> > likelyhood they will be the same. It's a good idea to check
> > though.
>
> In C, they're defined in <stdint.h>. In the next version of the
> C++ compiler, they will be defined in <cstdint> (and in
> namespace std:; until then, just use the C header.
>
> > > Also, if i make a struct of a few variables of type
> > > uint_xxx_t, can I be assured that this struct will be the
> > > same size on either end of the wire when sent over a network
> > > (note, the hosts may not be the same platform). I know that
> > > some architecture's treat int's as different lengths, but I
> > > thought that is why we use uint_xxx_t, to solve that poblem.
>
> > Well, is it your code on the other end of the network also?
> > If it's your code then it will be what you set it to. If it's
> > not your code, you'll need to check the documentation to see
> > what they expect the size of their ints to be.
>
> But you can't send struct's over the wire. Or even int's. Only
> bytes. So you have to define a format, and conform to it (or
> use an existing format, like XDR).
>
> > But, yes, uint_xxx_t should be the the same size on each
> > architecture. I'm not positive it's declared in the standard,
> > however, I don't have a copy of the standard handy.
>
> Same size and same representation. But perhaps different byte
> order.

....but perhaps a different number of bytes containing the same number
of bits.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html