bugs in c

[Prashanth Badabagni]

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

 

[Joona I Palaste]

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 ([email protected]) ------------- 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

 

[Robert Stankowic]

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

 

[Dan Pop]

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

 

[Joona I Palaste]

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.

 

[Richard Heathfield]

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.

 

[Christopher Benson-Manica]

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?

 

[Arthur J. O'Dwyer]

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

 

[Eric Sosman]

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

 

[Joona I Palaste]

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

 

[Irrwahn Grausewitz]

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.

 

[August Derleth]

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

 

[CBFalconer]

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

 

[Nudge]

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 ;-þ

 

[Dan Pop]

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]

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

 

[Richard Bos]

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

 

[Christopher Benson-Manica]

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?

 

[Dik T. Winter]

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

 

[Dan Pop]

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