Re: bit operation

Discussion in 'C Programming' started by Marcia Hon, Feb 16, 2004.

  1. Marcia Hon

    Marcia Hon Guest

    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
    Marcia Hon, Feb 16, 2004
    #1
    1. Advertising

  2. [OT] Re: bit operation

    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
    Arthur J. O'Dwyer, Feb 17, 2004
    #2
    1. Advertising

  3. Marcia Hon

    Clark Cox Guest

    In article <_FYXb.72$>,
    "Marcia Hon" <> 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.
    Clark Cox, Feb 17, 2004
    #3
  4. Marcia Hon

    P.T. Breuer Guest

    In comp.os.linux.networking 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.


    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
    P.T. Breuer, Feb 17, 2004
    #4
  5. Followup-To: comp.lang.c since this part of the thread discusses the
    C language.

    3m.es (P.T. Breuer) writes:
    > In comp.os.linux.networking 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.

    >
    > 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
    Martin Dickopp, Feb 17, 2004
    #5
  6. Marcia Hon

    CBFalconer Guest

    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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 17, 2004
    #6
  7. In article <clarkcox3-CD9761.02063417022004@localhost>,
    Clark Cox <> wrote:

    > In article <_FYXb.72$>,
    > "Marcia Hon" <> 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,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Margolin, Feb 17, 2004
    #7
  8. Marcia Hon

    P.T.B Guest

    In comp.os.linux.networking Martin Dickopp <> wrote:
    > Followup-To: comp.lang.c since this part of the thread discusses the C language.


    Oh, jump in lake.

    > 3m.es (P.T. Breuer) writes:
    > > In comp.os.linux.networking 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.

    > >
    > > 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
    P.T.B, Feb 18, 2004
    #8
  9. Marcia Hon

    Clark Cox Guest

    In article <3m.es>, (P.T.B)
    wrote:

    > In comp.os.linux.networking Martin Dickopp
    > <> wrote:
    > > Followup-To: comp.lang.c since this part of the thread discusses the C
    > > language.

    >
    > > 3m.es (P.T. Breuer) writes:
    > > > In comp.os.linux.networking 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.
    > > >
    > > > 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'.
    Clark Cox, Feb 19, 2004
    #9
  10. Marcia Hon

    CBFalconer Guest

    "P.T.B" wrote:
    > In comp.os.linux.networking Martin Dickopp <> wrote:
    > > Followup-To: comp.lang.c since this part of the thread discusses the C language.

    >
    > Oh, jump in lake.
    >
    > > 3m.es (P.T. Breuer) writes:
    > > > In comp.os.linux.networking 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.
    > > >
    > > > 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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 19, 2004
    #10
  11. In article <clarkcox3-28AF68.20294318022004@localhost>,
    Clark Cox <> wrote:

    > In article <3m.es>, (P.T.B)
    > wrote:
    >
    > > In comp.os.linux.networking Martin Dickopp
    > > <> wrote:
    > > > Followup-To: comp.lang.c since this part of the thread discusses the C
    > > > language.

    > >
    > > > 3m.es (P.T. Breuer) writes:
    > > > > In comp.os.linux.networking 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.
    > > > >
    > > > > 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.


    Not on his platform, on the OP's platform, which explains the behavior
    that the OP saw.

    If someone asks why they got wet when they went outside, you might say
    "because it's raining". You wouldn't be claiming that it's raining
    everywhere, just in the place relevant to the question.

    Yes, he could have been more precise and said "char is signed on your
    system". But leaving out details that don't seem to be relevant in a
    particular context (and might confuse more than enlighten) is not the
    same as being wrong.

    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Margolin, Feb 19, 2004
    #11
  12. Marcia Hon

    P.T. Breuer Guest

    In comp.os.linux.networking Clark Cox <> wrote:
    > In article <3m.es>, (P.T.B)
    > wrote:
    >
    > > In comp.os.linux.networking Martin Dickopp
    > > <> wrote:
    > > > Followup-To: comp.lang.c since this part of the thread discusses the C
    > > > language.

    > >
    > > > 3m.es (P.T. Breuer) writes:
    > > > > In comp.os.linux.networking 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.
    > > > >
    > > > > 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


    I saud char IS signed, and I am not talking about MY platform, but
    about THE platform that is the subject of this thread. Now GO AWAY!


    > is a difference.


    There is no difference, since (a) we are not talking about MY platform,
    (b) we are talking about A particular platform, one which you seem not
    to have anything relevant to contribute about. Now GO AWAY.

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


    NO you natwad, I added an explictit cast to make what the compiler does
    mplicitly EXPLICT!!!!!! Is it so hard for your noggin to absorb the
    concept of EXPLANATION, even though my post consisted of nothing BUT?
    GO AWAY!

    > > > (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?


    Perhaps you'll tell me the size of long on your platform, and then we'll
    know.


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


    You are saying that that the char 255 will be promoted not to int
    but to an unsigned int of value 255? Which of course
    is -1 when read as an int (since ints are 8 bit in your scheme)?

    Pinch me. Tell me the difference.


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


    It's perfectly well defined, since the receiving function is in in
    another compilation unit and doesn't know whether the (to it) remote
    compiler thinks the 4byte unit it just passed is signed or unsigned.
    And the (to us) local compiler doesn't know what the (to it) remote
    function expects, since it's a varargs type and interpretation is
    dynamic (and remote). It contracts only to put the stuff on the stack.

    > > 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'.


    Oh GO AWAY!!!!!! Int IS 32 bits, on THE PLATFORM BEING DISCUSSED! That
    is why we are talking in this funny way! Do you get it yet?

    Peter
    P.T. Breuer, Feb 19, 2004
    #12
  13. Marcia Hon

    pete Guest

    P.T. Breuer wrote:
    > In comp.os.linux.networking Clark Cox <> wrote:
    > > In article <3m.es>,
    > > (P.T.B) wrote:


    > > > 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:


    > You are saying that that the char 255 will be promoted not to int
    > but to an unsigned int of value 255?


    He's saying that what char gets promoted to, depends entirely
    on whether or not int can represent all of the values of char.
    If CHAR_MAX is greater than INT_MAX, then it can't, otherwise, it can.

    > Which of course
    > is -1 when read as an int (since ints are 8 bit in your scheme)?


    C allows for bytes which have more than 8 bits.
    CHAR_BIT in limits.h, tells how many bits are in a byte.
    There aren't any macros in the standard library which are identical
    on all systems.

    >
    > Pinch me. Tell me the difference.
    >
    > > > > 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.

    >
    > It's perfectly well defined, since the receiving function is in in
    > another compilation unit and doesn't know whether the (to it) remote
    > compiler thinks the 4byte unit it just passed is signed or unsigned.


    The undefined behavior comes from the standard
    saying that it is undefined.
    It doesn't matter if you can't figure a way for the machine
    to get it wrong.
    The standard says that if you have the wrong type for the specifier,
    then you have undefined behavior.

    --
    pete
    pete, Feb 19, 2004
    #13
  14. Marcia Hon

    Old Wolf Guest

    > > 3m.es (P.T. Breuer) writes:
    > > > In comp.os.linux.networking 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.
    > > >
    > > > 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.


    When posting in comp.lang.c you should talk about generic
    implementations. If not, then don't post here.
    Your statement "char is signed." looks much more like
    "char is always signed" (a common misconception) than
    "char is signed on your platform", to me anyway
    (and probably to the OP).

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


    To be consistent, you should have written:
    (int (*)(const char *, ...))printf((const char *)"%x", (int)mychar);

    > > (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.


    256 word address space has nothing to do with the number of bits
    in an int, and even less to do with sizeof(unsigned int).
    FYI, ints (signed or unsigned) must have at least 16 bits.

    Also, systems with sizeof(unsigned int) == 1 are not that
    uncommon, for example some CPUs for embedded devices cannot
    work with anything other than 32 bits (so they have 32-bit chars).

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


    Actually it gets promoted to signed int (except for implementations
    where this is not always possible -- namely, those with
    sizeof(int) == 1)
    Old Wolf, Feb 19, 2004
    #14
  15. Marcia Hon

    P.T. Breuer Guest

    In comp.os.linux.networking Old Wolf <> wrote:
    > > > 3m.es (P.T. Breuer) writes:
    > > > > In comp.os.linux.networking 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.
    > > > >
    > > > > 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.

    >
    > When posting in comp.lang.c you should talk about generic


    I don't know where you are talking, nor do I care. But I wish you would
    stop.

    > implementations. If not, then don't post here.


    I am not talking about generic implementations, I am answering a
    question. The OP asked why something was so and offered a false
    explanation. I corrected the explanation, telling her what she is
    seeing. You can read it for yourself above in your own quote!

    > Your statement "char is signed." looks much more like


    It is not a statement. It is an explanation. Read it as such.

    > "char is always signed" (a common misconception) than


    I did not say that, and I am not responsible for your misconceptions,
    and I wish you would keep both them and your imaginative
    misinterpretations to yourself.

    > "char is signed on your platform", to me anyway
    > (and probably to the OP).


    The OP doesn't know a thing about "platforms", except possibly that they
    often break when walking rapidly. Kindly do not confuse it. If it knew
    what it were doing it would not offer such absurd non-theories as to
    what is going on. The explanation it wants IS that its char IS a signed
    quantity and that it IS promoted to a (signed) int when passed to the
    printf routine that prints it out, thus extending the sign bit left,
    effctively "filling out" the space to left with fffff. It did have some
    crackpot theory about chars really being full of fffs as far as I can
    make out.

    Note my capitalization of IS, and go take a deep cold long shower.


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

    >
    > To be consistent, you should have written:
    > (int (*)(const char *, ...))printf((const char *)"%x", (int)mychar);



    To be consistent you should go shoot yourself. In what way is the type
    of the other elements here an issue? That's right, it isn't. Therefore
    "to be consistent" I should come over and break this ruler over your
    head until you stop behaving like a pratty schoolboy. Do I make myself
    clear?

    BTW, I maintain that the fact that the type of printf is a varargs
    means that the compiler is mandated to push the int on the stack and
    pay no attention to whatever is written in the format field for that arg
    - which, btw is not required to be a const in the fprintf instantiation
    of printf, so could not be examined anyway. As though even being a
    const permitted the compiler to figure it out, since the const can be
    passed in from another compilation unit.

    So all the nerrnerrs who are shouting further nonsenses about undefined
    behaviour can also go and shoot themselves, with thanks.

    > > > (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.

    >
    > 256 word address space has nothing to do with the number of bits
    > in an int, and even less to do with sizeof(unsigned int).
    > FYI, ints (signed or unsigned) must have at least 16 bits.


    Sigh. I made that more precise in the next sentence, where I asked how
    big was his long. And if you ask me it is pretty short.

    > Also, systems with sizeof(unsigned int) == 1 are not that
    > uncommon,


    Oh yes they are.

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

    >
    > Actually it gets promoted to signed int (except for implementations
    > where this is not always possible -- namely, those with
    > sizeof(int) == 1)


    And, as if I cared, exactly what difference does this make? The
    promotion happens because it is passed as an argument to a function
    call. Unless signed and unsigned ints are different sizes, the
    receiving function will care honaynanny about what the sending code
    thinks its sign is! So boo.


    Peter
    P.T. Breuer, Feb 19, 2004
    #15
  16. Marcia Hon

    CBFalconer Guest

    "P.T. Breuer" wrote:
    > In comp.os.linux.networking Old Wolf <> wrote:
    >

    .... snip ...
    >
    > I did not say that, and I am not responsible for your misconceptions,
    > and I wish you would keep both them and your imaginative
    > misinterpretations to yourself.
    >
    > > "char is signed on your platform", to me anyway
    > > (and probably to the OP).

    >
    > The OP doesn't know a thing about "platforms", except possibly that
    > they often break when walking rapidly. Kindly do not confuse it.
    > If it knew what it were doing it would not offer such absurd non-
    > theories as to what is going on. The explanation it wants IS that
    > its char IS a signed quantity and that it IS promoted to a (signed)
    > int when passed to the printf routine that prints it out, thus
    > extending the sign bit left, effctively "filling out" the space to
    > left with fffff. It did have some crackpot theory about chars
    > really being full of fffs as far as I can make out.
    >
    > Note my capitalization of IS, and go take a deep cold long shower.

    .... snip ...
    >
    > To be consistent you should go shoot yourself. In what way is the
    > type of the other elements here an issue? That's right, it isn't.
    > Therefore "to be consistent" I should come over and break this
    > ruler over your head until you stop behaving like a pratty
    > schoolboy. Do I make myself clear?


    You appear to be a boorish juvenile unable to understand that
    c.l.c wants topical postings, and that you should restrict your
    non-topical material to groups where they are acceptable. The
    appropriate response is PLONK.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 20, 2004
    #16
  17. Troll: bit operation

    CBFalconer wrote:

    > You appear to be a boorish juvenile
    > unable to understand that c.l.c wants topical postings
    > and that you should restrict your non-topical material
    > to groups where they are acceptable.
    > The appropriate response is PLONK.


    Chuck,

    You need to get yourself a life.
    Bullying and abusing new subscribers to the comp.lang.c newsgroup
    is *not* much of a hobby.
    Now that you've retired, you should try fishing or playing cards.
    E. Robert Tisdale, Feb 20, 2004
    #17
  18. Re: Troll: bit operation

    In article <>,
    "E. Robert Tisdale" <> wrote:

    > <nothing of interest>


    Tisdale, it is really nice of you that you start your posts with
    "Troll:" nowadays. That helps inexperienced readers of comp.lang.c who
    don't know you yet.
    Christian Bau, Feb 20, 2004
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    1,750
    Timothy Bendfelt
    Jan 19, 2007
  2. none
    Replies:
    2
    Views:
    286
  3. david ullua
    Replies:
    13
    Views:
    666
  4. Replies:
    9
    Views:
    968
    Juha Nieminen
    Aug 22, 2007
  5. Jeff.M
    Replies:
    6
    Views:
    172
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page