bugs in c

Discussion in 'C Programming' started by Prashanth Badabagni, Oct 15, 2003.

  1. hi,
    i'm prashanth Badabagni .. Can anyone tell me the BUGS present in
    C language whether programming or syntactical BUGS ....

    Thanks in advance ...


    Prashanth Badabagni
    Prashanth Badabagni, Oct 15, 2003
    #1
    1. Advertising

  2. Prashanth Badabagni <> scribbled the following:
    > hi,
    > i'm prashanth Badabagni .. Can anyone tell me the BUGS present in
    > C language whether programming or syntactical BUGS ....


    How would you define a "bug" in a programming language? Keep in mind
    that programming languages and *implementations* of programming
    languages are different things entirely. For example, gcc, Turbo C, MS
    Visual C, etc. are not languages, they're implementations of languages.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "When a man talks dirty to a woman, that's sexual harassment. When a woman talks
    dirty to a man, that's 14.99 per minute + local telephone charges!"
    - Ruben Stiller
    Joona I Palaste, Oct 15, 2003
    #2
    1. Advertising

  3. "Prashanth Badabagni" <> schrieb im Newsbeitrag
    news:...
    > hi,
    > i'm prashanth Badabagni .. Can anyone tell me the BUGS present in
    > C language whether programming or syntactical BUGS ....
    >
    > Thanks in advance ...


    Do you mean pitfalls? (you know, that features of a language which provide
    enough ammunition to shoot yourself into your foot)
    Well, C has plenty of them - it does not just give you the ammunition, it
    gives you the gun as well, together with enough rope to hang yourself :)

    Seriously, a good start will be to read the CLC FAQ at
    http://www.eskimo.com/~scs/C-faq/top.html
    and to get a good C-Book (IIRC there is a list of recommended books in the
    FAQ)
    Lurking around here for a while will also give you some valuable
    information.
    HTH
    Robert
    Robert Stankowic, Oct 15, 2003
    #3
  4. Prashanth Badabagni

    Dan Pop Guest

    In <bmiu2a$hpb$> Joona I Palaste <> writes:

    >Prashanth Badabagni <> scribbled the following:
    >> hi,
    >> i'm prashanth Badabagni .. Can anyone tell me the BUGS present in
    >> C language whether programming or syntactical BUGS ....

    >
    >How would you define a "bug" in a programming language?


    A brain dead feature that renders the language less intuitive or easy to
    use without any redeeming benefits. E.g. using + for the division
    operator and / for the addition operator.

    The precedence of the binary &, | and ^ operators is certainly a bug in C:
    they should have had higher precedence than the equality operators.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 15, 2003
    #4
  5. [OT] bugs in c

    Dan Pop <> scribbled the following:
    > In <bmiu2a$hpb$> Joona I Palaste <> writes:
    >>Prashanth Badabagni <> scribbled the following:
    >>> hi,
    >>> i'm prashanth Badabagni .. Can anyone tell me the BUGS present in
    >>> C language whether programming or syntactical BUGS ....

    >>
    >>How would you define a "bug" in a programming language?


    > A brain dead feature that renders the language less intuitive or easy to
    > use without any redeeming benefits. E.g. using + for the division
    > operator and / for the addition operator.


    > The precedence of the binary &, | and ^ operators is certainly a bug in C:
    > they should have had higher precedence than the equality operators.


    I agree that that is a bug if you define it in that way.

    Off-topic for comp.lang.c, but I have to say that there is also such a
    bug in Java: The fact that you can call static methods via instance
    references is clearly brain-dead language design. After all, the call
    doesn't *USE* the reference for anything other than finding out what
    class it is. There's *NO WAY* to tell from the call statement whether
    the method is static (and thus skips over polymorphism entirely) or
    dynamic (in which case the implementation is found polymorphically).
    You have to look at the method definition, which might well be in code
    someone else wrote.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "B-but Angus! You're a dragon!"
    - Mickey Mouse
    Joona I Palaste, Oct 15, 2003
    #5
  6. Prashanth Badabagni wrote:

    > hi,
    > i'm prashanth Badabagni .. Can anyone tell me the BUGS present in
    > C language whether programming or syntactical BUGS ....


    Show us your C code, and we'll gladly do our best to tell you the bugs
    present in that C code.

    The C language itself has remarkably few bugs. That's why it's still a
    phenomenally popular language 30 years on. If you want lots of bugs to chat
    about in a CS essay, try some other language.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Oct 15, 2003
    #6
  7. Dan Pop <> spoke thus:

    > The precedence of the binary &, | and ^ operators is certainly a bug in C:
    > they should have had higher precedence than the equality operators.


    Hm. I suppose I'll ask... 1) What was the original rationale for that
    design choice? 2) Why didn't C99 address it?

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Oct 15, 2003
    #7
  8. On Wed, 15 Oct 2003, Christopher Benson-Manica wrote:
    >
    > Dan Pop <> spoke thus:
    > >
    > > The precedence of the binary &, | and ^ operators is certainly a
    > > bug in C: they should have had higher precedence than the equality
    > > operators.

    >
    > Hm. I suppose I'll ask... 1) What was the original rationale for that
    > design choice?


    [DISCLAIMER: This whole thing is second-hand knowledge from memory.
    I believe Dennis Ritchie once wrote an article on the topic; check
    Google and Google Groups if you really want to know.]


    Some pre-C language (i.e., maybe B, BCPL, or intermediates) had the
    clever idea of overloading & and | in boolean contexts; that is,

    (i < j & j < k)

    would short-circuit and produce a boolean result (which in this
    context means an integer 0 or 1), while

    (i + j & j + k)

    would *not* short-circuit (not even if i+j==0) and not necessarily
    produce a boolean result.

    When pre-standard C came along, it inherited this overloading. But
    then the designers said, "Hey, this is really confusing!" and decided
    to split & and | into (& and |) and (&& and ||), one pair for arithmetic
    contexts and one pair for boolean contexts.

    So some poor fool probably had to go through all the old pre-C code,
    doing a search-and-replace on
    if (i==j & j==k)
    changing it to
    if (i==j && j==k)
    and so on. It would have been too much to ask of him to actually
    change the *precedence* of the operators, as well as the spelling!
    So && and || sneaked into the precedence table right below the
    old & and | operators, and nobody had to add any parentheses. :)


    > 2) Why didn't C99 address it?


    What would C99 have done? Changed the precedence tables? Do
    you have *any* idea how confusing that would be, especially when
    some hapless newbie Googles "c precedence table" and finds that
    the top two results contradict each other? Not to mention the
    vast body of C89 code out there that would break if the precedences
    were changed, or the annoyance it would cause to the designers of
    C-like languages like C++, Java, et al. - which of the two precedence
    tables would *they* use now?

    Moral: Design well, and design early, because once a re-design
    becomes a good idea, it's no longer a good idea. :)

    -Arthur
    Arthur J. O'Dwyer, Oct 15, 2003
    #8
  9. Prashanth Badabagni

    Eric Sosman Guest

    Christopher Benson-Manica wrote:
    >
    > Dan Pop <> spoke thus:
    >
    > > The precedence of the binary &, | and ^ operators is certainly a bug in C:
    > > they should have had higher precedence than the equality operators.

    >
    > Hm. I suppose I'll ask... 1) What was the original rationale for that
    > design choice? 2) Why didn't C99 address it?


    See

    http://www.lysator.liu.se/c/dmr-on-or.html#main

    --
    Eric Sosman, Oct 15, 2003
    #9
  10. Arthur J. O'Dwyer <> scribbled the following:
    > What would C99 have done? Changed the precedence tables? Do
    > you have *any* idea how confusing that would be, especially when
    > some hapless newbie Googles "c precedence table" and finds that
    > the top two results contradict each other? Not to mention the
    > vast body of C89 code out there that would break if the precedences
    > were changed, or the annoyance it would cause to the designers of
    > C-like languages like C++, Java, et al. - which of the two precedence
    > tables would *they* use now?


    > Moral: Design well, and design early, because once a re-design
    > becomes a good idea, it's no longer a good idea. :)


    So now the rule of thumb when dealing with C operator precedence is:
    "If in doubt, use parantheses like they're going out of fashion."

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Stronger, no. More seductive, cunning, crunchier the Dark Side is."
    - Mika P. Nieminen
    Joona I Palaste, Oct 15, 2003
    #10
  11. Joona I Palaste <> wrote:

    >Arthur J. O'Dwyer <> scribbled the following:
    >
    >> Moral: Design well, and design early, because once a re-design
    >> becomes a good idea, it's no longer a good idea. :)

    >
    >So now the rule of thumb when dealing with C operator precedence is:
    >"If in doubt, use parantheses like they're going out of fashion."


    Good advice. Both.
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Oct 15, 2003
    #11
  12. "Robert Stankowic" <> wrote in message news:<3f8d046d$0$33850$>...
    > (you know, that features of a language which provide
    > enough ammunition to shoot yourself into your foot)


    Shoot myself into my own foot? That would be a neat trick! Wouldn't it
    involve infinite recursion, tho?
    August Derleth, Oct 16, 2003
    #12
  13. Prashanth Badabagni

    CBFalconer Guest

    Joona I Palaste wrote:
    >

    .... snip ...
    >
    > So now the rule of thumb when dealing with C operator precedence is:
    > "If in doubt, use parantheses like they're going out of fashion."


    I make it a practice to use Lots of Insipid Silly Parentheses.
    The only assumptions I make is that multiplicative has precedence
    of additive has precedence over logical operators.

    This avoids much wear on tear on the little grey cells.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Oct 16, 2003
    #13
  14. Prashanth Badabagni

    Nudge Guest

    > The only assumptions I make is that multiplicative has precedence
    > of additive has precedence over logical operators.
    >
    > This avoids much wear on tear on the little grey cells.


    Judging from your first sentence, I'm afraid the little grey cells
    have taken quite a beating over the years.

    Just kidding, of course ;-รพ
    Nudge, Oct 16, 2003
    #14
  15. Prashanth Badabagni

    Dan Pop Guest

    In <bmk924$dql$> Joona I Palaste <> writes:

    >Arthur J. O'Dwyer <> scribbled the following:
    >> What would C99 have done? Changed the precedence tables? Do
    >> you have *any* idea how confusing that would be, especially when
    >> some hapless newbie Googles "c precedence table" and finds that
    >> the top two results contradict each other? Not to mention the
    >> vast body of C89 code out there that would break if the precedences
    >> were changed, or the annoyance it would cause to the designers of
    >> C-like languages like C++, Java, et al. - which of the two precedence
    >> tables would *they* use now?

    >
    >> Moral: Design well, and design early, because once a re-design
    >> becomes a good idea, it's no longer a good idea. :)

    >
    >So now the rule of thumb when dealing with C operator precedence is:
    >"If in doubt, use parantheses like they're going out of fashion."


    But that's the very problem: there is very little doubt in the mind of a
    newbie about the meaning of (alpha & 0xff == 0x33), therefore he can
    see no need for the *necessary* extra parentheses.

    As such, the expression is practically useless because it is parsed as
    (alpha & (0xff == 0x33)) which has no good use I can think of.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 16, 2003
    #15
  16. Prashanth Badabagni

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >I make it a practice to use Lots of Insipid Silly Parentheses.
    >The only assumptions I make is that multiplicative has precedence
    >of additive has precedence over logical operators.
    >
    >This avoids much wear on tear on the little grey cells.

    ^^^^^^^^^^^^^^^^^^^^^
    OTOH, leave them idle and they immediately get rusty. Which could
    explain your repeated failures of getting them to work when you needed
    them ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 16, 2003
    #16
  17. Prashanth Badabagni

    Richard Bos Guest

    Joona I Palaste <> wrote:

    > So now the rule of thumb when dealing with C operator precedence is:
    > "If in doubt, use parantheses like they're going out of fashion."


    Hmmm... no. I find the precedence of C operators quite sensible, with
    some glaring exceptions. Those exceptions are the bitwise operators,
    which are wrong; and the shift operators, and the relative positions of
    the ternary and assignment operators, for which no solution is
    definitely right. Around them, I parenthesise. Around the others, I
    don't see why it would be necessary.
    And I'll remark that your rule of thumb would mean that many people
    would follow fashion and stop using parentheses at all...

    Richard
    Richard Bos, Oct 16, 2003
    #17
  18. Dan Pop <> spoke thus:

    > As such, the expression is practically useless because it is parsed as
    > (alpha & (0xff == 0x33)) which has no good use I can think of.


    Maybe for setting an element in a bit array only if a given condition is true?

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Oct 16, 2003
    #18
  19. In article <bmm1n1$gmi$> Christopher Benson-Manica <> writes:
    > Dan Pop <> spoke thus:
    >
    > > As such, the expression is practically useless because it is parsed as
    > > (alpha & (0xff == 0x33)) which has no good use I can think of.

    >
    > Maybe for setting an element in a bit array only if a given condition is true?


    Perhaps clearing all bits, except one if the condition is true? The
    --
    dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
    home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
    Dik T. Winter, Oct 16, 2003
    #19
  20. Prashanth Badabagni

    Dan Pop Guest

    In <> "Dik T. Winter" <> writes:

    >In article <bmm1n1$gmi$> Christopher Benson-Manica <> writes:
    > > Dan Pop <> spoke thus:
    > >
    > > > As such, the expression is practically useless because it is parsed as
    > > > (alpha & (0xff == 0x33)) which has no good use I can think of.

    > >
    > > Maybe for setting an element in a bit array only if a given condition is true?

    >
    >Perhaps clearing all bits, except one if the condition is true? The


    That's why I said "good use". Hypothetical uses can be found, of course.

    How many people have actually used this construct, *on purpose*, in a real
    program?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 16, 2003
    #20
    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. aniket

    Vhdl Cli bugs ??

    aniket, Sep 27, 2003, in forum: VHDL
    Replies:
    0
    Views:
    513
    aniket
    Sep 27, 2003
  2. =?Utf-8?B?TkdN?=
    Replies:
    1
    Views:
    725
  3. angus
    Replies:
    1
    Views:
    528
    angus
    May 14, 2004
  4. Jon Maz
    Replies:
    14
    Views:
    854
    Mikhail Arkhipov (Microsoft)
    Oct 19, 2004
  5. Josef 'Jupp' Schugt

    Still use 'ruby-bugs' for Ruby bugs?

    Josef 'Jupp' Schugt, Nov 4, 2004, in forum: Ruby
    Replies:
    2
    Views:
    160
    Tom Copeland
    Nov 4, 2004
Loading...

Share This Page