Integer to "string" conversions

[bwaichu]

Now, I read the faq, and it suggests using sprintf. However,
I want to all ways know where the integer finishes in the string.
Basically, I want to:

nbr | other data

But the other data all ways has to start at the same place. I had
some problems using sprintf to accomplish this requirement. Maybe
I am overlooking something. But sprintf translates the nbr exactly
into
the string, so the nbr 123, would end up occupying:

p[0] = '1'
p[1] = '2'
p[2] = '3'

So as the number grew, the space taken grew.

To solve this, I went with the solution below. But this would require
me
to OR back the number later. Is there a better way to do this?

Note: I am using uint32_t to signify a 32 bit unsigned integer. This
is implementation
specific, but for the sake of this discussion, I need to know
the size
of the integer being assigned to buf ahead of time. I am also
ignoring
dynamically allocated arrays for this discussion as well.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int
main(void) {

int i;
uint32_t nbr;
unsigned char buf[4];

nbr = 0xffffffff;
memset(buf, 0, sizeof buf);

buf[0] = (unsigned char)(nbr >24) & 0xff;
buf[1] = (unsigned char)(nbr >16) & 0xff;
buf[2] = (unsigned char)(nbr > 8) & 0xff;
buf[3] = (unsigned char) nbr & 0xff;

for(i = 0; i < 4; i++)
printf("%d\n", buf[i]);

exit(EXIT_SUCCE SS);
}

[bwaichu]

Christopher Layne wrote:

CBFalconer wrote:

I thought you were complaining that the field used varied with the
value. If you don't want the leading zeroes, remove the '0'.

As far as I could tell, he was looking for a way of encoding "size" in a fixed
length method that would be network-portable. snprintf() could be used for
that, in a rather bizarre, inefficient, and roundabout way.

True. But I wanted to leave the network related items off this
newsgroup. And
I have read Stevens' book.

[Christopher Layne]

bw*****@yahoo.c om wrote:

True. But I wanted to leave the network related items off this
newsgroup. And
I have read Stevens' book.

Understandable. But why even consider such a ridiculous way of encoding when
the tried and true method is both more efficient, lower overhead, and more
natural?

[bwaichu]

Christopher Layne wrote:

Understandable. But why even consider such a ridiculous way of encoding when
the tried and true method is both more efficient, lower overhead, and more
natural?

What's the tried and true method? I did not get a lot out of Stevens'
when it comes
to protocol design. I saw a lot of different approaches to the
blocking problem.
But I never considered using writev or readv to build a protocol. I
figured I would
just write the protocol stuff to the front of the buffer and read it on
the other end
after doing any network translation as needed.

So you would build all your protocol information into struct iovec?
Basically, I was
thinking of sending only a few items: crc or sha1, file size, and file.
I was going
to buffer this out at the page size or twice the page size. My
approach to handling
the blocking problem was to use pthreads. Once this worked, my next
step was
to use ssl.

Of course, all of this is off topic here.

Cheers!

[Christopher Layne]

bw*****@yahoo.c om wrote:

So you would build all your protocol information into struct iovec?

I mainly use iovec's because they are natural for this purpose and also
because of the win/win of not having to marshal data into a temporary buffer
(don't even think of sending a struct over the network either) and/or call
read() more than once. That's the main goal of readv()/writev().

Basically, I was
thinking of sending only a few items: crc or sha1, file size, and file.
I was going
to buffer this out at the page size or twice the page size.

No need to do this really, that is page size buffering, etc. - atleast for the
transmission side. What one typically does is handle things via typical
realloc() and keep that larger buffer around for the life of the program or
downsize it to an average size seen, bordering a page boundary. As far as the
protocol itself, a basic protocol will revolve around TLV encoding + 1 main
header and possibly a trailer (although unlikely). Keep things small but not
so small there is no room for future expansion - and possibly consider a
version byte, or short.

My
approach to handling
the blocking problem was to use pthreads. Once this worked, my next
step was
to use ssl.

Let me give you some guidance here, as I have direct experience with it,
including pthreads + socket programming. Attempting to use threads (let's say
thread per connection) as a method of getting around blocking is going to
result in eventual pain - and not because of threading - just that one cannot
100% trust select(). The best way to get around blocking issues is to do just
that - write non-blocking handlers. If you need example code for all basic
socket routines, let me know - but I highly recommend writing your own first
so you can make the common mistakes and figure out they were made. It's
really not total rocket science, but don't make any assumptions. This is
where UNPv1 will come in extremely valuable. For a while I thought my
readv()/writev() routines would never return a partial read or partial write
space available error. It only took one serious stream of data above the MTU
to prove this wrong. This particular situation was only a tad more difficult
than normal as prior-documentation for it wasn't really out there on the net
(for readv()/writev() specifically). Like I said, just don't even bother with
blocking mode.

Of course, all of this is off topic here.

Yep, comp.unix.progr ammer. Followed up.