Bytes to bits

[Sync_net]

I am not sure if this a valid topic to be asked in the groups. --Kindly
suggest me a technique/algorithm by which i can convert a stream of
data (we could take it to be characters -- stream of 8 bit data) to
sets of 13 bits each and then further convert this 13 bit data to
integer. I have been able to do this when i know the length of the
input string before hand. But i am not able to generalize this for a
stream of data (or char).

 

[Vladimir Oka]

I am not sure if this a valid topic to be asked in the groups.

Not really, as it's not C specific. Better guess is comp.programming.
However, before you go there, I suggest you better define your problem.
See comments below:

suggest me a technique/algorithm by which i can convert a stream of
data (we could take it to be characters -- stream of 8 bit data)

Is it 8 bits or is it not, or are you asking for a general method,
regardless of the number of bits?

to sets of 13 bits each

What is the "set" you're talking about. How does this conversion work?

and then further convert this 13 bit data to integer.

What sort of "integer". In C, you have different flavours: short, long,
signed, unsigned, and char is also an integer type (and there are
combinations of those as well).

I have been able to do this when i know the length of the
input string before hand. But i am not able to generalize this for a
stream of data (or char).

I don't understand why you're having problems with this. If you're
converting data that's less than 13 bits wide, then for every datum
coming in, you know you'll have to allocate 13 bits for output. If you
don't know how may are coming in advance, you can always allocate
memory dynamically. How you do that depends on your language of choice,
but you first have to define the problem precisely.

 

[vire]

eh...i am a little poor in english. and i can hardly understand what
you said.
maybe a "bit field" and a "union" can help you.
a "bit field" is a kind of spacial struct structure. you can define how
many bits a member take.
like:
typedef struct{
unsigned int f1:1;
unsigned int f2:1;
unsigned int f3:1;
unsigned int f4:1;
unsigned int type:4;
} pack;
so sizeof(pack) is 8;
//just google "bit field",you'll find more helpful answer.

if you define a union like the following:
union u_type{
pack apack;
int convert_result;
};
then you changes every bits in "apack" will get a new "convert_result";

 

[vire]

eh...i am a little poor in english. and i can hardly understand what
you said.
maybe a "bit field" and a "union" can help you.
a "bit field" is a kind of spacial struct structure. you can define how

many bits a member take.
like:
typedef struct{
unsigned int f1:1;
unsigned int f2:1;
unsigned int f3:1;
unsigned int f4:1;
unsigned int type:4;

} pack;


so sizeof(pack) is 8;
//just google "bit field",you'll find more helpful answer.

if you define a union like the following:
union u_type{
pack apack;
int convert_result;


};


then everytime you change bits in "apack" will get a new
"convert_result";

 

[vire]

eh...i am a little poor in english. and i can hardly understand what
you said.
maybe a "bit field" and a "union" can help you.
a "bit field" is a kind of spacial struct structure. you can define how


many bits a member take.
like:
typedef struct{
unsigned int f1:1;
unsigned int f2:1;
unsigned int f3:1;
unsigned int f4:1;
unsigned int type:4;



} pack;


//just google "bit field",you'll find more helpful answer.

if you define a union like the following:
union u_type{
pack apack;
int convert_result;



};


then everytime you change bits in "apack" will get a new
"convert_result";

 

[Keith Thompson]

eh...i am a little poor in english. and i can hardly understand what
you said.

[...]

And most of the rest of us have no idea what he said, because you
didn't provide any context. Read <http://cfaj.freeshell.org/google/>.

Also, you posted nearly the same thing three times. Once would have
been sufficient. (If you tried to cancel the first two attempts, be
aware that cancels often don't work. Make sure your article is
correct before you submit it.)

 

[vire]

i am really so sorry for having done that stupid thing.
because of my poor english , i will just provide some code below , hope
to express my thoughts well.

#include <stdio.h>
typedef struct{
unsigned int f0:1;
unsigned int f1:3;
unsigned int f2:4;
unsigned int f3:4;
unsigned int f4:4;
unsigned int type:16;

}pack;

typedef union converter{
pack apack;
int convert_result;
}converter;

int main(){
converter aconverter;
aconverter.apack.f0=0x1;
aconverter.apack.f1=0x7;
aconverter.apack.f2=0xf;
aconverter.apack.f3=0xf;
aconverter.apack.f4=0xf;
aconverter.apack.type=0xffff;
printf("%X\n",aconverter.convert_result);
return 0;
}

if this still cannot give any help..er..i think i had to remove my post
..
Sorry to be a bother.please forgive me.

 

[Vladimir Oka]

vire opined:

i am really so sorry for having done that stupid thing.

What stupid thing? Not quoting any context again? You've been told
before. It's worse than posting multiple times (for that at least, you
can blame buggy Google interface).

because of my poor english , i will just provide some code below ,
hope to express my thoughts well.

Code only sometimes explains the thoughts well. I'll leave it, in case
someone wants to comment (I have a train to catch).

#include <stdio.h>
typedef struct{
unsigned int f0:1;
unsigned int f1:3;
unsigned int f2:4;
unsigned int f3:4;
unsigned int f4:4;
unsigned int type:16;

}pack;

typedef union converter{
pack apack;
int convert_result;
}converter;

int main(){
converter aconverter;
aconverter.apack.f0=0x1;
aconverter.apack.f1=0x7;
aconverter.apack.f2=0xf;
aconverter.apack.f3=0xf;
aconverter.apack.f4=0xf;
aconverter.apack.type=0xffff;
printf("%X\n",aconverter.convert_result);
return 0;
}

if this still cannot give any help..er..i think i had to remove my
post .

You probably shouldn't bother. Removing posts rarely has the desired
effect. Better think carefully before posting in the first place.

--
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."
(By (e-mail address removed))

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

 

[Keith Thompson]

i am really so sorry for having done that stupid thing.

Don't worry about it too much. We've seen *much* worse around here.

But you're still not providing context. Please read

because of my poor english , i will just provide some code below , hope
to express my thoughts well.

#include <stdio.h>
typedef struct{
unsigned int f0:1;
unsigned int f1:3;
unsigned int f2:4;
unsigned int f3:4;
unsigned int f4:4;
unsigned int type:16;

}pack;

typedef union converter{
pack apack;
int convert_result;
}converter;

int main(){
converter aconverter;
aconverter.apack.f0=0x1;
aconverter.apack.f1=0x7;
aconverter.apack.f2=0xf;
aconverter.apack.f3=0xf;
aconverter.apack.f4=0xf;
aconverter.apack.type=0xffff;
printf("%X\n",aconverter.convert_result);
return 0;
}

The layout of bit fields is compiler-specific. Your code assumes that
an int is 32 bits; it could be as small as 16 bits, or arbitrarily
large (64 bits is common). Even if int is 32 bits, the behavior of
the program will vary depending on how the compiler lays out the bit
fields and on byte ordering.

 

[vire]

vire opined:


What stupid thing? Not quoting any context again? You've been told
before. It's worse than posting multiple times (for that at least, you
can blame buggy Google interface).

Read <http://cfaj.freeshell.org/google/>.

i was too hurry to explain my apologies that i had missed the context
for the 2nd time.
my mistake.it won't happen any more.

Code only sometimes explains the thoughts well. I'll leave it, in case
someone wants to comment (I have a train to catch).

You probably shouldn't bother. Removing posts rarely has the desired
effect. Better think carefully before posting in the first place.

thank you for your advice. i think i will do it better in the future.

Don't worry about it too much. We've seen *much* worse around here.

But you're still not providing context. Please read
<http://cfaj.freeshell.org/google/>.

That's very kind of you . i feel much better now.

The layout of bit fields is compiler-specific. Your code assumes that
an int is 32 bits; it could be as small as 16 bits, or arbitrarily
large (64 bits is common). Even if int is 32 bits, the behavior of
the program will vary depending on how the compiler lays out the bit
fields and on byte ordering.

yes .i've just assumed that int was 32 bits.but the code was not
supposed to solve the problem in the top if you won't go any further
with it.
you can use sizeof in the bit fields to get a better layout. such as
unsigned f1: sizeof(int)*8/4;

you may defined a union with a char and a bit field to get every bit
of the char(remember that a char was an ASCII code integer).

now i have a new idea.
if we have
char array[9]="01101110";
we can write these code:
int i,a=0;
for(i =0; i<strlen(array);i++){
a = a*2+array-0x30;
}
for the stream maybe there is a little different.
if your have a stream of char such as "4A3C",you may use the union
above to get the bits of the characters first.
many thanks to Keith Thompson , and Vladimir Oka .

 

[Keith Thompson]

Keith Thompson wrote: [...]

The layout of bit fields is compiler-specific. Your code assumes that
an int is 32 bits; it could be as small as 16 bits, or arbitrarily
large (64 bits is common). Even if int is 32 bits, the behavior of
the program will vary depending on how the compiler lays out the bit
fields and on byte ordering.

yes .i've just assumed that int was 32 bits.but the code was not
supposed to solve the problem in the top if you won't go any further
with it.
you can use sizeof in the bit fields to get a better layout. such as
unsigned f1: sizeof(int)*8/4;

you may defined a union with a char and a bit field to get every bit
of the char(remember that a char was an ASCII code integer).

Don't assume that a char represents an ASCII code. The C standard
doesn't specify a particular charater set. Some C implementations use
an IBM character set called EBCDIC, which is very different from
ASCII; others use various extensions of ASCII (ASCII itself is only a
7-bit character set).

now i have a new idea.
if we have
char array[9]="01101110";
we can write these code:
int i,a=0;
for(i =0; i<strlen(array);i++){
a = a*2+array-0x30;
}

This assumes ASCII; the value 0x30 isn't necessarily meaningful in
another character set. To convert a digit character to its numeric
value, you can use:

char c = '7';
int d = c - '0';

Though C doesn't specify a character set, it does guarantee that the
characters '0' through '9' have contiguous values.

 

[CBFalconer]

.... snip ...

now i have a new idea.
if we have
char array[9]="01101110";
we can write these code:
int i,a=0;
for(i =0; i<strlen(array);i++){
a = a*2+array-0x30;
}

This assumes ASCII; the value 0x30 isn't necessarily meaningful in
another character set. To convert a digit character to its numeric
value, you can use:

char c = '7';
int d = c - '0';

Though C doesn't specify a character set, it does guarantee that
the characters '0' through '9' have contiguous values.

Any holes in the following, which is intended to avoid using any
library calls other than getc(f), for string base 10 to integer
conversion:

unsigned int num, digit;
FILE *f; /* assume initialized */

num = 0;
while ((digit = (getc(f) - '0')) <= 9) {
num = 10 * num + digit; /* ignoring overflows */
}

and at exit (digit + '0') yields the terminating input, which may
well be equal to (unsigned)EOF, or something else. It will not be
a digit.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Flash Gordon]

CBFalconer wrote:

Any holes in the following, which is intended to avoid using any
library calls other than getc(f), for string base 10 to integer
conversion:

unsigned int num, digit;
FILE *f; /* assume initialized */

num = 0;
while ((digit = (getc(f) - '0')) <= 9) {
num = 10 * num + digit; /* ignoring overflows */
}

and at exit (digit + '0') yields the terminating input, which may
well be equal to (unsigned)EOF, or something else. It will not be
a digit.

What if EOF is defined as INT_MIN? Then, on end-of-file you get INT_MIN
- '0' which gives you a negative overflow and undefined behaviour.

 

[vire]

Keith Thompson wrote:

[...]
Don't assume that a char represents an ASCII code. The C standard
doesn't specify a particular charater set. Some C implementations use
an IBM character set called EBCDIC, which is very different from
ASCII; others use various extensions of ASCII (ASCII itself is only a
7-bit character set).
[...]
This assumes ASCII; the value 0x30 isn't necessarily meaningful in
another character set. To convert a digit character to its numeric
value, you can use:

char c = '7';
int d = c - '0';

Though C doesn't specify a character set, it does guarantee that the
characters '0' through '9' have contiguous values.

Yes, absolutely you are right.

 

[CBFalconer]

CBFalconer wrote:



What if EOF is defined as INT_MIN? Then, on end-of-file you get INT_MIN
- '0' which gives you a negative overflow and undefined behaviour.

That's why num and digit are unsigned. The overflow conditions are
defined, and the exit action is reversible. getc returns an int,
which will be negative for EOF, and has to be coerced into an
unsigned. Maybe '0' should be coerced into an unsigned int to
force the "getc() - (unsigned)'0'" to be evaluated unsigned.
That's the sort of hole I was wondering about.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Flash Gordon]

That's why num and digit are unsigned.

Num and digits may be, but neither '0' not the return of getc are, and
it is on the subtraction you have the problem.

> The overflow conditions are
defined, and the exit action is reversible.

Ah, but the conversion to unsigned is after the overflow.

> getc returns an int,
which will be negative for EOF, and has to be coerced into an
unsigned. Maybe '0' should be coerced into an unsigned int to
force the "getc() - (unsigned)'0'" to be evaluated unsigned.

Yes, that is indeed the hole I meant. You need to force the subtraction
to be done unsigned.

That's the sort of hole I was wondering about.

Glad to be of service