Working with C
Deano
I always sort of wanted to be a coder. I liked C because it was near
the bottom
of what was really going on, almost assembler. I am going down the
support/network career path at the moment (Cisco etc.).
I gained really good grades in college doing C, Delphi etc. and my
lecturer
told me to go into development when I leave. Then I thought well
imagine
how boring it would be day in, day out although I never found
'assignments'
boring. I guess some of you here are full time coders, what do you
think?
Thanks for any views.
Romulus Marius Mare
news:17326cd1.03052...@posting.google.com...
I am sure nobody here finds C boring. :) However, I believe, this is
off-topic here.
Malcolm
the same computer. Only very rarely do you get to go out to a meeting or
conference.
However every day is different in that you are working on different problems
all the time. Once one module is written, its on to the next one.
The main requirement for being a programmer is good concentration and the
patience to keep at something until it is solved. Computers are
perfectionists, generally a program has to be 100% correct or it won't work
at all.
On Topic: If you want to do serious computer programming then C is the most
important language to learn. Practically every leading product is written
either in C or in C++.
Thomas Matthews
Sometimes I find coding as boring, not much of a challenge.
I find designing more exciting. Optimizing is more exciting too.
Developing code to exercise hardware is exciting.
I'm not a full-time coder, that is for college graduates and
interns. At the moment, I spend only about 20% of my time coding.
There are code reviews, design reviews, communication meetings and
problem solving / brainstorming sessions.
A lot of my time is spent in research. For example, when you
have an idea of what you want to accomplish, you need to research
how to accomplish it and if it has been done before.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
Dan Pop
>Sometimes I find coding as boring, not much of a challenge.
Easily avoided if you don't resort to routine coding. Try to "invent" a
new way of coding the same old thing in every new application and coding
becomes as interesting as designing.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Ben Pfaff
> Easily avoided if you don't resort to routine coding. Try to "invent" a
> new way of coding the same old thing in every new application and coding
> becomes as interesting as designing.
Sounds like a great way to write code that no one else can
understand. Code should be written to be as clear as possible,
not in a gratuitously "different" manner to amuse the
programmer. (At least for software that others will use. If
it's for personal enjoyment, it's entirely different.)
--
"This is a wonderful answer.
It's off-topic, it's incorrect, and it doesn't answer the question."
--Richard Heathfield
Malcolm
"Ben Pfaff" <b...@cs.stanford.edu> wrote in message
>
> Sounds like a great way to write code that no one else can
> understand. Code should be written to be as clear as possible,
> not in a gratuitously "different" manner to amuse the
> programmer. (At least for software that others will use. If
> it's for personal enjoyment, it's entirely different.)
>
world" in C
#include <stdio.h>
int main(void)
{
printf("Hello world\n");
return 0;
}
Now go to C++.
int main(void)
{
cout << "Hello World\n";
return 0;
}
or maybe, to be better
int main(void)
{
cout << "Hello World" << endl;
return 0;
}
But really it should be
int main(void)
{
string hello("Hello world");
cout << hello << endl;
return 0;
}
Or why not abandon all the cout ugliness and go back to good old stdio
int main(void)
{
printf("Hello world\n");
return 0;
}
or should that be
int main(void)
{
string hello("Hello World");
printf("%s\n", hello.cstr());
return 0;
}
We can play about forever with different coding styles.
Emmanuel Delahaye
>
> "Ben Pfaff" <b...@cs.stanford.edu> wrote in message
>>
>> Sounds like a great way to write code that no one else can
>> understand. Code should be written to be as clear as possible,
>> not in a gratuitously "different" manner to amuse the
>> programmer. (At least for software that others will use. If
>> it's for personal enjoyment, it's entirely different.)
>>
> C++ is your language for this. There's only one non-joke way to write
> "hello world" in C
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("Hello world\n");
> return 0;
> }
#include <stdio.h>
int main(void)
{
puts ("Hello world");
return 0;
}
is fine too.
--
-ed- emdel at noos.fr
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++
Giuseppe
Not forever, because people has to decide what is the best (or easy)
"Hello World" so only the much useful way to write the program "Hello
World" will live.
I think this is the way in what a language become more powerful.
_______________
We have to run.
Ravi Uday
> In 'comp.lang.c', "Malcolm" <mal...@55bank.freeserve.co.uk> wrote:
>
> >
> > "Ben Pfaff" <b...@cs.stanford.edu> wrote in message
> >>
> >> Sounds like a great way to write code that no one else can
> >> understand. Code should be written to be as clear as possible,
> >> not in a gratuitously "different" manner to amuse the
> >> programmer. (At least for software that others will use. If
> >> it's for personal enjoyment, it's entirely different.)
> >>
> > C++ is your language for this. There's only one non-joke way to write
> > "hello world" in C
> >
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > printf("Hello world\n");
> > return 0;
> > }
>
> #include <stdio.h>
>
> int main(void)
> {
> puts ("Hello world");
> return 0;
> }
>
> is fine too.
>
fputs ("hello world", stdout);
return 0;
}
too is better :-)
Mark McIntyre
(Ravi Uday) wrote:
>int main (){
> fputs ("hello world", stdout);
> return 0;
>}
>
>too is better :-)
Except that you may want to include the header for fputs, to avoid
invoking undefined behaviour... :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Dan Pop
>Dan...@cern.ch (Dan Pop) writes:
>
>> Easily avoided if you don't resort to routine coding. Try to "invent" a
>> new way of coding the same old thing in every new application and coding
>> becomes as interesting as designing.
>
>Sounds like a great way to write code that no one else can
>understand.
Could be true, if you're the one writing it.
>Code should be written to be as clear as possible,
>not in a gratuitously "different" manner to amuse the
>programmer.
Who says that the different manners need not be equally clear?
Is puts("hello world") less clear than printf("hello world\n") ?
How about fputs("hello world\n", stdout) or even
fwrite("hello world\n", 1, strlen("hello world\n"), stdout) ?
Dan Pop
>On 25 May 2003 22:54:20 -0700, in comp.lang.c , rav...@yahoo.com
>(Ravi Uday) wrote:
>
>>int main (){
>> fputs ("hello world", stdout);
>> return 0;
>>}
>>
>>too is better :-)
>
>Except that you may want to include the header for fputs, to avoid
>invoking undefined behaviour... :-)
There is no undefined behaviour, idiot! The usage of stdout without a
declaration in scope requires a diagnostic.
Emmanuel Delahaye
> int main (){
> fputs ("hello world", stdout);
Missing '\n' of fflush (stdout);
> return 0;
Dan Pop
>In 'comp.lang.c', rav...@yahoo.com (Ravi Uday) wrote:
>
>> int main (){
>> fputs ("hello world", stdout);
>
>Missing '\n' of fflush (stdout);
>
>> return 0;
>> }
stdout is automatically flushed, as part of the program termination
procedure. This doesn't fix the problem of the missing newline character,
however.
D Lewis
> patience to keep at something until it is solved. Computers are
> perfectionists, generally a program has to be 100% correct or it won't work
> at all.
>
> On Topic: If you want to do serious computer programming then C is the most
> important language to learn. Practically every leading product is written
> either in C or in C++.
I used to have a real dislike, when I was younger, about high level
languages.
Ok I suppose there is the productivity thing but codes becomes so much
more 'bloat' (Im not sure how optimizing high level language comilers
are these days but surely not as much as when using fine detail langs
like C?).
Saying that though I learned much, when at school, playing around
with the good old Turbo Pascal DOS compiler. Good intro to
programming.
I hated the idea of not knowing what was going on 'under the bonnet'
so to
speak. I guess after a few years of doing it properly in C/assembler
id be rid
of this curiousity maybe, then maybe not mind higher level languages
(but I doubt it).
When you think of co. like m$, look at the size of their programs.
This is so wasteful, and they are taking advantage of the new quick
h/w and big storage
capabilitys.
At least with other OS like Linux the code (Say the kernel) is being
done for interest sake and not for money and marketing targets.
Therefore is should be fairly optimum.
I wrote a Filebrowser etc. C program for X windows when at college,
loved the language and the way you could make real errors and crash
the machine properly. Guess Id have to get a year training position in
C to break into that career. I think ultimately Id need to try for a
while to see if its for me on a fulltime scale.
Dan Pop
>The main requirement for being a programmer is good concentration and the
>patience to keep at something until it is solved. Computers are
>perfectionists, generally a program has to be 100% correct or it won't work
>at all.
I wish that were true! Obscure bugs that manifest themselves a long time
after the program has been released are far from being an exception.
Ever heard of the so called "Y2K bug", which is a whole class of bugs?
>On Topic: If you want to do serious computer programming then C is the most
>important language to learn.
It strongly depends on the kind of computer programming you intend to do.
C sucks for numerical analysis, routine system administration tasks or
many serious text processing applications. Programming GUI-based
applications in C is not exactly a piece of cake, either.
>Practically every leading product is written either in C or in C++.
Do you have any factual evidence supporting this assertion?
D Lewis
> >patience to keep at something until it is solved. Computers are
> >perfectionists, generally a program has to be 100% correct or it won't work
> >at all.
> I wish that were true! Obscure bugs that manifest themselves a long time
> after the program has been released are far from being an exception.
> Ever heard of the so called "Y2K bug", which is a whole class of bugs?
A program is never really bug free 100%, there is always something in
there. It just has to be good enough for its job, then usually obvious
bugs are ironed out later. An exception is mission critical stuff like
flight control systems
but even they have had problems.
He did say *generally* 100% correct so I think this is what was meant.
> >On Topic: If you want to do serious computer programming then C is the most
> >important language to learn.
>
> It strongly depends on the kind of computer programming you intend to do.
> C sucks for numerical analysis, routine system administration tasks or
> many serious text processing applications. Programming GUI-based
> applications in C is not exactly a piece of cake, either.
C is a 3rd generation language but the most low level 3GL available
(compared
to pascal, modula2 etc. which take it a bit further) Some of the 3GL
are
specialised for particular tasks but are just more higher level. Some
Gui
langs. (ie Delphi) is a 4th Generation language (ie good for GUI
coding).
Sysadmin is mostly shell programming.
I beleive that someone who wants to have a true understanding of
Computers and
programming languages should of at least done C/Assembler coding. It
is not
a requirement,but for *serious* programming/understanding .
> >Practically every leading product is written either in C or in C++.
> Do you have any factual evidence supporting this assertion?
> Dan
When you say leading products, I wonder if m$ code in C++/C much. Id
say they
have lots of high level products that create *fat* inefficient code?
Thats
why we need so much ram and hd space :-)
I think that products that require top notch h/w performance must be
done in
lowish level langs like C.
Dan Pop
>> >The main requirement for being a programmer is good concentration and the
>> >patience to keep at something until it is solved. Computers are
>> >perfectionists, generally a program has to be 100% correct or it won't work
>> >at all.
>> I wish that were true! Obscure bugs that manifest themselves a long time
>> after the program has been released are far from being an exception.
>> Ever heard of the so called "Y2K bug", which is a whole class of bugs?
>
>A program is never really bug free 100%, there is always something in
>there.
Could you point out the bugs left in the following program:
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 0;
}
>It just has to be good enough for its job, then usually obvious
>bugs are ironed out later. An exception is mission critical stuff like
>flight control systems
>but even they have had problems.
>He did say *generally* 100% correct so I think this is what was meant.
And he was wrong. Generally, a program will work way before it is 100%
correct. Remove the #include <stdio.h> line from my program above and
chances are that it will still work as intended, despite no longer
being a correct C program (it invokes undefined behaviour now).
Chris Dollin
> Could you point out the bugs left in the following program:
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("hello world\n");
> return 0;
> }
There should be a comma after "hello" and a full stop after "world".
The moral of this nitpick being, if there's no specification, there's
no bug.
--
Chris "... printf( "loi\n" ); ..." Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
Bruce G. Stewart
>Could you point out the bugs left in the following program:
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("hello world\n");
> return 0;
> }
It exits successfully, even if printf fails?
Dan Pop
Does the specification requires anything else?
Dan Pop
>Dan Pop wrote:
>
>> Could you point out the bugs left in the following program:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> printf("hello world\n");
>> return 0;
>> }
>
>There should be a comma after "hello" and a full stop after "world".
>
>The moral of this nitpick being, if there's no specification, there's
>no bug.
The obvious specification is that the program displays the words "hello"
and "world", separated by a space and followed by a line terminator.
If the program displays any commas or full stops, it doesn't match the
specification.
Mark McIntyre
>In <bb7nqe$bha$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com> writes:
>
>>The moral of this nitpick being, if there's no specification, there's
>>no bug.
>
>The obvious specification is that the program displays the words "hello"
>and "world", separated by a space and followed by a line terminator.
Thats a logical choice for the spec. But for all we know, the spec
actually included the comma and dot, and their lack is a bug. If there
is no spec, you can't definitively state that a behaviour is a bug,
merely that its not what /you/ expected.
Bruce G. Stewart
>In <9goedvo0cccia9qdi...@4ax.com> Bruce G. Stewart <Bruce.G...@att.net> writes:
>
>>On 30 May 2003 13:21:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>
>>>Could you point out the bugs left in the following program:
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>> printf("hello world\n");
>>> return 0;
>>> }
>>
>>It exits successfully, even if printf fails?
>
>Does the specification requires anything else?
As is customary in this line of work, the programmer is not allowed to
know the full scope of the specification until the software has been
delivered.
Will
int main() {return 0; }. I sit here like a broken record
repeating over and over again "this is not C that is not C."
Maybe someone just post the darn
starndard in this group and there will be no more questions to ask. Unfortunately
reproducing the work of the standard committe here is illegal
(EVEN PARTS, SNIPPETS OF THE STANDARDS SHOULD NOT BE POSTED)
therefore I dont see how someone can speculate ,for example, socket is not C,
unless he posts the whole C standard here (and risking litigations issues)
or he/she is himself/herself a member of the C committee.
To whoever who have questions like how to write a driver in C or program I2C
or do DirectX in C, I strongly urge you find a windows or linux group to ask.
Better yet, use googles to search for your topics. HEre you only find people
that dont get bored typeing "this is not C, that is not C" over and over again.
Flopp...@hotmail.com (Deano) wrote in message news:<17326cd1.03052...@posting.google.com>...
CBFalconer
And the canny programmer writes his code to anticipate the future
outrageous demands of the marketdroids. He then moans and groans
about the effort required to implement these new and obviously
ridiculous demands, drops memos here and there, with copies there
and here, installs two new lines after spending a week on things
of real interest, cackles and preens himself while composing a new
set of memos pointing out how his herculean efforts have saved the
day, and demands a raise. He can also take an extra week off,
pleading exhaustion from his epic struggles on behalf of the PHB.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Ben Pfaff
> Maybe someone just post the darn
> starndard in this group and there will be no more questions to ask. Unfortunately
> reproducing the work of the standard committe here is illegal
> (EVEN PARTS, SNIPPETS OF THE STANDARDS SHOULD NOT BE POSTED)
Don't be ridiculous. Posting a small piece of the standard to
back up a point is perfectly acceptable. It falls under "fair
use".
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro
pete
> not C
> not C."
> not C,
> not C" over and over again.
Those Not C Bastards ! (flirting with Godwin's law)
--
pete
CBFalconer
> wv9...@yahoo.com (Will) writes:
>
> > Maybe someone just post the darn starndard in this group and
> > there will be no more questions to ask. Unfortunately
> > reproducing the work of the standard committe here is illegal
> > (EVEN PARTS, SNIPPETS OF THE STANDARDS SHOULD NOT BE POSTED)
>
> Don't be ridiculous. Posting a small piece of the standard to
> back up a point is perfectly acceptable. It falls under "fair
> use".
Besides which, anybody can go to:
<http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/>
and download the last draft version. The text version is my
preference. Searching and quoting then becomes easy. WARNING:
there are differences from the final standard, usually minor.
Chris Dollin
> In <bb7nqe$bha$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
> writes:
>
>>Dan Pop wrote:
>>
>>> Could you point out the bugs left in the following program:
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>> printf("hello world\n");
>>> return 0;
>>> }
>>
>>There should be a comma after "hello" and a full stop after "world".
>>
>>The moral of this nitpick being, if there's no specification, there's
>>no bug.
>
> The obvious specification is that the program displays the words "hello"
> and "world", separated by a space and followed by a line terminator.
You might think that. I couldn't possibly comment.
All right, perhaps I can. That's *not* the obvious specification.
> If the program displays any commas or full stops, it doesn't match the
> specification.
Chapter and verse, please.
--
Chris "electric hedgehog" Dollin
Dan Pop
>Ben Pfaff wrote:
>> wv9...@yahoo.com (Will) writes:
>>
>> > Maybe someone just post the darn starndard in this group and
>> > there will be no more questions to ask. Unfortunately
>> > reproducing the work of the standard committe here is illegal
>> > (EVEN PARTS, SNIPPETS OF THE STANDARDS SHOULD NOT BE POSTED)
>>
>> Don't be ridiculous. Posting a small piece of the standard to
>> back up a point is perfectly acceptable. It falls under "fair
>> use".
>
>Besides which, anybody can go to:
>
> <http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/>
>
>and download the last draft version. The text version is my
>preference. Searching and quoting then becomes easy. WARNING:
>there are differences from the final standard, usually minor.
But the copyright issue is the same. You can't post quotes from n869
any more than you can post quotes from C99. The "fair use" doctrine
applies the same in both cases.
Dan Pop
>Dan Pop wrote:
>
>> In <bb7nqe$bha$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
>> writes:
>>
>>>Dan Pop wrote:
>>>
>>>> Could you point out the bugs left in the following program:
>>>>
>>>> #include <stdio.h>
>>>>
>>>> int main(void)
>>>> {
>>>> printf("hello world\n");
>>>> return 0;
>>>> }
>>>
>>>There should be a comma after "hello" and a full stop after "world".
>>>
>>>The moral of this nitpick being, if there's no specification, there's
>>>no bug.
>>
>> The obvious specification is that the program displays the words "hello"
>> and "world", separated by a space and followed by a line terminator.
>
>You might think that. I couldn't possibly comment.
>
>All right, perhaps I can. That's *not* the obvious specification.
>
>> If the program displays any commas or full stops, it doesn't match the
>> specification.
>
>Chapter and verse, please.
Chapter and verse from what?!? From the program specification, that is
written by myself?
Are you sure you have engaged your brain?
BTW, the corresponding program from K&R2 matches neither your
specification nor mine. Which is OK, since it was specified and
implemented by a third person.
D Lewis
> >> after the program has been released are far from being an exception.
> >> Ever heard of the so called "Y2K bug", which is a whole class of bugs?
> >A program is never really bug free 100%, there is always something in
> >there.
> Could you point out the bugs left in the following program:
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("hello world\n");
> return 0;
> }
This is 100% ok, there is next to nothing in logic here. Not exactly a
fully
blown application though is it. I guess youll be picky and say yes,
but I am referring to a much more complex piece of coding (as you
know!), with *lots*
of different paths through the logic.
> >It just has to be good enough for its job, then usually obvious
> >bugs are ironed out later. An exception is mission critical stuff like
> >flight control systems
> >but even they have had problems.
> >He did say *generally* 100% correct so I think this is what was meant.
>
> And he was wrong. Generally, a program will work way before it is 100%
> correct. Remove the #include <stdio.h> line from my program above and
> chances are that it will still work as intended, despite no longer
> being a correct C program (it invokes undefined behaviour now).
There is no *logic* errors in the program. I am not on about compiler
library
errors and the like.
D Lewis
> Dan...@cern.ch (Dan Pop) writes:
>
> > Easily avoided if you don't resort to routine coding. Try to "invent" a
> > new way of coding the same old thing in every new application and coding
> > becomes as interesting as designing.
>
> Sounds like a great way to write code that no one else can
> not in a gratuitously "different" manner to amuse the
> it's for personal enjoyment, it's entirely different.)
Yeh the old saying dont re-invent the wheel.
I still think there is still plenty of room for your own algorithms,
while still using commonly available librarys. The program design as a
whole, then I guess you could alter that to make things more
interesting as long as youve got the time for the variety and its not
too complex to require extensive testing/debug. A good way to learn
and improve things too.
Emmanuel Delahaye
>> Could you point out the bugs left in the following program:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> printf("hello world\n");
>> return 0;
>> }
>
> There should be a comma after "hello" and a full stop after "world".
And the 'h' of hello should be uppercase!
Chris Dollin
> In <bbetvr$alr$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
> writes:
>
>>Dan Pop wrote:
>>
>>> In <bb7nqe$bha$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
>>> writes:
>>>
>>>>Dan Pop wrote:
>>>>
>>>>> Could you point out the bugs left in the following program:
>>>>>
>>>>> #include <stdio.h>
>>>>>
>>>>> int main(void)
>>>>> {
>>>>> printf("hello world\n");
>>>>> return 0;
>>>>> }
>>>>
>>>>There should be a comma after "hello" and a full stop after "world".
>>>>
>>>>The moral of this nitpick being, if there's no specification, there's
>>>>no bug.
>>>
>>> The obvious specification is that the program displays the words "hello"
>>> and "world", separated by a space and followed by a line terminator.
>>
>>You might think that. I couldn't possibly comment.
>>
>>All right, perhaps I can. That's *not* the obvious specification.
(Since you didn't respond to this, I don't know whether or not you still
think your specification is the "obvious" one, and if you do, why you think
your notion of obviousness is obviously the appropriate one. It's those
kind of differences of interpretation, writ larger, are one source of
difficulty in producing code that does "the right thing")
>>> If the program displays any commas or full stops, it doesn't match the
>>> specification.
>>
>>Chapter and verse, please.
>
> Chapter and verse from what?!? From the program specification, that is
> written by myself?
Any idiot [1] can write a specification that specifies what a program does
*after* they have the program to hand [2]. Since I don't take you to be that
kind of idiot, I assumed you were working from an actual pre-existing
specification that you could cite, rather than making things up on the
spot.
> Are you sure you have engaged your brain?
Absolutely. I'm not sure you have, though.
> BTW, the corresponding program from K&R2 matches neither your
> specification nor mine. Which is OK, since it was specified and
> implemented by a third person.
[1] Well ... they have to be able to write, and they have to be able to
udnerstand the notion of "specification". So perhaps not *any* idiot.
[2] For interesting programs this turns out to be rather less easy than
the casual tone taken by this sentence would suggest.
--
Chris "hedgehog, not fox, today" Dollin
Dan Pop
>In 'comp.lang.c', Chris Dollin <ke...@hpl.hp.com> wrote:
>
>>> Could you point out the bugs left in the following program:
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>> printf("hello world\n");
>>> return 0;
>>> }
>>
>> There should be a comma after "hello" and a full stop after "world".
>
>And the 'h' of hello should be uppercase!
Too bad a certain Brian W. Kernighan couldn't benefit from your combined
insight...
Dan Pop
>spot. ^^^^^^^^^^^^^^^^^^^
And this pre-existing specification could not have been elaborated
by myself? By what kind of logic?
>> Are you sure you have engaged your brain?
>
>Absolutely. I'm not sure you have, though.
Ditto.
Chris Dollin
I did not claim that you could not have elaborated such a specification
yourself, so I don't need to supply a logic to derive it, ta very much.
What you *could* have done, but did not, was to supply such a specification
at the time you called for bug-spotting, thus leaving me a convenient slot
to point out that without a specification, there's no way to check for bugs.
>>> Are you sure you have engaged your brain?
>>
>>Absolutely. I'm not sure you have, though.
>
> Ditto.
Well, at least we can be confident in our mutual uncertainty about each
other's engagedness. It's nice to have an anchor in the storm.
--
Chris "teacup hedgehog" Dollin
Chris Dollin
> In <Xns938F4B448EC...@130.133.1.4> Emmanuel Delahaye
> <emdel...@noos.fr> writes:
>
>>In 'comp.lang.c', Chris Dollin <ke...@hpl.hp.com> wrote:
>>
>>>> Could you point out the bugs left in the following program:
>>>>
>>>> #include <stdio.h>
>>>>
>>>> int main(void)
>>>> {
>>>> printf("hello world\n");
>>>> return 0;
>>>> }
>>>
>>> There should be a comma after "hello" and a full stop after "world".
>>
>>And the 'h' of hello should be uppercase!
>
> Too bad a certain Brian W. Kernighan couldn't benefit from your combined
> insight...
He's not died, has he?
--
Chris "electric hedgehog" Dollin
Dan Pop
>Dan Pop wrote:
>
>> In <Xns938F4B448EC...@130.133.1.4> Emmanuel Delahaye
>> <emdel...@noos.fr> writes:
>>
>>>In 'comp.lang.c', Chris Dollin <ke...@hpl.hp.com> wrote:
>>>
>>>>> Could you point out the bugs left in the following program:
>>>>>
>>>>> #include <stdio.h>
>>>>>
>>>>> int main(void)
>>>>> {
>>>>> printf("hello world\n");
>>>>> return 0;
>>>>> }
>>>>
>>>> There should be a comma after "hello" and a full stop after "world".
>>>
>>>And the 'h' of hello should be uppercase!
>>
>> Too bad a certain Brian W. Kernighan couldn't benefit from your combined
>> insight...
>
>He's not died, has he?
No, but it's too late for the existing editions of K&R and there are no
plans for a third edition.
Dan Pop
>Dan Pop wrote:
>
>> In <bbhj96$dbo$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
>> writes:
>
>>>Any idiot [1] can write a specification that specifies what a program does
>>>*after* they have the program to hand [2]. Since I don't take you to be
>>>that kind of idiot, I assumed you were working from an actual pre-existing
>>>specification that you could cite, rather than making things up on the
>>>spot. ^^^^^^^^^^^^^^^^^^^
>>
>> And this pre-existing specification could not have been elaborated
>> by myself? By what kind of logic?
>
>I did not claim that you could not have elaborated such a specification
>yourself, so I don't need to supply a logic to derive it, ta very much.
>
>What you *could* have done, but did not, was to supply such a specification
>at the time you called for bug-spotting, thus leaving me a convenient slot
>to point out that without a specification, there's no way to check for bugs.
It was supposed to be obvious. And you're dead wrong: you can find bugs
even in the absence of a specification. Proof:
int main()
{
char c;
puts("Enter a word of your choice:");
gets(&c);
printf("The word you entered was: %c", c);
return 0;
}
The specification of the program is equally obvious and so are (hopefully)
the bugs.
Richard Heathfield
> Dan Pop wrote:
>
<snip>
>>
>> Too bad a certain Brian W. Kernighan couldn't benefit from your combined
>> insight...
>
> He's not died, has he?
That's the trouble with being a celebrated figure, I guess. After a while,
people just start assuming you're dead. Mark Twain[1] had the same problem.
[1] Whoever it is who feels obliged to provide the quote, please - just
don't. Thanks.
--
Richard Heathfield : bin...@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
Chris Dollin
> In <bbkadl$7ds$1...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
> writes:
>>What you *could* have done, but did not, was to supply such a
>>specification at the time you called for bug-spotting, thus leaving me a
>>convenient slot to point out that without a specification, there's no way
>>to check for bugs.
>
> It was supposed to be obvious.
So much for supposition. People are different; there isn't a universal
meaning for "obvious".
> And you're dead wrong: you can find bugs
> even in the absence of a specification.
Nope. Sorry.
> Proof:
>
> int main()
> {
> char c;
> puts("Enter a word of your choice:");
> gets(&c);
> printf("The word you entered was: %c", c);
> return 0;
> }
>
> The specification of the program is equally obvious
I'm glad you think so. I certainly don't. There are certainly plausible
candidates. I'd guess that it's supposed to prompt, read in a "word",
and write it out again, using your assertion of "obviousness" to supply
extra information.
It's not obvious to me that the specification of the program said
anything about a prompt, or what its spelling was, and whether or not
it should end with a newline. It's not obvious to me that the specification
said what the format of the output was - for example, I would expect
that the %c should be surrounded by suitable quotes. It's not obvious
what, if any, the limit on word size in the specification was, and
whether or not the specification is as confused about words vs lines
as the code appears to be.
> and so are (hopefully) the bugs.
No specification, no bugs. If we *assume* a specification, we can
infer the corresponding bugs. If we're mistaken in our assumptions,
then we may mis-identify bugs.
*If* the program is supposed to read a line-as-word [which I count as
plasible but not as obvious], and words are expected to have at least one
character in them [which even I would count as obvious, the expectation
tat is not the length constraint], then by golly I agree that a single-char
buffer is a bug, and gets a bug waiting to happen.
--
Chris "electric hedgehog" Dollin
Chris Dollin
And?
Chris Dollin
... some stuff to which I'd nearly finished a reply, whereupon my
newsreader fell over, and furthermore refuses once restarted to
reveal Dan's message again (we've had server problems today). Drat.
So: my splitting of Dan's paragraph at a sentence boundary seemed
perfectly reasonable to me, inasmuch I had separate responses to
separate sentences; my so-called "cheap shot" made what I believe
to be a genuine point, which Dan chose to ignore; I made no assertion
that up-front design was the only way to know what one is doing
when writing code; and I wasn't the one arguing that parameters should
never be modified in the first place.
--
Chris "electric hedgehog" Dollin
Dan Pop
>Dan Pop wrote:
>
>> In <bbkaf5$7ds$2...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
>> writes:
>>
>>>Dan Pop wrote:
>
>>>> Too bad a certain Brian W. Kernighan couldn't benefit from your combined
>>>> insight...
>>>
>>>He's not died, has he?
>>
>> No, but it's too late for the existing editions of K&R and there are no
>> plans for a third edition.
>
>And?
And read again my remark at the beginning of the included text (right
after the attributions). If you still don't get the point (you seem to
be deliberately obtuse in this thread), the idea is that someone who is
both a native English speaker and a reputed author of programming books
doesn't share your views about the proper way of punctuating a "hello
world" message. So, can we have your credentials?
Dan Pop
>Dan Pop wrote:
>
>... some stuff to which I'd nearly finished a reply, whereupon my
>newsreader fell over, and furthermore refuses once restarted to
>reveal Dan's message again (we've had server problems today). Drat.
>
>So: my splitting of Dan's paragraph at a sentence boundary seemed
>perfectly reasonable to me, inasmuch I had separate responses to
>separate sentences;
Yet, the sentences were very closely related (the second one started
with "or", IIRC). Therefore, completely ignoring the second one when
replying to the first one was a cheap trick to allow you to make a
cheap shot. It's called "quoting out of context".
Mark McIntyre
<ke...@hpl.hp.com> wrote:
>Dan Pop wrote:
>
>
>> And you're dead wrong: you can find bugs
>> even in the absence of a specification.
>
>Nope. Sorry.
I'm fascinated: how _can_ you find bugs without a specification?
ps Someone please quote dan's response so that I can see it...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
CBFalconer
>
... snip ...
>
> And read again my remark at the beginning of the included text (right
> after the attributions). If you still don't get the point (you seem to
> be deliberately obtuse in this thread), the idea is that someone who is
> both a native English speaker and a reputed author of programming books
> doesn't share your views about the proper way of punctuating a "hello
> world" message. So, can we have your credentials?
This is roughly the most inane thread in captivity. thread PLONK.
Chris Dollin
As usual, when attempting to guess my motives you're about as far
off the mark as it's possible to be while still writing coherent English.
Chris Dollin
> In <bbkukp$hfs$2...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
> writes:
>
>>Dan Pop wrote:
>>
>>> In <bbkaf5$7ds$2...@murdoch.hpl.hp.com> Chris Dollin <ke...@hpl.hp.com>
>>> writes:
>>>
>>>>Dan Pop wrote:
>>
>>>>> Too bad a certain Brian W. Kernighan couldn't benefit from your
>>>>> combined insight...
>>>>
>>>>He's not died, has he?
>>>
>>> No, but it's too late for the existing editions of K&R and there are no
>>> plans for a third edition.
>>
>>And?
>
> And read again my remark at the beginning of the included text (right
> after the attributions). If you still don't get the point (you seem to
> be deliberately obtuse in this thread), the idea is that someone who is
> both a native English speaker and a reputed author of programming books
> doesn't share your views about the proper way of punctuating a "hello
> world" message.
And?
I mean, so what?
That doesn't stop him benefiting, in the unlikely event he thought it
relevant and appropriate. What this has to do with specification is
beyond me. He had his; I have mine; neither of them is Right and the
entire point of my original nitpick [labelled as such] was that you
cannot tell if a program is buggy without knowing what it's supposed
to do. That we've both wasted our - and other people's - time on this
bickering reflects badly on me, and I apologise and stop with this
posting.
> So, can we have your credentials?
No.
If you really thought they'd matter in this discussion, you'd be an
idiot.
Chris Torek
Mark McIntyre <markmc...@spamcop.net> writes:
>I'm fascinated: how _can_ you find bugs without a specification?
I am neither Dan Pop nor Chris Dollin, but I can answer this one :-)
In fact, it is pretty easy to find bugs in a program, even
without a specification for that program. The problem is that
you may not be finding the *important* bugs.
Consider, e.g., the following (broken) function:
double convert(double x) {
return x * 9 / 5 - 32;
}
This is full of magic numbers, but one might recognize those numbers
and say: aha, this must be a (broken) fahrenheit/celsius conversion
function.
Add a bit more context with another (broken) function:
int doit(void) {
double x;
char buf[SOMESIZE];
printf("tell me temperature in degrees C: ");
fflush(stdout);
if (fgets(buf, sizeof buf, stdin) == NULL)
return -1;
if (sscanf("%f", &x) != 1)
return 1;
printf("in degrees F, it is: %f\n", convert(x));
return 0;
}
There are two bugs I put in here deliberately. The first is in
convert(), which should *add* 32, not subtract it. The second is
in doit(), which must use "%lf" in the scanf format.
So, even without a specification (much less a main()) we can
claim to have found two bugs.
If the specification says that the program needs to calculate square
footage, however, we have found the *wrong* bugs. Which is of
course the point someone here was making -- we need to know what
the program is *supposed* to do. Otherwise we may waste time and
energy debugging something entirely irrelevant.
As an aside, I might note (as I think others, maybe David Parnas,
did before me) that a sufficiently detailed specification *is* a
program. Specifications therefore necessarily leave things out,
and the usual problem is leaving out too much -- but "not leaving
enough out" can also be a problem. :-)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Dan Pop
>Dan Pop wrote:
>
>That doesn't stop him benefiting, in the unlikely event he thought it
>relevant and appropriate. What this has to do with specification is
>beyond me. He had his; I have mine; neither of them is Right and the
>entire point of my original nitpick [labelled as such] was that you
>cannot tell if a program is buggy without knowing what it's supposed
>to do. That we've both wasted our - and other people's - time on this
>bickering reflects badly on me, and I apologise and stop with this
>posting.
>
>> So, can we have your credentials?
>
>No.
>
>If you really thought they'd matter in this discussion, you'd be an
>idiot.
It was a mere insinuation that they're nowhere near his, therefore I have
no *good* reason for preferring your version to his. I really couldn't
care less about your credentials.
Mark McIntyre
<nos...@elf.eng.bsdi.com> wrote:
>In article <s64tdvgeerh9b9n2f...@4ax.com>
>Mark McIntyre <markmc...@spamcop.net> writes:
>>I'm fascinated: how _can_ you find bugs without a specification?
>
>I am neither Dan Pop nor Chris Dollin, but I can answer this one :-)
>
>In fact, it is pretty easy to find bugs in a program, even
>without a specification for that program.
Hmm.... Its pretty easy to find what are, in ones opionion, bugs,
given ones opinion of what the spec ought to have been.
>The problem is that
>you may not be finding the *important* bugs.
That too.
>Consider, e.g., the following (broken) function:
>
> double convert(double x) {
> return x * 9 / 5 - 32;
> }
>
>This is full of magic numbers, but one might recognize those numbers
>and say: aha, this must be a (broken) fahrenheit/celsius conversion
>function.
My point was ,since you don't have the spec, maybe the OP *wanted* a
broken F/C convertor. There's no way to know.
...
>So, even without a specification (much less a main()) we can
>claim to have found two bugs.
Again, maybe the (pathological) specifier *wanted* something that did
odd things. Maybe he was a practical joker. Maybe he subscribed to the
"if my users enter silly input I'm allowed to crash horribly and
physically damage the database and tape drive" school of programming.
Dan Pop
>In article <s64tdvgeerh9b9n2f...@4ax.com>
>Mark McIntyre <markmc...@spamcop.net> writes:
>>I'm fascinated: how _can_ you find bugs without a specification?
>
>I am neither Dan Pop nor Chris Dollin, but I can answer this one :-)
>
>In fact, it is pretty easy to find bugs in a program, even
>without a specification for that program. The problem is that
>you may not be finding the *important* bugs.
>
>Consider, e.g., the following (broken) function:
>
> double convert(double x) {
> return x * 9 / 5 - 32;
> }
>
>This is full of magic numbers, but one might recognize those numbers
>and say: aha, this must be a (broken) fahrenheit/celsius conversion
>function.
My own example was even less ambiguous:
int main()
{
char c;
puts("Enter a word of your choice:");
gets(&c);
printf("The word you entered was: %c", c);
return 0;
}
Anyone pretending not to be able to figure out the program's specification
and its obvious bugs is either deliberately obtuse or Mark McIntyre.
pete
> >> And you're dead wrong: you can find bugs
> >> even in the absence of a specification.
> >
> >Nope. Sorry.
>
> I'm fascinated: how _can_ you find bugs without a specification?
I found two bugs in one of Joel Rees' posts recently.
One was a obviously a bug, without knowing any specification.
The first bug was comparing a size_t variable,
for greater than or equal to zero,
as the control condition in a while loop.
--
pete
Mark McIntyre
<pfi...@mindspring.com> wrote:
>Mark McIntyre wrote:
>
>> >> And you're dead wrong: you can find bugs
>> >> even in the absence of a specification.
>> >
>> >Nope. Sorry.
>>
>> I'm fascinated: how _can_ you find bugs without a specification?
>
>I found two bugs in one of Joel Rees' posts recently.
>One was a obviously a bug, without knowing any specification.
Yeah? How do you know for sure? Seriously.
>The first bug was comparing a size_t variable,
>for greater than or equal to zero,
>as the control condition in a while loop.
Its *probably* a bug, but there's absolutely no way to know for sure.
Maybe the unseen specification wanted an infinite loop, and maybe the
control variable was required to count down to zero and then on again
from UINT_MAX, for purposes unknown and not contained within this
snippet. Or maybe the OP just thought it was a cool way to get an
infinite loop.
Do you see my point?
karl malbrain
news:bbqde3$a9$1...@sunnews.cern.ch...
You are correct with respect to SELF-DOCUMENTING programming discipline,
which should be S.O.P. However, your example also displays the MAXIM: if
it's not broken, don't fix it. In other words this particular bug might be
as minor as the HUNDREDS of patches being released out of Redmond right now
that I just ignore. karl m
Kevin Easton
> On Fri, 06 Jun 2003 05:32:01 -0400, in comp.lang.c , pete
> <pfi...@mindspring.com> wrote:
>
>>Mark McIntyre wrote:
>>
>>> >> And you're dead wrong: you can find bugs
>>> >> even in the absence of a specification.
>>> >
>>> >Nope. Sorry.
>>>
>>> I'm fascinated: how _can_ you find bugs without a specification?
>>
>>I found two bugs in one of Joel Rees' posts recently.
>>One was a obviously a bug, without knowing any specification.
>
> Yeah? How do you know for sure? Seriously.
>
>>The first bug was comparing a size_t variable,
>>for greater than or equal to zero,
>>as the control condition in a while loop.
>
> Its *probably* a bug, but there's absolutely no way to know for sure.
> Maybe the unseen specification wanted an infinite loop, and maybe the
> control variable was required to count down to zero and then on again
> from UINT_MAX, for purposes unknown and not contained within this
> snippet. Or maybe the OP just thought it was a cool way to get an
> infinite loop.
>
> Do you see my point?
Your point seems to be that by pretending to lack common sense, you can
prevent yourself from making otherwise sensible judgements. Just
because you work with computers doesn't mean you have to act like one.
- Kevin.
D. Power
<markmc...@spamcop.net> wrote:
> On Wed, 04 Jun 2003 15:09:21 +0100, in comp.lang.c , Chris Dollin
> <ke...@hpl.hp.com> wrote:
>
> >Dan Pop wrote:
> >
> >
> >> And you're dead wrong: you can find bugs
> >> even in the absence of a specification.
> >
> >Nope. Sorry.
>
> I'm fascinated: how _can_ you find bugs without a specification?
<delurk>
Maybe I'm not following the import of your statement here, but doesn't
this program have an obvious bug regardless of specification?
#include <stdio.h>
#include <string.h>
int main (void)
{
char *p;
strcpy (c, "Hello, World!");
printf ("%s\n", c);
return 0;
}
i.e. failing to allocate memory for the pointer? Or am I being dense
and this is not what you mean by a bug?
DP (attempting brain engagement)
</delurk>
--
My real email address is powerd the domain is pcisys DOT net
No matter where you go, there you are.
Richard Heathfield
> In article <s64tdvgeerh9b9n2f...@4ax.com>, Mark McIntyre
> <markmc...@spamcop.net> wrote:
>
>> On Wed, 04 Jun 2003 15:09:21 +0100, in comp.lang.c , Chris Dollin
>> <ke...@hpl.hp.com> wrote:
>>
>> >Dan Pop wrote:
>> >
>> >
>> >> And you're dead wrong: you can find bugs
>> >> even in the absence of a specification.
>> >
>> >Nope. Sorry.
>>
>> I'm fascinated: how _can_ you find bugs without a specification?
>
> <delurk>
>
> Maybe I'm not following the import of your statement here, but doesn't
> this program have an obvious bug regardless of specification?
>
> #include <stdio.h>
> #include <string.h>
>
> int main (void)
> {
> char *p;
> strcpy (c, "Hello, World!");
> printf ("%s\n", c);
> return 0;
> }
>
> i.e. failing to allocate memory for the pointer?
...and failing to define c. :-)
> Or am I being dense
No.
Mark McIntyre
<kar...@acm.org> wrote:
"Dan Pop" <Dan...@cern.ch> wrote in message
>> int main()
>> {
>> char c;
>> puts("Enter a word of your choice:");
>> gets(&c);
>> printf("The word you entered was: %c", c);
>> return 0;
>> }
>>
>> Anyone pretending not to be able to figure out the program's specification
Sure, for such a trivial example, most reasonalby experienced
programmers could determine a likely spec.
But figuring out specs from the code is a bit like determining some
law of physics. Its intelligent guesswork which nevertheless ends up
codifying misunderstandings, measurement errors and personal bias.
For example, Newtons laws seemed a fair spec for quite a while.
>> and its obvious bugs is either deliberately obtuse or Mark McIntyre.
You only demean yourself by these ad hominem attacks. My resolution
for the week is to refrain from response in kind.
<karl M> weirdness snipped
Mark McIntyre
<kevin@-nospam-pcug.org.au> wrote:
>Mark McIntyre <markmc...@spamcop.net> wrote:
>Your point seems to be that by pretending to lack common sense, you can
>prevent yourself from making otherwise sensible judgements. Just
>because you work with computers doesn't mean you have to act like one.
My point is that by assuming that the code documents the requirement
you are hoping that what you /believe/ to be code errors are indeed
so, that the original programmer correctly coded the (lost) spec,
and that your own belief of correctness matches the OP's .
I believe you understand this perfectly, and are just being
difficult. So lets stop the debate.
Mark McIntyre
<pow...@pcisys.net> wrote:
>In article <s64tdvgeerh9b9n2f...@4ax.com>, Mark McIntyre
><markmc...@spamcop.net> wrote:
>
>> On Wed, 04 Jun 2003 15:09:21 +0100, in comp.lang.c , Chris Dollin
>> <ke...@hpl.hp.com> wrote:
>>
>> >Dan Pop wrote:
>> >
>> >
>> >> And you're dead wrong: you can find bugs
>> >> even in the absence of a specification.
>> >
>> >Nope. Sorry.
>>
>> I'm fascinated: how _can_ you find bugs without a specification?
>
><delurk>
>
>Maybe I'm not following the import of your statement here, but doesn't
>this program have an obvious bug regardless of specification?
Maybe the spec said "upon user input, arbitrarily crash"
Sure, this is a pathological case. But there are many much less
obvious cases where what you *believe* to be a bug is in fact correct.
For instance I've seen maintenance programmers insert breaks into code
that used duffs device, in the mistaken belief that the fall through
was a bug.
Kevin Easton
> On Sat, 07 Jun 2003 00:55:14 GMT, in comp.lang.c , Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote:
>
>>Mark McIntyre <markmc...@spamcop.net> wrote:
>
>>Your point seems to be that by pretending to lack common sense, you can
>>prevent yourself from making otherwise sensible judgements. Just
>>because you work with computers doesn't mean you have to act like one.
>
> My point is that by assuming that the code documents the requirement
> you are hoping that what you /believe/ to be code errors are indeed
> so, that the original programmer correctly coded the (lost) spec,
> and that your own belief of correctness matches the OP's .
>
> I believe you understand this perfectly, and are just being
> difficult. So lets stop the debate.
...and my point is that, although you can't know with 100% certainty
that the spec you have deduced is correct, in many cases you can decide
that it is "on the balance of probabilities" correct; or even "beyond a
reasonable doubt".
Anyway, you can't ever know something determined from the world around
you with absolute certainty, since you are always relying on the
evidence provided by your senses at some level. You are reading a
requirements document - how do you know for sure that what you think you
see is what is actually there?
Wake up, Neo.
- Kevin.
Mark McIntyre
<kevin@-nospam-pcug.org.au> wrote:
>Mark McIntyre <markmc...@spamcop.net> wrote:
>> My point is that by assuming that the code documents the requirement
>> you are hoping that what you /believe/ to be code errors are indeed
>> so, that the original programmer correctly coded the (lost) spec,
>> and that your own belief of correctness matches the OP's .
>>
>...and my point is that, although you can't know with 100% certainty
>that the spec you have deduced is correct, in many cases you can decide
>that it is "on the balance of probabilities" correct; or even "beyond a
>reasonable doubt".
oh, sure. But ISTR that the original assertion was that you *never*
need the spec since you can *always* infer it from the code with
complete accuracy. and consequently you can *always* spot all the
bugs. Thats plain wrong. All too often I've seen maintenance
programmers, including myself, erroneously correct "bugs" because we
misinferred the spec.
>Anyway, you can't ever know something determined from the world around
>you with absolute certainty, since you are always relying on the
>evidence provided by your senses at some level. You are reading a
>requirements document - how do you know for sure that what you think you
>see is what is actually there?
Did you remember to feed his cat?
>Wake up, Neo.
Ah, we're in /that/ reality. And I was just wondering if the Vogons
were about to hurl me out an airlock.
Kevin Easton
> On Sun, 08 Jun 2003 03:08:41 GMT, in comp.lang.c , Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote:
>
>>Mark McIntyre <markmc...@spamcop.net> wrote:
>>> My point is that by assuming that the code documents the requirement
>>> you are hoping that what you /believe/ to be code errors are indeed
>>> so, that the original programmer correctly coded the (lost) spec,
>>> and that your own belief of correctness matches the OP's .
>>>
>>...and my point is that, although you can't know with 100% certainty
>>that the spec you have deduced is correct, in many cases you can decide
>>that it is "on the balance of probabilities" correct; or even "beyond a
>>reasonable doubt".
>
> oh, sure. But ISTR that the original assertion was that you *never*
> need the spec since you can *always* infer it from the code with
> complete accuracy. and consequently you can *always* spot all the
> bugs. Thats plain wrong. All too often I've seen maintenance
> programmers, including myself, erroneously correct "bugs" because we
> misinferred the spec.
Well, yes. ISTR that the assertion was that you don't always need a
spec to find bugs; sometimes enough of the spec can be reasonably
inferred from what you have that you can spot some bugs (for some level
of "reasonable").
- Kevin.
Chris Dollin
> Well, yes. ISTR that the assertion was that you don't always need a
> spec to find bugs; sometimes enough of the spec can be reasonably
> inferred from what you have that you can spot some bugs (for some level
> of "reasonable").
The word "obvious was used at some point (clearly I think it was mis-
used). I have no quarrel with "reasonably inferred" and "for some level
of reasonable"; it's just that [my] experience shows that one person's
"obvious" is another persons "implausible". So when someone says
something is "obvious" I expect they're missing something - and when
*I* think something is obvious I'm sure [at least some] other people
don't, and it's entirely likely I'm the one missing something.
--
Chris "obviously not a real hedgehog" Dollin
karl malbrain
> On Fri, 6 Jun 2003 16:15:07 -0700, in comp.lang.c , "karl malbrain"
> <kar...@acm.org> wrote:
>
> "Dan Pop" <Dan...@cern.ch> wrote in message
> >> int main()
> >> {
> >> char c;
> >> puts("Enter a word of your choice:");
> >> gets(&c);
> >> printf("The word you entered was: %c", c);
> >> return 0;
> >> }
> >>
> >> Anyone pretending not to be able to figure out the program's specification
>
> Sure, for such a trivial example, most reasonalby experienced
> programmers could determine a likely spec.
When given the PROPER roadmap issued as COMMENTS, even inexperienced
programmers can determine the FINITE SPECIFICATIONS that surround the
code. Who would allow code to be issued without a mapping is the REAL
question.
> But figuring out specs from the code is a bit like determining some
> law of physics. Its intelligent guesswork which nevertheless ends up
> codifying misunderstandings, measurement errors and personal bias.
> For example, Newtons laws seemed a fair spec for quite a while.
"spec" -- some new BUZZWORD or another? It's FINITE SPECIFICATION.
> >> and its obvious bugs is either deliberately obtuse or Mark McIntyre.
>
> You only demean yourself by these ad hominem attacks. My resolution
> for the week is to refrain from response in kind.
>
> <karl M> weirdness snipped
and re-inserted for the hapless. karl m
pete
>
> Kevin Easton wrote:
>
> > Well, yes. ISTR that the assertion was that you don't always need a
> > spec to find bugs; sometimes enough of the spec can be reasonably
> > inferred from what you have that you can
> > spot some bugs (for some level of "reasonable").
>
> The word "obvious was used at some point (clearly I think it was mis-
> used).
> I have no quarrel with "reasonably inferred" and "for some level
> of reasonable"; it's just that [my] experience shows that one person's
> "obvious" is another persons "implausible". So when someone says
> something is "obvious" I expect they're missing something - and when
> *I* think something is obvious I'm sure [at least some] other people
> don't, and it's entirely likely I'm the one missing something.
I consider a function, which always yields undefined behavior
no matter how it's called, to have a bug.
I don't think that "It's supposed to invoke undefined behavior."
is a good counter argument.
char * memcpy( char * dest, char * src, size_t count )
{
char * curr = dest;
while ( --count >= 0 )
* curr++ = * src++;
return dest;
}
Joel Rees said:
> Incidentally, if you do end up rolling your own, make sure you test
> the end cases as well as the common cases. (I obviously failed to do
> either before I posted my bad examples. My "errors gratis" disclaimer
> covers all code I post, BTW. .-)
How can you say that
that function definition doesn't have an obvious bug ?
Even assuming that the identifiers provide no clues.
Just look at it !
--
pete
Mark McIntyre
<pfi...@mindspring.com> wrote:
>I consider a function, which always yields undefined behavior
>no matter how it's called, to have a bug.
you must have *significant* problems with Real Code (tm) then. :-)
Remember,any code construct not defined in the Standard, such as
direct memory access (common in games and drivers, I believe), 3rd
party libraries (common in, erm, everything), use of hardware-specific
tricks (common in drivers, and probably viruses) , etc is technically
UB.
Out of interest, whats your view on Unspecified Behaviour,
Implementation Defined Behaviour? :=0
(yes, I'm being bloody, but this thread calls for it. Anyone who makes
such sweeping statements* sa have been made is asking for trouble)
* including me
Mark McIntyre
malbrain) wrote:
>When given the PROPER roadmap issued as COMMENTS, even inexperienced
Telephone box, hatstand, BANANA, mrs Flange-Baffle.
When you stop Capitalising words like you were some text book
indicating words to crossreference in the glossary, I'll start reading
your posts again.
>"spec" -- some new BUZZWORD or another? It's FINITE SPECIFICATION.
Yeah, whatever, don't stop taking the dried frog pills, bursar. But
watch out for the shopping trolleys, and for gawds sake don't offer
the Librarian a banana (CapItaLised above for emphasis).
>and re-inserted for the hapless.
snippage is a powerful tool.
karl malbrain
> On 9 Jun 2003 07:23:32 -0700, in comp.lang.c , kar...@acm.org (karl
> malbrain) wrote:
>
> >When given the PROPER roadmap issued as COMMENTS, even inexperienced
>
> Telephone box, hatstand, BANANA, mrs Flange-Baffle.
>
> When you stop Capitalising words like you were some text book
> indicating words to crossreference in the glossary, I'll start reading
> your posts again.
Gee, I never thought of the quantity in that way before. Yes, I
suppose you're right, I've typed about a textbook's worth of material,
haven't I. Some glossary!
> >"spec" -- some new BUZZWORD or another? It's FINITE SPECIFICATION.
>
> Yeah, whatever, don't stop taking the dried frog pills, bursar. But
> watch out for the shopping trolleys, and for gawds sake don't offer
> the Librarian a banana (CapItaLised above for emphasis).
That's BLOXY and I'm afraid he's no longer welcome at Hitachi and he
went back to Russia.
> >and re-inserted for the hapless.
>
> snippage is a powerful tool.
for the hopeful. karl m
pete
>
> On Mon, 09 Jun 2003 12:23:02 -0400, in comp.lang.c , pete
> <pfi...@mindspring.com> wrote:
>
> >I consider a function, which always yields undefined behavior
> >no matter how it's called, to have a bug.
>
> you must have *significant* problems with
> Real Code (tm) then. :-)
Off Topic
> Remember,any code construct not defined in the Standard, such as
> direct memory access (common in games and drivers, I believe), 3rd
> party libraries (common in, erm, everything), use of hardware-specific
> tricks (common in drivers, and probably viruses) , etc is technically
> UB.
The consensus of comp.std.c, is to the contrary:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=131&thl=1261006352,1260581714,1259635171,1259550946,1259378001,1259291945,1258441644,1258362021,1262695350,1262702766,1261889103,1261881500&seekm=3C764FBB.7195%40mindspring.com#link132
char * memcpy( char * dest, char * src, size_t count )
{
char * curr = dest;
while ( --count >= 0 )
* curr++ = * src++;
return dest;
}
How can you say that that function definition
Dan Pop
It's the best *he* can do. He provided ample proof, in this very
newsgroup, over the years.
Dan Pop
>I consider a function, which always yields undefined behavior
>no matter how it's called, to have a bug.
Only if the undefined behaviour has no redeeming benefit(s).
>I don't think that "It's supposed to invoke undefined behavior."
>is a good counter argument.
However, "it's supposed to change the current working directory" is
(usually) a good counter argument. Can you do that in standard C without
invoking undefined behaviour?
Mark McIntyre
<pfi...@mindspring.com> wrote:
>The consensus of comp.std.c, is to the contrary:
but this is CLC, where the language is studied, not the standard.
>char * memcpy( char * dest, char * src, size_t count )
>{
> char * curr = dest;
> while ( --count >= 0 )
> * curr++ = * src++;
> return dest;
>}
>
>How can you say that that function definition
>doesn't have an obvious bug ?
Because I have no clue what its supposed to do. What do you think the
bug is?
>Even assuming that the identifiers provide no clues.
>Just look at it !
Unlike some people, I'm not given to guessing what source code is
supposed to do, unless its the only way. I'm quite quite sure that you
see my point, and are being as anal as I am by now. So no more.
pete
>
> In <3EE4B...@mindspring.com> pete <pfi...@mindspring.com> writes:
>
> >I consider a function, which always yields undefined behavior
> >no matter how it's called, to have a bug.
>
> Only if the undefined behaviour has no redeeming benefit(s).
I now provide context.
I was rerefering to a specific function
which I had previously mentioned upthread.
char * memcpy( char * dest, char * src, size_t count )
{
char * curr = dest;
while ( --count >= 0 )
* curr++ = * src++;
return dest;
}
--
pete
Joe Wright
> On Tue, 10 Jun 2003 09:04:56 -0400, in comp.lang.c , pete
> <pfi...@mindspring.com> wrote:
>
> >The consensus of comp.std.c, is to the contrary:
>
> but this is CLC, where the language is studied, not the standard.
>
> >char * memcpy( char * dest, char * src, size_t count )
> >{
> > char * curr = dest;
> > while ( --count >= 0 )
> > * curr++ = * src++;
> > return dest;
> >}
> >
> >How can you say that that function definition
> >doesn't have an obvious bug ?
>
> Because I have no clue what its supposed to do. What do you think the
> bug is?
>
> >Even assuming that the identifiers provide no clues.
> >Just look at it !
>
> Unlike some people, I'm not given to guessing what source code is
> supposed to do, unless its the only way. I'm quite quite sure that you
> see my point, and are being as anal as I am by now. So no more.
>
bugger just won't quit until something breaks. count is unsigned and
therefore >= 0 always.
Joe
Ben Pfaff
> >char * memcpy( char * dest, char * src, size_t count )
> >{
> > char * curr = dest;
> > while ( --count >= 0 )
> > * curr++ = * src++;
> > return dest;
> >}
> >
> >How can you say that that function definition
> >doesn't have an obvious bug ?
>
> Because I have no clue what its supposed to do.
This is CLC. You should know what a function named memcpy() is
supposed to do. If not, find a reference manual or a copy of the
standard.
> What do you think the bug is?
Any programmer, even one intentionally playing stupid, should be
able to see that a function that always invokes undefined
behavior is buggy.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan
pete
>
> On Tue, 10 Jun 2003 09:04:56 -0400, in comp.lang.c , pete
> <pfi...@mindspring.com> wrote:
>
> >The consensus of comp.std.c, is to the contrary:
>
> but this is CLC, where the language is studied, not the standard.
>
> >char * memcpy( char * dest, char * src, size_t count )
> >{
> > char * curr = dest;
> > while ( --count >= 0 )
> > * curr++ = * src++;
> > return dest;
> >}
> >
> >How can you say that that function definition
> >doesn't have an obvious bug ?
>
> Because I have no clue what its supposed to do. What do you think the
> bug is?
The bug is that the function tries to access memory
outside the address space of the program.
> I'm quite quite sure that you see my point,
Try wearing a tall hat, and maybe no one else will notice it.
--
pete
Dan Pop
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> >char * memcpy( char * dest, char * src, size_t count )
>> >{
>> > char * curr = dest;
>> > while ( --count >= 0 )
>> > * curr++ = * src++;
>> > return dest;
>> >}
>> >
>> >How can you say that that function definition
>> >doesn't have an obvious bug ?
>>
>> Because I have no clue what its supposed to do.
>
>This is CLC. You should know what a function named memcpy() is
>supposed to do. If not, find a reference manual or a copy of the
>standard.
>
>> What do you think the bug is?
>
>Any programmer, even one intentionally playing stupid, should be
>able to see that a function that always invokes undefined
>behavior is buggy.
How about a *genuinely* stupid programmer, like Mark McIntyre?
Mark McIntyre
<b...@cs.stanford.edu> wrote:
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> >char * memcpy( char * dest, char * src, size_t count )
>> >{
>> > char * curr = dest;
>> > while ( --count >= 0 )
>> > * curr++ = * src++;
>> > return dest;
>> >}
>> >
>> >How can you say that that function definition
>> >doesn't have an obvious bug ?
>>
>> Because I have no clue what its supposed to do.
>
>This is CLC. You should know what a function named memcpy() is
>supposed to do.
easy - invoke UB and cause a compilation failure if stdlib.h is
included, otherwise invade the namespace of the Standard Library. :-)
But thats hardly the point is it? What if the fn was prototyped
FOOTYPE frobozz456(UCHP poffle, UCHP paffle, BLOINGE barf);
/now/ is it so easy to be sure what it does?
> If not, find a reference manual or a copy of the standard.
>
>> What do you think the bug is?
>
>Any programmer, even one intentionally playing stupid, should be
>able to see that a function that always invokes undefined
>behavior is buggy.
*shrug*. In that case, no nontrivial code ever written was bugfree.
Consider manipulating the video buffer in MSDOS. Or accessing a
database. Or... the list is literally endless.
Mark McIntyre
<pfi...@mindspring.com> wrote:
>Mark McIntyre wrote:
>> Because I have no clue what its supposed to do. What do you think the
>> bug is?
>
>The bug is that the function tries to access memory
>outside the address space of the program.
but you /still/ haven't proved that the original spec didn't call for
that.
For instance maybe theres a trick of the hardware on which this code
was implemented which allows precisely that sort of access, and the
programmer is making use of that feature. Much as many of us wrote
directly to the video buffer of PCs using a pointer to the relevant
memory area.
>
>> I'm quite quite sure that you see my point,
>
>Try wearing a tall hat, and maybe no one else will notice it.
--
pete
>
> On Wed, 11 Jun 2003 04:35:11 -0400, in comp.lang.c , pete
> <pfi...@mindspring.com> wrote:
>
> >Mark McIntyre wrote:
>
> >> Because I have no clue what its supposed to do.
> >> What do you think the bug is?
> >
> >The bug is that the function tries to access memory
> >outside the address space of the program.
>
> but you /still/ haven't proved that the original spec didn't call for
> that.
Yes I have.
Joel Rees said:
> Incidentally, if you do end up rolling your own, make sure you test
> the end cases as well as the common cases. (I obviously failed to do
> either before I posted my bad examples. My "errors gratis" disclaimer
> covers all code I post, BTW. .-)
Debugging code without a spec, isn't a hypothetical situation;
this is an event that has already happened.
People on this newsgroup, debug code without specs, routinely.
Haven't you ever noticed ?
--
pete
Mark McIntyre
<pfi...@mindspring.com> wrote:
>Mark McIntyre wrote:
>>
>> but you /still/ haven't proved that the original spec didn't call for
>> that.
>
>Yes I have.
post a reference.
>Joel Rees said:
nothing relevant,.
>Debugging code without a spec, isn't a hypothetical situation;
>this is an event that has already happened.
No, really? Ever sucked eggs? I must show you how sometime.
FWIW, me too, on numerous occasions over the last 15 years. That
doesn't mean that I can tell you the spec of the original code, merely
that I can tell you what it does by the time I'm finished "fixing" it.
Thats not the same thing, and if you can't see that, you're frankly
missing an important trick. No, I'll go further, anyone who can't see
the difference is, to quote DP, an Idiot.
>People on this newsgroup, debug code without specs, routinely.
And are they _always_ right? Or do they sometimes misundersstand the
requirement?
>Haven't you ever noticed ?
*sigh*
pete
> On Wed, 11 Jun 2003 20:42:28 -0400, in comp.lang.c , pete
> <pfi...@mindspring.com> wrote:
> >Debugging code without a spec, isn't a hypothetical situation;
> >this is an event that has already happened.
> FWIW, me too, on numerous occasions over the last 15 years.
Then you were trolling when you wrote this in
news:<s64tdvgeerh9b9n2f...@4ax.com>
"I'm fascinated:
how _can_ you find bugs without a specification? "
... which was your post in this thread, which I responded to.
Good job ! You got me !
--
pete
E. Gibbons
>
>My own example was even less ambiguous:
>
> int main()
> {
> char c;
> puts("Enter a word of your choice:");
> gets(&c);
> printf("The word you entered was: %c", c);
> return 0;
> }
>
>Anyone pretending not to be able to figure out the program's specification
Yeah, duh, needs to be %s in the printf() format.
Next time test your code before posting.
--Ben
:)
--
E. Gibbons
pete <pfi...@mindspring.com> wrote:
>Mark McIntyre wrote:
>>
>> On Tue, 10 Jun 2003 09:04:56 -0400, in comp.lang.c , pete
>> <pfi...@mindspring.com> wrote:
>>
>> >The consensus of comp.std.c, is to the contrary:
>>
>> but this is CLC, where the language is studied, not the standard.
>>
>> >char * memcpy( char * dest, char * src, size_t count )
>> >{
>> > char * curr = dest;
>> > while ( --count >= 0 )
>> > * curr++ = * src++;
>> > return dest;
>> >}
>> >
>> >How can you say that that function definition
>> >doesn't have an obvious bug ?
>>
>> Because I have no clue what its supposed to do. What do you think the
>> bug is?
>
>The bug is that the function tries to access memory
>outside the address space of the program.
No, it doesn't.
On my 8-bit microcomputer with 64K of RAM, it runs fine.
I use it as a memory exerciser. "^C to quit".
--Ben
--
pete
> >> >char * memcpy( char * dest, char * src, size_t count )
> >> >{
> >> > char * curr = dest;
> >> > while ( --count >= 0 )
> >> > * curr++ = * src++;
> >> > return dest;
> >> >}
> >The bug is that the function tries to access memory
> >outside the address space of the program.
>
> No, it doesn't.
It doesn't what ?
> On my 8-bit microcomputer with 64K of RAM, it runs fine.
> I use it as a memory exerciser. "^C to quit".
--
pete
Dan Pop
>In article <bbqde3$a9$1...@sunnews.cern.ch>, Dan Pop <Dan...@cern.ch> wrote:
>>
>>My own example was even less ambiguous:
>>
>> int main()
>> {
>> char c;
>> puts("Enter a word of your choice:");
>> gets(&c);
>> printf("The word you entered was: %c", c);
>> return 0;
>> }
>>
>>Anyone pretending not to be able to figure out the program's specification
>>and its obvious bugs is either deliberately obtuse or Mark McIntyre.
>
>Yeah, duh, needs to be %s in the printf() format.
I expected a lot more from you! There are plenty of bugs in this
program, but not this one.
>Next time test your code before posting.
This is the kind of code I'd rather not test before (or even after)
posting ;-)