Thread: New idea on conveting byte to bits/bits to byte

Code:

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

void foo(FILE *file, unsigned char value)
{
   unsigned char bit;
   for ( bit = 1 << (CHAR_BIT - 1); bit; bit >>= 1 )
   {
      fputc(value & bit ? '1' : '0', file);
   }
}

int main(void)
{
   const char filename[] = "file.txt";
   FILE *file = fopen(filename, "wb");
   if ( file )
   {
      const char text[] = "My question is why?\n";
      size_t i;
      for ( i = 0; i < sizeof text; ++i )
      {
         foo(file, text[i]);
      }
      fclose(file);
      file = fopen(filename, "rb");
      if ( file )
      {
         char buffer[CHAR_BIT + 1];
         while ( fgets(buffer, sizeof buffer, file) )
         {
            fputc(strtol(buffer, NULL, 2), stdout);
         }
         fclose(file);
      }
   }
   return 0;
}

/* my output
My question is why?
*/

I think the problem you're having is you have an idea and you are asking us how to do something that you think will help with your idea, but we haven't been told what the idea is. We're guessing and confusing everyone.

Start again and
1) explain in detail what you are trying to do.
2) Then ask how to do it.

What I think you've done so far is skip step 1 in your posts. And add it to this thread, don't start another one.

There you go. All you need to know about bits. Test a bit. Write either a one or zero to an array. Later, rinse, repeat.

Quzah.

Ah, yes. What you are missing is understanding the terminology.

Originally posted by megablue
What i'm trying to do is simply convert a 1 byte to 8 bits.

You see, a byte is 8 bits. C does not really have a 'bit type'

1)Firtsly i want to read a file let it be fileA which contain 5 byte.

2)inside a loop it will start read byte to byte until EOF.

--a)The one byte will be converted to 8 bits(eg: 10011001) each bits will be convered to a byte and store them to array (bits[1]=='1'.... bits[7]=='0'.....bits[8]=='1')

And here's the explanation I wanted to see. IOW:
--a)The one byte will be "converted" to an 8 byte array, each byte of which contains the value of each source bit....

...
i think my explaination is clear by now.... thx for guiding me!! =)

You are welcome. Definitely read the info at the link Q mentioned above.

In most instances a byte is indeed 8 bits. Some platforms may define a bit as being more than 8 bits, but in ALL IBM PC based platforms operating with one of the 8086 family of processors a byte is always eight bits. When the processor goes to fetch a byte, it will actually fetch 8 bytes or 32 bits. All modern CPU fetches are 32 bits no matter what, even in real mode although this is hidden somewhat.

So the phrase 'convert 1 byte to 8 bits' is crazy because 1 byte is 8 bits.

<1|0>*(2^0)
<1|0>*(2^1)
<1|0>*(2^2)
<1|0>*(2^3)
<1|0>*(2^4)
<1|0>*(2^5)
<1|0>*(2^6)
<1|0>*(2^7)


Assembly language data types
BYTE is 8 bits
WORD is 16 bits
DWORD is 32 bits
QWORD is 64 bits - FPU and MMX

Now this all gets confusing in C when you move to 32-bit protected mode because unsigned int are DWORDs and not WORDs. Most stay away from these data types but I stick with them.

Fact is, in any given C program a WORD is always always always going to be 16 bits in assembly. See in 32-bit mode the compiler does some jiggy stuff and makes and unsigned int into 32-bits or a DWORD. But in 16-bit mode an unsigned int is a WORD. So the best way to think about your data types is not from a C standpoint but from an assembly standpoint IMO. Simply because C can be misleading when you move from 16 to 32 bit. Assembly data types never ever change and the native language of the CPU is assembly opcodes. So a movsd will ALWAYS move 32 bits no matter what. For instance besides the stack being different in the following function, notice how it is called from C.


__Add32 proc
ARG v1:DWORD,v2:DWORD
push ebp
mov ebp,esp

mov eax,[v1]
add eax,[v2]

pop ebp
ret
__Add32 endp


16-bit version
extern "C" unsigned long Add32(unsigned long v1,unsigned long v2)

32-bit version
extern "C" unsigned int Add32(unsigned int v1,unsigned int v2)

So the C data types 'int' and 'long' change from 32-bit to 16-bit. So you would think that a double in 32-bit is actually 128 bits, but alas its not. It's still 64 bits. Also the 'char' data type does not change with 16 bit or 32 bit. It is always 8 bits. Intel has always allowed programmers to access individual bytes and will continue to based on their tech manuals. A byte on an Intel/AMD machine is always 8 bits - even on IA64.

Because of the problems associated with int and long I stay away from these names for data types and instead use their assembly equivalents. If I was programming on another platform I would typedef the C data types to correspond to the appropriate CPU data type for it.

If you want a good example of how to screw up data types and make an easy principle very convoluted, simply examine windows.h and your head will spin for days. Personally, I've never had problems with my method

But you must remember that regardless of the sign of the number, it's the number of bits in the value, including the sign bit, that will determine its data type.

>so in c terminology a byte can be not a byte?!

This sounds familiar.

Originally posted by Omnius
Note that in C terminology, a byte may not be exactly 8 bits, but is guaranteed to be at least 8 bits. It could indeed be more. The size of a byte is tied in with the size of the char type, and the number of bits can be determined from CHAR_BIT in <limits.h> for any particular implementation.

That is true -- but I'll bet 99.99% of the people on this board are using systems where the byte value is exactly 8 bits. And those that do work on systems with different byte sizes already know this.

For the sake of this board, and so as not to complicate the matter for somewhat inexperienced programmers (see megablue's response) I'm ignoring this fact. It simply muddies the waters.

The first system I ever used defined a 36 bit word. Bytes were non-existant, but they did have a half-word defined. But you could not use them as separate entities. Characters were stored 5 chars per word with 1 bit left over (7-bit ASCII).