Velocity Reviews > Integer to "string" conversions

# Integer to "string" conversions

bwaichu@yahoo.com
Guest
Posts: n/a

 09-30-2006
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 >> & 0xff;
buf[3] = (unsigned char) nbr & 0xff;

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

exit(EXIT_SUCCESS);
}

Eric Sosman
Guest
Posts: n/a

 09-30-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

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

Probably things like "%5d" or "%05d".

--
Eric Sosman
(E-Mail Removed)lid

mkaras
Guest
Posts: n/a

 09-30-2006
(E-Mail Removed) wrote:
> 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 >> & 0xff;
> buf[3] = (unsigned char) nbr & 0xff;
>
> for(i = 0; i < 4; i++)
> printf("%d\n", buf[i]);
>
> exit(EXIT_SUCCESS);
> }

You are making your life far far too hard.

A) If you you used the following:

char buf[25];
unsigned int num = 3784;
sprintf(buf, "%d", num);

you could easily use strlen(buf) to figure out how long the sprintf()
result is.

B) Why not combine all the string formatting together into one process
using something like:

char buf[100];
unsigned int num = 23405;
unsigned int num2 = 978;
char name[] = "Ben Hurr";
sprintf(buf, "%10d %s - %d\n", num, name, num2);

- mkaras

pete
Guest
Posts: n/a

 09-30-2006
(E-Mail Removed) wrote:
>
> 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'
>

sizeof "123" is four, not three.

p[3] = '\0'

--
pete

bwaichu@yahoo.com
Guest
Posts: n/a

 09-30-2006

mkaras wrote:

> You are making your life far far too hard.
>
> A) If you you used the following:
>
> char buf[25];
> unsigned int num = 3784;
> sprintf(buf, "%d", num);
>
> you could easily use strlen(buf) to figure out how long the sprintf()
> result is.

True, but then buf grows even larger. Let me explain what I am doing.
I am writing a file to a socket. I am working on designing the
protocol,
so I want to write the size of the file as well as other information
before
appending a portion of the file to the buffer. I need to make sure that
the size of the file is all ways at the same place in the buffer, and I
want to make sure the portion of the file all ways starts in the
same place.

Once that is done, the receiving end will know how to process the
packet

At the end of the day, I am just copying between two buffers. The file
transfer
stuff is implementation specific -- off topic here. One side just
creates a
buffer and sends if over the wire. The other side writes that packet
to a buffer
and processes it. It still is just copying one buffer to another.

>
> B) Why not combine all the string formatting together into one process
> using something like:
>
> char buf[100];
> unsigned int num = 23405;
> unsigned int num2 = 978;
> char name[] = "Ben Hurr";
> sprintf(buf, "%10d %s - %d\n", num, name, num2);

I intend to write specific functions for handling the creation of the
final buffer.
I posted one under "more buffer" here a while ago. That one just
appended
characters to a buffer and resized as needed. I received great
feedback
for expanding that buffer by incremental pages. That solution is
working out great.
It lead me to look more carefully at bitwise operators.

For the purposes of this buffer, I do not need to nul terminate, I just
need
to store somewhere the location of the end of the buffer as well as the
size of
the buffer. But I can nul terminate for the sake of maintaining c
strings, and just overwrite
the nul terimator with the subsequent append.

CBFalconer
Guest
Posts: n/a

 10-01-2006
"(E-Mail Removed)" wrote:
>
> 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;

unsigned long nbr;
> unsigned char buf[4];
>
> nbr = 0xff100401;

/* memset(buf, 0, sizeof buf); */
>
> buf[0] = (unsigned char)(nbr >> 24) & 0xff;
> buf[1] = (unsigned char)(nbr >> 16) & 0xff;
> buf[2] = (unsigned char)(nbr >> & 0xff;
> buf[3] = (unsigned char) nbr & 0xff;
>

for (i = 0; i < 4; i++) printf("%03d ", buf[i]);
putchar('\n');
>
> exit(EXIT_SUCCESS);
> }

Does the above do what you want? Note changes.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net> (C-info)

bwaichu@yahoo.com
Guest
Posts: n/a

 10-01-2006

CBFalconer wrote:
> > #include <stdio.h>
> > #include <stdlib.h>

> /* #include <string.h>
> */
> > int
> > main(void) {
> > int i;

> unsigned long nbr;
> > unsigned char buf[4];
> >
> > nbr = 0xff100401;

> /* memset(buf, 0, sizeof buf); */
> >
> > buf[0] = (unsigned char)(nbr >> 24) & 0xff;
> > buf[1] = (unsigned char)(nbr >> 16) & 0xff;
> > buf[2] = (unsigned char)(nbr >> & 0xff;
> > buf[3] = (unsigned char) nbr & 0xff;
> >

> for (i = 0; i < 4; i++) printf("%03d ", buf[i]);
> putchar('\n');
> >
> > exit(EXIT_SUCCESS);
> > }

>
> Does the above do what you want? Note changes.

Yes. Here's taking those changes to the next step:

int
main(void) {

int i;
unsigned long nbr, nbr2;
unsigned char buf[4];

nbr = 0xff100401;

printf("%lu\n", nbr);

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

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

nbr2 = (unsigned long)buf[0] << 24;
nbr2 |= (unsigned long)buf[1] << 16;
nbr2 |= (unsigned long)buf[2] << 8;
nbr2 |= (unsigned long)buf[3];

printf("%lu\n", nbr2);

exit(EXIT_SUCCESS);
}

I am able to "save" the integer to the buffer and extract it later.
You removed my
memset because I was immediately assigning the array after it, right?
unsigned
long is 32 bit, so you backed away my implementation specific type. But
I don't
quite get your printf change. It guarantees that each item printed
from the array
buf is 3 characters wide and will lead with a zero if needed. Why that
change?

Thanks!

Christopher Layne
Guest
Posts: n/a

 10-01-2006
(E-Mail Removed) wrote:
> True, but then buf grows even larger. Let me explain what I am doing.
> I am writing a file to a socket. I am working on designing the
> protocol,
> so I want to write the size of the file as well as other information
> before
> appending a portion of the file to the buffer. I need to make sure that
> the size of the file is all ways at the same place in the buffer, and I
> want to make sure the portion of the file all ways starts in the
> same place.
>
> Once that is done, the receiving end will know how to process the
> packet

You are still making this incredibly too hard for what is normally done. By
hard I mean you shouldn't be converting integers to strings, etc. just to
transmit it over a socket. You're working with sockets, so we're already out
of comp.lang.c land, and I'm adding comp.unix.programmer here. As a result of
working with sockets, you SHOULD have the standard repertoire of functions
available. If you want to transmit the size of a file, previous to the file,
aka LV, or extended more, TLV (type-length-value), you do just that. However,
you design things ahead of time such that both sides know what protocol
they're speaking, and you always transmit any single object larger than a
byte in network byte order. This applies to shorts, ints, longs, etc. It does
not apply to streams of byte data. Before you even get into this territory,
it's pretty much required that you pick up a copy of W. Richard Stevens: Unix
Network Programming, Volume 1. Without it, you're going to make a lot of
novice mistakes.

In your particular example, you want to send size first, most likely as a
network byte order uint_32t and then the stream of bytes representing the
file. Extremely basic protocol, essentially:

/*
* all code below not entirely comp.lang.c safe
*/

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/uio.h>

ssize_t file_send(int, char *, size_t);
ssize_t file_recv(int, char *, size_t);

ssize_t file_send(int s, char *buf, size_t sz)
{
struct iovec packet[2];
ssize_t bw;
uint32_t nbo_sz;

/* host to network long, look it up and use it, or else */
nbo_sz = htonl(sz);
packet[0].iov_len = sizeof(nbo_sz);
packet[0].iov_base = &nbo_sz;
packet[1].iov_len = sz;
packet[1].iov_base = buf;

/*
* naive, don't do as one call and call it a day, and don't do it as
* blocking. this is entirely for simple contrived example.
* read: W. Richard Stevens: UNPv1
*/
if ((bw = writev(s, packet, 2)) == -1) {
perror("writev");
return -1;
}

return bw;
}

ssize_t file_recv(int s, char *buf, size_t sz)
{
struct iovec packet[2];
ssize_t br, brt = 0;
uint32_t nbo_sz;

/*
* in this recv example, one doesn't necessarily need to use iovecs,
* but it's a good idea as you may end up sending more than just size
* initially.
*/
packet[0].iov_len = sizeof(nbo_sz);
packet[0].iov_base = &nbo_sz;

/*
* naive, don't do as one call and call it a day, and don't do it as
* blocking. this is entirely for simple contrived example.
* read: W. Richard Stevens: UNPv1
*/
if ((br = readv(s, packet, 1)) == -1) {
return -1;
}
brt += br;

/* network to host long, look it up and use it, or else */
nbo_sz = ntohl(nbo_sz);

/*
* better handle nbo_sz > sz, and handle it appropriately either
* through a callback to handle the remaining bytes, realloc, etc
* or some other form of unexpected case handling or do it
* after the intial sz-max read.
*/
packet[0].iov_len = nbo_sz > sz ? sz : nbo_sz; /* example only */
packet[0].iov_base = buf;

/*
* naive, don't do as one call and call it a day, and don't do it as
* blocking. this is entirely for simple contrived example.
* read: W. Richard Stevens: UNPv1
*/
if ((br = readv(s, packet, 1)) == -1) {
return -1;
}
brt += br;

/*
* possibly handle nbo_sz > sz here by calling a user supplied callback
* to realloc or store elsewhere or some other form of unexpected case
* handling. either way, plan for it - as it will happen.
*/

return brt;
}

CBFalconer
Guest
Posts: n/a

 10-01-2006
"(E-Mail Removed)" wrote:
> CBFalconer wrote:
>

.... snip ...
>
> for (i = 0; i < 4; i++)
> printf("%03d", buf[i]);
> putchar('\n');
>

.... snip ...
>
> I don't quite get your printf change. It guarantees that each
> item printed from the array buf is 3 characters wide and will
> lead with a zero if needed. Why that change?

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

--
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>

Christopher Layne
Guest
Posts: n/a

 10-01-2006
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.