This is a discussion on Re: bit operation within the Linux Networking forums, part of the Linux Forums category; Hi, The reason I was having that problem is that char wraps around itself beyond -126 to 127. So, the ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
On Mon, 16 Feb 2004, Marcia Hon wrote in comp.lang.c: > > Hi, > > The reason I was having that problem is that char wraps around itself > beyond -126 to 127. So, the bits were wrapped around. > > thanks, > Marcia You have [probably serendipitously] hit upon an excellent way to get a whole bunch of people annoyed at you: Post a random and almost certainly wrong observation, with no context, to three different Usenet newsgroups. Don't do this. If you have a question, post it to the most appropriate group. If you have an observation, post a *complete* thought (including antecedents for all your "this"es and "that"s) to the most appropriate group. But don't assume that people in the Big World Outside Your Room [tm] have an instantaneous grasp of whatever it was you were thinking when you typed your message. We don't know [and frankly I don't care] what "that problem" was to which you refer. However, I *do* know that the values of 'char' in the C programming language *do not* and *cannot* wrap from -126 to 127. So either you're mistaken, or you are programming in some really funky language that's not topical in this newsgroup. HTH, -Arthur |
|
|||
|
In article <_FYXb.72$kaP1.26@news04.bloor.is.net.cable.rogers .com>,
"Marcia Hon" <honm@rogers.com> wrote: > The reason I was having that problem First, what problem were you having? > is that char wraps around itself beyond -126 to 127. No, the char type in C is not allowed to do that. If the char type can represent any negative values at all (i.e. it is not unsigned) then it must be able to represent the number -127, so it cannot wrap at -126, if it does so, then your compiler is broken. > So, the bits were wrapped around. Whatever that means. Also, whatever your problem was, I find it hard to believe that it could have been relevant to comp.lang.c, comp.os.linux.networking *and* comp.unix.programmer. |
|
|||
|
In comp.os.linux.networking Marcia Hon <honm@rogers.com> wrote:
> The reason I was having that problem is that char wraps around itself > beyond -126 to 127. So, the bits were wrapped around. No, this is not so. char is signed. I imagine you did printf("%x", (int)mychar); which will do a signed extension of mychar to an int. Since mychar = 141 has the sign bit set (it is -115, I suppose, or 0x8d), it will be turned into a 32-bit integer by repeating the sign bit to the left in the extension, giving you 0xffffff8d. Peter |
|
|||
|
Followup-To: comp.lang.c since this part of the thread discusses the
C language. ptb@oboe.it.uc3m.es (P.T. Breuer) writes: > In comp.os.linux.networking Marcia Hon <honm@rogers.com> wrote: >> The reason I was having that problem is that char wraps around itself >> beyond -126 to 127. So, the bits were wrapped around. > > No, this is not so. char is signed. No, `char' can be either a signed or an unsigned type. > I imagine you did > > printf("%x", (int)mychar); If `mychar' has type `char', the cast is superfluous, since a `char' argument is promoted to `int' anyway. (Except on systems where `char' is unsigned and `sizeof(unsigned int)' is equal to 1, where it is promoted to `unsigned int'.) An `int' argument is an error here, since `%x' expects an `unsigned int' argument. > which will do a signed extension of mychar to an int. Since mychar = > 141 has the sign bit set (it is -115, I suppose, or 0x8d), it will be > turned into a 32-bit integer by repeating the sign bit to the left in > the extension, giving you 0xffffff8d. It will be promoted to `int', not necessarily a 32-bit integer, unless `int' happens to be a 32-bit integer on the platform in question. Martin |
|
|||
|
Marcia Hon wrote:
> > The reason I was having that problem is that char wraps around > itself beyond -126 to 127. So, the bits were wrapped around. Another pointless new thread foolishly cross-posted. The time has come to PLONK. So even if you learn to post sanely, you will not be seen here. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address! |
|
|||
|
In article <clarkcox3-CD9761.02063417022004@localhost>,
Clark Cox <clarkcox3@mac.com> wrote: > In article <_FYXb.72$kaP1.26@news04.bloor.is.net.cable.rogers .com>, > "Marcia Hon" <honm@rogers.com> wrote: > > > The reason I was having that problem > > First, what problem were you having? I think he's referring to the problem he described in a different thread, titled "Bit operation not working". It was only cross-posted to comp.os.linux.networking (I'm guessing because his bit-twiddling is part of implementing a network protocol) and comp.unix.programmer, so if you're seeing this pseudo-followup in comp.lang.c it's understandable that you wouldn't know what the heck he's talking about. To the OP -- if you're following up on a posting, use your newsreader's Reply/Followup command, don't start a new thread. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** |
|
|||
|
In comp.os.linux.networking Martin Dickopp <expires-2004-03-31@zero-based.org> wrote:
> Followup-To: comp.lang.c since this part of the thread discusses the C language. Oh, jump in lake. > ptb@oboe.it.uc3m.es (P.T. Breuer) writes: > > In comp.os.linux.networking Marcia Hon <honm@rogers.com> wrote: > >> The reason I was having that problem is that char wraps around itself > >> beyond -126 to 127. So, the bits were wrapped around. > > > > No, this is not so. char is signed. > > No, `char' can be either a signed or an unsigned type. Oh, shut up! I said IS, not "can be". I know perfectly well what it can and can not be, and it IS signed, which is why I said it. When you learn to distinguish between concrete and generic instantiation, I will be happy. That IS a bus stop, OK? Yes, I know, it CAN BE a taxi stand also, but it IS a bus stop. OK? Now just retreat, desist, stop, go away. > > I imagine you did > > > > printf("%x", (int)mychar); > > If `mychar' has type `char', the cast is superfluous, The cast is "superfluous" in that it will be promoted to int anyway, but that is why I added the explicit cast! In order to make it plain what it was (which is what I said it was). Why else would I say what I said? Plese stop this. I didn't believe in idiots this big before now. > since a `char' > argument is promoted to `int' anyway. Oh, hooo hooo. We are quick, aren't we? > (Except on systems where `char' > is unsigned and `sizeof(unsigned int)' is equal to 1, Yeah, I suppose like wow you really know how to program those ancient smart cards with the 256 word address space. > where it is > promoted to `unsigned int'.) Out of a mild but morbid interest, how the heck do you calculate that? If char is unsigned then it will be promoted to (unsigned) int FULL STOP, never mind how big an int is. > An `int' argument is an error here, since `%x' expects an `unsigned int' > argument. That doesn't matter - it's the same size, and is not an "error" (yes, I do know the difference between a compiler advisory and an "error"). Please come up to speed with the rest of the class, Einstein. > > which will do a signed extension of mychar to an int. Since mychar = > > 141 has the sign bit set (it is -115, I suppose, or 0x8d), it will be > > turned into a 32-bit integer by repeating the sign bit to the left in > > the extension, giving you 0xffffff8d. > > It will be promoted to `int', not necessarily a 32-bit integer, YES, "necessarily" a 32 bit integer, since that is what it IS. Get it? It happened - we are talking about the universe, real life, your tea pot. Learn to DISTINGUISH, fer crissakes, before you get murdered by a passing midget with a filed skateboard. > unless > `int' happens to be a 32-bit integer on the platform in question. The platform in question does have 32 bit integers. We know that. Why do we know that? Put your hand up. Yes ... OK, you at the back! yes, that's right, yes, .. because "0xffffff8d" was the value PRINTED. > Martin No. You mean "nit ram". It's bigendian. kindly get it right, and then crawl back deep underground. Come back when you mutter things that are not complete piffle that demonstrate only that you are unaware of what is being talked about. Look at what was said, do not imagine it. Yes, I am aware that you think you are giving a wonderful lesson on the possible implementations of C, and you are wrong. You are instead demonstrating that you cannot observe the data provided and deduce the way things ARE. P |
|
|||
|
In article <9ut01c.d1q.ln@news.it.uc3m.es>, ptb@notme.com (P.T.B)
wrote: > In comp.os.linux.networking Martin Dickopp > <expires-2004-03-31@zero-based.org> wrote: > > Followup-To: comp.lang.c since this part of the thread discusses the C > > language. > > > ptb@oboe.it.uc3m.es (P.T. Breuer) writes: > > > In comp.os.linux.networking Marcia Hon <honm@rogers.com> wrote: > > >> The reason I was having that problem is that char wraps around itself > > >> beyond -126 to 127. So, the bits were wrapped around. > > > > > > No, this is not so. char is signed. > > > > No, `char' can be either a signed or an unsigned type. > > Oh, shut up! I said IS, not "can be". You said 'char is signed', not 'char is signed on my platform', there is a difference. [snip] > > > I imagine you did > > > > > > printf("%x", (int)mychar); > > > > If `mychar' has type `char', the cast is superfluous, > > The cast is "superfluous" in that it will be promoted to int anyway, > but that is why I added the explicit cast! You added an explicit cast to make sure that something that happens automatically would happen? That doesn't make much sense. > > (Except on systems where `char' > > is unsigned and `sizeof(unsigned int)' is equal to 1, > > Yeah, I suppose like wow you really know how to program those ancient > smart cards with the 256 word address space. What does a 256 word address space have to do with sizeof(unsigned int) equaling 1? > > where it is > > promoted to `unsigned int'.) > > Out of a mild but morbid interest, how the heck do you calculate that? > If char is unsigned then it will be promoted to (unsigned) int FULL > STOP, never mind how big an int is. Not true, take the following implementation for instance: char is an unsigned type sizeof(int) == 4 sizeof(unsigned) == 4 char will be promoted to int, as int is capable of representing the entire range of char, however, if sizeof(int) == 1, int will not be sufficent to represent the entire range, and char will therefore be promoted to unsigned int. > > An `int' argument is an error here, since `%x' expects an `unsigned int' > > argument. > > That doesn't matter - it's the same size, It doesn't matter if it's the same size or not, it's undefined behavior. > and is not an "error" (yes, I > do know the difference between a compiler advisory and an "error"). > Please come up to speed with the rest of the class, Einstein. > > > > which will do a signed extension of mychar to an int. Since mychar = > > > 141 has the sign bit set (it is -115, I suppose, or 0x8d), it will be > > > turned into a 32-bit integer by repeating the sign bit to the left in > > > the extension, giving you 0xffffff8d. > > > > It will be promoted to `int', not necessarily a 32-bit integer, > > YES, "necessarily" a 32 bit integer, since that is what it IS. No, int can be as small as 16-bits, or as large as 'long int'. |
|
|||
|
"P.T.B" wrote:
> In comp.os.linux.networking Martin Dickopp <expires-2004-03-31@zero-based.org> wrote: > > Followup-To: comp.lang.c since this part of the thread discusses the C language. > > Oh, jump in lake. > > > ptb@oboe.it.uc3m.es (P.T. Breuer) writes: > > > In comp.os.linux.networking Marcia Hon <honm@rogers.com> wrote: > > >> The reason I was having that problem is that char wraps around itself > > >> beyond -126 to 127. So, the bits were wrapped around. > > > > > > No, this is not so. char is signed. > > > > No, `char' can be either a signed or an unsigned type. > > Oh, shut up! I said IS, not "can be". I know perfectly well what it > can and can not be, and it IS signed, which is why I said it. When you > learn to distinguish between concrete and generic instantiation, I will > be happy. That IS a bus stop, OK? Yes, I know, it CAN BE a taxi stand > also, but it IS a bus stop. OK? Now just retreat, desist, stop, go > away. char may be signed or unsigned. You have no way of knowing except for a particular installation. c.l.c does not deal with particular installations, it deals with all of them in a fully portable manner. Your appearance here is doubtless the result of the OPs foul cross-posting, so please retreat to where you came from and remove c.l.c from any replies. I have attempted to assist in that. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address! |