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]

Prashanth Badabagni <pr***********@yahoo.co.uk> 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 (pa*****@cc.helsinki.fi) ------------- 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]

"Prashanth Badabagni" <pr***********@yahoo.co.uk> schrieb im Newsbeitrag
news:7b**************************@posting.google.c om...

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]

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Prashanth Badabagni <pr***********@yahoo.co.uk> 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: Da*****@ifh.de

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Prashanth Badabagni <pr***********@yahoo.co.uk> 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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"B-but Angus! You're a dragon!"
- Mickey Mouse

[Richard Heathfield]

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 : bi****@eton.powernet.co.uk
"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

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.ch> 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.

[Arthur J. O'Dwyer]

On Wed, 15 Oct 2003, Christopher Benson-Manica wrote:

Dan Pop <Da*****@cern.ch> 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

[Eric Sosman]

Christopher Benson-Manica wrote:

Dan Pop <Da*****@cern.ch> 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

--
Er*********@sun.com

[Joona I Palaste]

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> 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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen

[Irrwahn Grausewitz]

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> 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
(ir*******@freenet.de)

[August Derleth]

"Robert Stankowic" <pc******@netway.at> wrote in message news:<3f***********************@newsreader02.highw ay.telekom.at>...

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

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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

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

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> 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: Da*****@ifh.de

[Dan Pop]

In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> 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: Da*****@ifh.de

[Richard Bos]

Joona I Palaste <pa*****@cc.helsinki.fi> 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

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.ch> 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.

[Dik T. Winter]

In article <bm**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Dan Pop <Da*****@cern.ch> 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, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dan Pop]

In <HM********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:

In article <bm**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Dan Pop <Da*****@cern.ch> 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: Da*****@ifh.de

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.ch> spoke thus:

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

The folks who wrote the Linux kernel have done some bizarre things... if
anyone has done it, they have...

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