I am reading "Joel on Software" these days, and am in stuck with the
question of "how to calculate bitsize of a byte" which is listed as one
of the basic interview questions in Joel's book. Anyone could give some
ideas?I am expecting your reply.
David.
Feb 21 '06
96  4848 
Peter Nilsson wrote: stathis gotsis wrote: "sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11********************@g43g2000cwa.googlegrou ps.com... To complicate matters, char is not required by the C standard to be the
machine "byte". It is only required to be at least 8 bits. And a
machine "byte" is not always 8 bits. And some ancient beasts even
enables the programmer to specify how many bits are in a byte. So on
those machines (I believe Unisys was one) you "defined" how many bits
was in a byte rather than test it.
So you are saying that there are two bytes: the "machine byte" and the "C
implementation byte"? I assume that because the C standard clearly states
that char is equivalent to byte.
Yes, which is why it's best to use the term 'byte' in the C language
sense,
and terms like octet or machine word for other senses.
A hardware 'byte' and 'octet' are again different things. In hardware,
a byte may be 6 bits but an octet by definition is always 8 bits even
on machines with 6 bit bytes (in which case, on that machine, it takes
2 bytes to correctly encode an octet). Which is why it is best to use
the them 'char' if you want to talk about byte in the C language sense
because you can't use the term octet to talk about bytes except in the
strict case where a byte is 8 bits.
So the original question should really have asked to calculate the size
of 'char' rather than 'byte'. But then again, in that case, a char is
always CHAR_BIT bits by definition and the code to calculate is useless
in the real world.
On 2006-02-22, sl*******@yahoo.com <sl*******@gmail.com> wrote: Peter Nilsson wrote: Yes, which is why it's best to use the term 'byte' in the C language
sense,
and terms like octet or machine word for other senses.
A hardware 'byte' and 'octet' are again different things. In hardware,
a byte may be 6 bits but an octet by definition is always 8 bits even
on machines with 6 bit bytes (in which case, on that machine, it takes
2 bytes to correctly encode an octet).
And a "machine word" is much more likely to be an int than a "byte" of
any sort.
david ullua wrote: Hi, Rod,
Martin and Vladimir has given a shorten method to find bit size of a
byte in c :). I think maybe Joe was not intended get an answer of
calculation, not looking up in an included file.
In programming language like C, compiler may set CHAR_BIT predefined.
But I wonder whether there is some cases when we don't know the bit
size of a byte in hardware CPU, and should calculate it by programming
language. The case's just like kidding, since we don't know bits of
CPU, how could programming language would work on it?
Of course the compiler does not have to be the same size as the CPU.
x86 is a good example there are 16, 32 and 64 bit compilers.
The compiler determines the byte size not the CPU.
It could have 32 bit bytes on an 8 bit CPU.
Jordan Abel wrote: On 2006-02-22, sl*******@yahoo.com <sl*******@gmail.com> wrote: Peter Nilsson wrote: Yes, which is why it's best to use the term 'byte' in the C language
sense,
and terms like octet or machine word for other senses.
A hardware 'byte' and 'octet' are again different things. In hardware,
a byte may be 6 bits but an octet by definition is always 8 bits even
on machines with 6 bit bytes (in which case, on that machine, it takes
2 bytes to correctly encode an octet).
And a "machine word" is much more likely to be an int than a "byte" of
any sort.
Hmm.. this is slowly getting to be off-topic in c.l.c. Anyway...
A byte does not refer to a word. A machine word in hardware does indeed
usually correspond to an int. A byte is usually defined as the smallest
addressible unit of memory for an architecture whereas a word is
usually defined as the native register size of the architecture
(whatever that means).
The smallest addressible memory may not always be 8 bits. And on
machines where this is smaller than 8 bits (for example 6 bits was once
very common) the C standard requires chars to be at least 8 bits. Hence
the C standard requires that on such machines two bytes be used to
represent a char. It is also common to find modern machines,
particularly DSPs, where the machine byte is 32 bits. On such machines
it is not possible to address smaller than 32 bit values (you can
access individual octets though by masking and shifting but you cannot
address individual octets).
"david ullua" <da*********@gmail.com> wrote in message
news:11********************@f14g2000cwb.googlegrou ps.com... Thanks for both of your reply.
I take a look at limits.h and other head files, there is really
something need to be read.
Before i knew CHAR_BIT is a defined value, I wrote the following
snippet to do the job:
(now i realize it is not neccessary)
char c = '\01';
int i=0;
do
{
i++;
printf("%d:%x(dex)\n",i,c);
c = c<<1;
}while(c>0);
printf("bit count in a byte:%d",i);
An alternate method that should work for ones and twos complement integers:
#include <stdio.h>
int main(void)
{
unsigned short i,j;
/* i and j must be the same type needed */
/*
unsigned long i,j;
char i,j;
*/
unsigned short k;
for(i=1,j=0,k=0;i!=j;k++,j=i,i<<=1);
k--;
printf("\nbits %d\n",k);
return(0);
}
Rod Pemberton
"sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com... Hmm.. this is slowly getting to be off-topic in c.l.c. Anyway...
A byte does not refer to a word. A machine word in hardware does indeed
usually correspond to an int. A byte is usually defined as the smallest
addressible unit of memory for an architecture whereas a word is
usually defined as the native register size of the architecture
(whatever that means).
The smallest addressible memory may not always be 8 bits. And on
machines where this is smaller than 8 bits (for example 6 bits was once
very common) the C standard requires chars to be at least 8 bits. Hence
the C standard requires that on such machines two bytes be used to
represent a char. It is also common to find modern machines,
particularly DSPs, where the machine byte is 32 bits. On such machines
it is not possible to address smaller than 32 bit values (you can
access individual octets though by masking and shifting but you cannot
address individual octets).
Based on what you said i came to the assumption that CHAR_BIT is the minimum
multiple of the number of bits in the machine byte which is equal or greater
than 8. So, given the CHAR_BIT value, one can find one or two numbers, one
of which will be the machine byte size. That means that the machine byte can
be roughly determined through C.
stathis gotsis wrote: "sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com... Hmm.. this is slowly getting to be off-topic in c.l.c. Anyway...
A byte does not refer to a word. A machine word in hardware does indeed
usually correspond to an int. A byte is usually defined as the smallest
addressible unit of memory for an architecture whereas a word is
usually defined as the native register size of the architecture
(whatever that means).
The smallest addressible memory may not always be 8 bits. And on
machines where this is smaller than 8 bits (for example 6 bits was once
very common) the C standard requires chars to be at least 8 bits. Hence
the C standard requires that on such machines two bytes be used to
represent a char. It is also common to find modern machines,
particularly DSPs, where the machine byte is 32 bits. On such machines
it is not possible to address smaller than 32 bit values (you can
access individual octets though by masking and shifting but you cannot
address individual octets).
Based on what you said i came to the assumption that CHAR_BIT is the minimum
multiple of the number of bits in the machine byte which is equal or greater
than 8. So, given the CHAR_BIT value, one can find one or two numbers, one
of which will be the machine byte size. That means that the machine byte can
be roughly determined through C.
Hmm.. But what about a machine with 9 bit bytes where CHAR_BIT is 8
(the C compiler simply ignores the most significant bit)? I believe
that the standard doesn't allow padding bits in char but I think in
this case the most significant bit is not a padding bit, it is simply
ignored by the compiler author. In this case a string of chars will
still be contiguous from the point of view of C but you won't be able
to ever find out the size of the machine byte from C.
I'm not so sure about how conformant is such an implementation. Any
standard experts here think it's valid?
"stathis gotsis" <st***********@hotmail.com> writes:
[...] Based on what you said i came to the assumption that CHAR_BIT is the minimum
multiple of the number of bits in the machine byte which is equal or greater
than 8. So, given the CHAR_BIT value, one can find one or two numbers, one
of which will be the machine byte size. That means that the machine byte can
be roughly determined through C.
You're assuming that "the machine byte" is meaningful.
If by "the machine byte" you mean the smallest directly addressible
unit of memory, I've worked on systems with CHAR_BIT==8 where the
smallest addressible unit of memory is 64 bits. (Strictly speaking,
setting CHAR_BIT to 64 would have been more correct, but that would
have broken too much code and killed compatibility with other
systems.)
If you want to know what a "machine byte" is, look for the word "byte"
in the CPU reference manual. I don't believe any other method can
give you a reliable and meaningful answer.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
"stathis gotsis" <st***********@hotmail.com> wrote in message
news:dt***********@ulysses.noc.ntua.gr... Based on what you said i came to the assumption that CHAR_BIT is the
minimum
"minimum" is wrong here, so my mistake.
multiple of the number of bits in the machine byte which is equal or
greater than 8. So, given the CHAR_BIT value, one can find one or two numbers, one
of which will be the machine byte size. That means that the machine byte
can be roughly determined through C.
stathis gotsis wrote: "sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com... Hmm.. this is slowly getting to be off-topic in c.l.c. Anyway...
A byte does not refer to a word. A machine word in hardware does indeed
usually correspond to an int. A byte is usually defined as the smallest
addressible unit of memory for an architecture whereas a word is
usually defined as the native register size of the architecture
(whatever that means).
<snip>
Based on what you said i came to the assumption that CHAR_BIT is
the minimum multiple of the number of bits in the machine byte which
is equal or greater than 8.
No. CHAR_BIT is a C implementation construct that refers exclusively to
the C implementation on which it is defined. The underlying platform
need
not have _any_similarity in terms of 'machine bytes' or 'words'.
As Keith has pointed out, there have been hosted 8-bit byte
implementations where the only addressable unit on the underlying
archecture were 64-bit words.
There have also been 36-bit machines where it was common assembly
practice to pack 6 6-bit character entities into a word, but the C
implementations used 4 9-bit bytes.
So, given the CHAR_BIT value, one can find one or two numbers, one
of which will be the machine byte size.
No, you can't. It's likely that CHAR_BIT will match the underlying
architecture because implementations tend to promote efficiency,
but this is not guaranteed.
That means that the machine byte can be roughly determined
through C.
The fundamental issue (from clc's point of view) is that C is an
abstract
language. If you want to guage the 'machine byte' (whatever that may
mean to you), then you should abandon ISO C and use implementation
specific constructs or assumptions. [Thus reducing the portability of
your code.]
--
Peter
On 2006-02-23, sl*******@yahoo.com <sl*******@gmail.com> wrote: stathis gotsis wrote: "sl*******@yahoo.com" <sl*******@gmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com... > Hmm.. this is slowly getting to be off-topic in c.l.c. Anyway...
>
> A byte does not refer to a word. A machine word in hardware does indeed
> usually correspond to an int. A byte is usually defined as the smallest
> addressible unit of memory for an architecture whereas a word is
> usually defined as the native register size of the architecture
> (whatever that means).
>
> The smallest addressible memory may not always be 8 bits. And on
> machines where this is smaller than 8 bits (for example 6 bits was once
> very common) the C standard requires chars to be at least 8 bits. Hence
> the C standard requires that on such machines two bytes be used to
> represent a char. It is also common to find modern machines,
> particularly DSPs, where the machine byte is 32 bits. On such machines
> it is not possible to address smaller than 32 bit values (you can
> access individual octets though by masking and shifting but you cannot
> address individual octets).
Based on what you said i came to the assumption that CHAR_BIT is the minimum
multiple of the number of bits in the machine byte which is equal or greater
than 8. So, given the CHAR_BIT value, one can find one or two numbers, one
of which will be the machine byte size. That means that the machine byte can
be roughly determined through C.
Hmm.. But what about a machine with 9 bit bytes where CHAR_BIT is 8
(the C compiler simply ignores the most significant bit)? I believe
that the standard doesn't allow padding bits in char but I think in
this case the most significant bit is not a padding bit, it is simply
ignored by the compiler author. In this case a string of chars will
still be contiguous from the point of view of C but you won't be able
to ever find out the size of the machine byte from C.
If it's "ignored", it has to be consistently ignored - i.e. it is a
padding bit in both [or more] bytes in an int, and in all [at least]
four bytes in a long. And it can't be a "dangerous" padding bit [i.e. if
assignments to it as unsigned char sets or clears it, having it
set/clear can't be a trap representation of other types or vice versa].
I'm not so sure about how conformant is such an implementation. Any
standard experts here think it's valid?
If it's _impossible_ to prove in software that such a bit exists, I
suppose the implementation could be valid. I suppose one could say that
the ECC bit is a real-world example.
Michael Wojcik wrote:
8 - - -
Given that, try this code:
#include <stdio.h>
int main(void)
{
unsigned i, c;
unsigned char *bp1, *bp2;
if (sizeof i > 1)
{
i = 0;
bp1 = bp2 = (unsigned char *)&i;
bp1++; /* point to second byte */
#if 0 bp2 += sizeof i - 1; /* point to second-to-last byte */
#else
bp2 += sizeof i - 2; /* correction: point to second-to-last
byte*/
#endif for (c = 0; *bp1 == 0 && *bp2 == 0; c++)
i = 1u << c;
printf("bytes have %d bits in this implementation\n", (int)c - 1);
}
return 0;
}
This works for both big- and little-endian architectures, as far as I
can see, because it tests when the shift operator alters the second
or penultimate bytes.
Works now.
"sl*******@yahoo.com" wrote:
.... snip ...
Hmm.. But what about a machine with 9 bit bytes where CHAR_BIT is 8
(the C compiler simply ignores the most significant bit)? I believe
that the standard doesn't allow padding bits in char but I think in
this case the most significant bit is not a padding bit, it is simply
ignored by the compiler author. In this case a string of chars will
still be contiguous from the point of view of C but you won't be able
to ever find out the size of the machine byte from C.
I'm not so sure about how conformant is such an implementation. Any
standard experts here think it's valid?
You are talking about machines with parity memory, for example.
ECC memory machines just organize things somewhat differently, but
can be built around parity memory. However parity memory cannot
necessarily be built from ECC modules.
--
"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/>
On 2006-02-22, Rod Pemberton <do*********@sorry.bitbucket.cmm> wrote:
#include <stdio.h>
int main(void)
{
unsigned short i,j;
/* i and j must be the same type needed */
/*
unsigned long i,j;
char i,j;
*/
unsigned short k;
for(i=1,j=0,k=0;i!=j;k++,j=i,i<<=1);
k--;
printf("\nbits %d\n",k);
return(0);
}
How is this superior to the previous bit shifting example?
e.g
int numbits=1; /* assuming c unsigned */
while(c<<=1)
numBits++
"Richard G. Riley" <rg***********@gmail.com> wrote in message
news:46************@individual.net... On 2006-02-22, Rod Pemberton <do*********@sorry.bitbucket.cmm> wrote:
#include <stdio.h>
int main(void)
{
unsigned short i,j;
/* i and j must be the same type needed */
/*
unsigned long i,j;
char i,j;
*/
unsigned short k;
for(i=1,j=0,k=0;i!=j;k++,j=i,i<<=1);
k--;
printf("\nbits %d\n",k);
return(0);
}
How is this superior to the previous bit shifting example?
I never said it was. There are probably a thousand ways to do this. Some,
I'm sure, are much better than mine. Mine does fix one potential error
though. The first example assumes the the data will wrap to zero (0) when
the bit shift overflows. This may not be the case. Mine just checks for
equality. If the bit size of the register or memory location is larger than
the CHAR_BIT size, the first example will fail. Also, certain CPUs don't
have bit shifts but have bit rotates. If this is the case and the compiler
uses them to emulate bit shifts, the first example might fail too.
Rod Pemberton
Rod Pemberton wrote: ...
An alternate method that should work for ones and twos complement integers:
#include <stdio.h>
int main(void)
{
unsigned short i,j;
/* i and j must be the same type needed */
/*
unsigned long i,j;
char i,j;
*/
unsigned short k;
for(i=1,j=0,k=0;i!=j;k++,j=i,i<<=1);
k--;
printf("\nbits %d\n",k);
return(0);
}
...
On a pedantic side, all these methods attempt to calculate the bit-size of
_value_ _representation_ of certain type, which (theoretically) could be less
than the bit-size of its _object_ _representation_, because the latter might
include extra padding bits. It applies to all types except '[signed/unsigned]
char'.
I don't know which representation the OP was interested in, but in case of a
"byte" it doesn't really matter, since "byte" is synonymous with 'char' type in
standard C terminology.
Once you start dealing with "larger" types (as is the case in your code), the
ambiguity immediately presents itself.
--
Best regards,
Andrey Tarasevich
Michael Wojcik wrote: ... So, given that it can't strictly be done in C
I don't think this is true. Consider that:
- integers must have a pure binary representation, which means
value bits are in order
What order? At the language level the "bit" and the "order of bits" are just
concepts. The only way to interact with "bits" and analyze their "order" is to
use bitwise or shift operators, which are also language-level constructs. There
are absolutely no requirement for the language-level "order of bits" to be in
any agreement with machine-level order of bits. Moreover, there is no
requirement for the machine to even have binary "bits". The machine itself might
be ternary. This still does not prevent the implementation from using the "pure
binary representation" (as seen by bitwise and shift operators) for representing
integers.
- you can inspect the representation of any object using a
pointer to unsigned char
You will only see the language-level representation of the type 'unsigned
char', which, in general case, has absolutely nothing to to with the
machine-level details.
Given that, try this code:
#include <stdio.h>
int main(void)
{
unsigned i, c;
unsigned char *bp1, *bp2;
if (sizeof i > 1)
{
i = 0;
bp1 = bp2 = (unsigned char *)&i;
bp1++; /* point to second byte */
bp2 += sizeof i - 1; /* point to second-to-last byte */
for (c = 0; *bp1 == 0 && *bp2 == 0; c++)
i = 1u << c;
printf("bytes have %d bits in this implementation\n", (int)c - 1);
}
return 0;
}
This works for both big- and little-endian architectures, as far as I
can see, because it tests when the shift operator alters the second
or penultimate bytes. I don't offhand see a way for a conforming
implementation (where sizeof(unsigned) > 1) to produce the wrong
answer.
...
This might work "in most (or all) cases" in practice, but it is still not
something with language-guaranteed behavior. Object 'i' is allowed to contain
padding bits, which might happen to occupy both bytes you are trying to analyze
in the above code and might happen to stay 0 for all legal values of 'i'. I.e
any attempts to modify 'i' might never change the bytes in question, thus
resulting in never-ending cycle. This is unlikely in practice, but perfectly
legal from the language point of view.
--
Best regards,
Andrey Tarasevich
In article <11**********************@z14g2000cwz.googlegroups .com>, vy****@gmail.com writes: Michael Wojcik wrote:
bp2 += sizeof i - 1; /* point to second-to-last byte */
bp2 += sizeof i - 2; /* correction: point to second-to-last byte*/
Be nice if I could count, eh? Thanks for the correction.
--
Michael Wojcik mi************@microfocus.com
In article <43***********@mindspring.com>, pete <pf*****@mindspring.com> writes:
[To determine the number of bits in a byte:]
Define an unsigned char with a value of -1,
and count the right shifts until zero.
Heh. That's a lot simpler than my method. I was so busy trying to
portably handle overflowing left shifts I didn't even consider right
shifts.
--
Michael Wojcik mi************@microfocus.com
Vladimir S. Oka 写道： david ullua wrote: Hi, Rod,
Thanks for your reply. Martin and Vladimir have given a solution to
find bit size of byte. Maybe Joe was not intended to get such anwser
from interviewee, it is still an efficient way :).
I wander whether there exists such case when we don't know the bit size
of byte in a machine but we need to calculate it in programming
language? It's just like kidding, since we don't know bytesize in the
machine, how could we know which programming lanugage would work on it?
Oh, alright...
#include <limits.h>
int bytesize = 1 * CHAR_BIT;
Does this qualify as calculation?
If you have a compliant Standard C implementation this has to work, and
it won't fail you.
There are batter ways of testing algorithmic skills in an interview
than contriving something like this.
PS
Please quote what you're replying to. Many people can't see the whole
thread.
"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/>
--
BR, Vladimir
Hi,Vladimir, Thanks for your PS. I would never do that again.
Default User 写道： david ullua wrote:
Thanks for both of your reply.
Both who? See below.
Brian
--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.
De, ...hmmm, could I address you "Default User"?
I give my thanks to both Vladimir and Martin.
Your signature(?) is short and clear, Thank you!
Emmanuel Delahaye 写道： david ullua a écrit : Thanks for both of your reply.
I take a look at limits.h and other head files, there is really
something need to be read.
/Your/ C-book needs to be read from cover to cover. every 6 month.
--
C is a sharp tool
good idea, it's time to learn it again.
Hi, everyone, thanks for all of your passionate reply. Since i am a
green hand here, lots of people tell me how to reply. I am terribly
sorry that I didn't see and those remarks until today cause busy the
job.
It's a better group than any group I've ever joined. There are so many
smart and learned here.
Hope everyone would enjoy it :)
david ullua wrote: It's a better group than any group I've ever joined.
Believe it or not,
it's largely due to the fact that
we gang up and mob off topic posters.
--
pete
On 2006-02-24, pete <pf*****@mindspring.com> wrote: david ullua wrote:
It's a better group than any group I've ever joined.
Believe it or not,
it's largely due to the fact that
we gang up and mob off topic posters.
Hilarious...
--
Remove evomer to reply
david ullua wrote:
Default User 写道：
Brian
De, ...hmmm, could I address you "Default User"?
What do you think?
I give my thanks to both Vladimir and Martin.
Your signature(?) is short and clear, Thank you!
You're welcome.
Brian
pete wrote: david ullua wrote:
It's a better group than any group I've ever joined.
Believe it or not,
it's largely due to the fact that
we gang up and mob off topic posters.
Is that why we do it? I thought it was because we were evil control
freaks who hate newbies and outsiders.
Brian
Default User wrote: pete wrote: david ullua wrote:
It's a better group than any group I've ever joined.
Believe it or not, it's largely due to the fact that
we gang up and mob off topic posters.
Is that why we do it? I thought it was because we were evil
control freaks who hate newbies and outsiders.
Don't forget the inner satisfaction gained by restricting knowledge
from the unwashed. Oooh, it's positively orgasmic.
--
"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/>
"Default User" <de***********@yahoo.com> wrote in message
news:46************@individual.net... Is that why we do it? I thought it was because we were evil control
freaks who hate newbies and outsiders.
Hey, I'm a newbie, and I don't feel hated. You guys must be slacking off.
heheh.
--
MrG{DRGN}
I thought your reply was generated automatically, when someone didn't
quote other's word to reply, the system post a reply to remind. hahaha
Default User 写道： david ullua wrote:
Default User 写道：
Brian
De, ...hmmm, could I address you "Default User"?
What do you think?
I give my thanks to both Vladimir and Martin.
Your signature(?) is short and clear, Thank you!
You're welcome.
Brian
david ullua wrote: I thought your reply was generated automatically, when someone didn't
quote other's word to reply, the system post a reply to remind. hahaha
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See almost every other message on the
newsgroup.
Brian
On 2006-02-27, Default User <de***********@yahoo.com> wrote: david ullua wrote:
I thought your reply was generated automatically, when someone didn't
quote other's word to reply, the system post a reply to remind. hahaha
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See almost every other message on the
newsgroup.
Brian
I suspect that you are a very good C programmer : either that or
looking for guidance or help in this NG. Nothing wrong there.
Tiring of repeatedly seeing OLD posts reignited because the likes of
you reply yet another damn "etiquette" guide, I had a quick look at
google. http://tinyurl.com/ekv6p
Interestingly it would appear that the only thing you do is post
reprimands or repeat the bleeding obvious.
How about a compromise? If the post is less than a day old OR noone
got there before you, THEN post your little guidelines.
--
Remove evomer to reply
On 27 Feb 2006 17:47:34 GMT, in comp.lang.c , "Richard G. Riley"
<rg****@gmail.com> wrote: Tiring of repeatedly seeing OLD posts reignited because the likes of
you reply yet another damn "etiquette" guide,
you can always killfile him. It'd be your loss, not his. :-)
I had a quick look at google.
http://tinyurl.com/ekv6p
Google may be great, but it doesn't archive everything.
How about a compromise? If the post is less than a day old OR noone
got there before you, THEN post your little guidelines.
I think you need to remember that usenet is NOT a synchronous
mechanism., There's no way to know if someone "got there before you",
since you may see their post already, but the OP may never see it, or
vice-versa.
Its trickier than you think.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
CBFalconer <cb********@yahoo.com> wrote: Default User wrote: pete wrote: david ullua wrote:
It's a better group than any group I've ever joined.
Believe it or not, it's largely due to the fact that
we gang up and mob off topic posters.
Is that why we do it? I thought it was because we were evil
control freaks who hate newbies and outsiders.
Don't forget the inner satisfaction gained by restricting knowledge
from the unwashed. Oooh, it's positively orgasmic.
Personally, I've always done it because it makes my diminutive coding
skills look better than those of the newbie with four decades of C
experience.
Richard
On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote: unsigned i, c;
unsigned char *bp1, *bp2;
i = 0;
bp1 = bp2 = (unsigned char *)&i;
bp1++; /* point to second byte */
bp2 += sizeof i - 1; /* point to second-to-last byte */
for (c = 0; *bp1 == 0 && *bp2 == 0; c++)
i = 1u << c;
This works for both big- and little-endian architectures, as far as I
can see, because it tests when the shift operator alters the second
or penultimate bytes. I don't offhand see a way for a conforming
implementation (where sizeof(unsigned) > 1) to produce the wrong
answer.
PDP-11 "middle-endian" (hi.lo, hi.hi, lo.lo, lo.hi) gives 0.
Although it could conform only to C90 because it couldn't support a
single 64K-1B object together with an invocation of main(). <G>
Extending the program to handle the case where sizeof(unsigned) is 1
is left as an exercise for the reader.
Shifting or otherwise popcounting (unsigned char)-1 is more reliable
and simpler/clearer to boot.
- David.Thompson1 at worldnet.att.net
On 2006-03-03, Dave Thompson <da*************@worldnet.att.net> wrote: On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
unsigned i, c;
unsigned char *bp1, *bp2;
Why not just use CHAR_BITS from limits.h?
Just asking
8-)
Charles Krug schrieb: On 2006-03-03, Dave Thompson <da*************@worldnet.att.net> wrote:
On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
unsigned i, c;
unsigned char *bp1, *bp2;
Why not just use CHAR_BITS from limits.h?
Just asking
8-)
What are you referring to? The context provided is insufficient.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Charles Krug said: On 2006-03-03, Dave Thompson <da*************@worldnet.att.net> wrote: On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
unsigned i, c;
unsigned char *bp1, *bp2;
Why not just use CHAR_BITS from limits.h?
No such animal. Care to try again?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
On 2006-03-04, Michael Mair <Mi**********@invalid.invalid> wrote: Charles Krug schrieb: On 2006-03-03, Dave Thompson <da*************@worldnet.att.net> wrote:
On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
unsigned i, c;
unsigned char *bp1, *bp2;
Why not just use CHAR_BITS from limits.h?
Just asking
8-)
What are you referring to? The context provided is insufficient.
The OP wanted bits per byte. C defines (freely speaking) char to be
"one byte" (IANALL).
So CHAR_BIT is the number of bits in a byte.
IANALL, not valid in Vermont, Puerto Rico, the US Virgin Islands, or
where prohibited by ARINC 653
On 2006-03-04, Richard Heathfield <in*****@invalid.invalid> wrote: Charles Krug said:
On 2006-03-03, Dave Thompson <da*************@worldnet.att.net> wrote: On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
unsigned i, c;
unsigned char *bp1, *bp2;
Why not just use CHAR_BITS from limits.h?
No such animal. Care to try again?
Is CHAR_BIT not what the OP is after?
I'm not aware that C offers us any other definition for "byte", though
IANALL.
I'm fairly certain that the difficulties inherent in transferring data
from a TI 'c40 to a PPC 704 over VMEBus (each has a distinct idea of the
size of a "byte") are OT.
Charles Krug <cd****@aol.com> writes: On 2006-03-04, Michael Mair <Mi**********@invalid.invalid> wrote: Charles Krug schrieb: On 2006-03-03, Dave Thompson <da*************@worldnet.att.net> wrote:
On 22 Feb 2006 02:30:54 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
> unsigned i, c;
> unsigned char *bp1, *bp2;
Why not just use CHAR_BITS from limits.h?
Just asking
8-)
What are you referring to? The context provided is insufficient.
The OP wanted bits per byte. C defines (freely speaking) char to be
"one byte" (IANALL).
So CHAR_BIT is the number of bits in a byte.
Yes, CHAR_BIT is by definition the number of bits in a byte, which is
exactly what the OP was asking about. The thread wandered into a
discussion of how to compute CHAR_BIT without actually using the
CHAR_BIT macro. There are several ways to do this, none of them
useful if CHAR_BIT is available, but it's an interesting exercise.
(It could also be useful in the unlikely event that CHAR_BIT is
defined incorrectly; this could possibly happen if the compiler and
<limits.h> are out of sync.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On 2006-03-04, Charles Krug <cd****@aol.com> wrote: The OP wanted bits per byte. C defines (freely speaking) char to be
"one byte" (IANALL).
Out of curiosity, what is IANALL supposed to disclaim? How does one
become qualified as such?
Jordan Abel said: On 2006-03-04, Charles Krug <cd****@aol.com> wrote: The OP wanted bits per byte. C defines (freely speaking) char to be
"one byte" (IANALL).
Out of curiosity, what is IANALL supposed to disclaim?
I Am Not A Language Lawyer.
How does one become qualified as such?
By being a language-lawyer-in-training (because it is invariably used with
an implied "but...").
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Charles Krug said: On 2006-03-04, Richard Heathfield <in*****@invalid.invalid> wrote: Charles Krug said:
Why not just use CHAR_BITS from limits.h?
No such animal. Care to try again?
Is CHAR_BIT not what the OP is after?
Yes. No S.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
On 2006-03-05, Richard Heathfield <in*****@invalid.invalid> wrote: Jordan Abel said:
On 2006-03-04, Charles Krug <cd****@aol.com> wrote: The OP wanted bits per byte. C defines (freely speaking) char to be
"one byte" (IANALL).
Out of curiosity, what is IANALL supposed to disclaim?
I Am Not A Language Lawyer.
How does one become qualified as such?
By being a language-lawyer-in-training (because it is invariably used with
an implied "but...").
Around here, I use to disclaim my lack of accuracy.
In this case I saw someone who thought it might be useful to have a sort
of "roundish" thing that he could use to roll things around, and I was
trying to point out the prefectly good wheel over in the corner.
(freely speaking) and IANALL in this case 'cuz I wasn't giving the
precise definition of a byte--please don't use what I say to write your
own compiler--but something Good Enough for many purposes, including IMO
the issue at hand.
On 2006-03-05, Richard Heathfield <in*****@invalid.invalid> wrote: Charles Krug said:
On 2006-03-04, Richard Heathfield <in*****@invalid.invalid> wrote: Charles Krug said:
Why not just use CHAR_BITS from limits.h?
No such animal. Care to try again?
Is CHAR_BIT not what the OP is after?
Yes. No S.
Gotta get that tire fixed. It's hissing. This thread has been closed and replies have been disabled. Please start a new discussion. |
