gets() - dangerous?

[Kenny McCormack]

Kenny McCormack said:


"Pedantry" is just a word used by people who don't care about accuracy to
describe the attitude of those people who do.

Thereby clearly demonstrating that you are in that group of people who
can't tell the difference. Which means this ng is a nice safe padded area
for you.

The claim, however, is incorrect.

I guess we just disagree on (the definition of) that which matters.

P.S. I really don't think the typical Wiki reader gives two hoots about
why you shouldn't cast the return value of malloc(). In this context, that
bit of trivia is just BS.

 

[Richard Bos]

(I wrote)

Luckily, they don't use anything written by MS.


Exactly my point. That's why I said "thank you for playing our (Wikipedia)
game."

Meaning, of course, that Wiki is as untrustworthy as your posts, and Mr.
Heathfield was right all along.

Richard

 

[Walter Roberson]

I was using BASIC long before there were such things as microcomputers
(aka, PCs). *Real* BASIC on *real* computers (w/o PEEK/POKE/etc) was/is
a baby-proof environment.

October 1 1964, Dartmouth, "BASIC", page 1, section I "WHAT IS A PROGRAM?"

A program is a set of directions, a recipie, that is used to provide
an answer to some problem. It usually consists of a set of instructions
to be performed or carried out in a certain order. It starts with the
given data and parameters as the ingredients, and ends up with a
set of answers as the cake. And, as with ordinary cakes, if you make
a mistake in your program, you will end up with something else --
perhaps hash!

http://www.bitsavers.org/pdf/dartmouth/BASIC_Oct64.pdf

Doesn't sound "user-proof" or "baby-proof" to me. Doesn't sound
substantially different than "nasal demons".

Notice that the manual does not define what happens if one uses
an invalid subscript, or attempts to do a MAT operation between
incompatable matrices. Appendix A does list "SUBSCRIPT ERROR",
but catching subscript problems is not given as part of the
language definition.

And even you can see that if you invoke machine language from within BASIC,
well, then you're not programming in BASIC anymore.

But a BASIC that permits such things is not "user-proof".

 

[Malcolm]

A program is a set of directions, a recipie, that is used to provide
an answer to some problem. It usually consists of a set of instructions
to be performed or carried out in a certain order. It starts with the
given data and parameters as the ingredients, and ends up with a
set of answers as the cake. And, as with ordinary cakes, if you make
a mistake in your program, you will end up with something else --
perhaps hash!

No computer programming language can second-guess the programmer and ignore
dangerous or foolish instructions (such as give the least-well performing
employee the biggest bonus).
Humans usually can do this.

 

[Keith Thompson]

P.S. I really don't think the typical Wiki reader gives two hoots about
why you shouldn't cast the return value of malloc(). In this context, that
bit of trivia is just BS.

I usually try to ignore this troll, but I'm going to make an exception
in this case he's spewing dangerous misinformation, at least by
implication.

It may be true that the typical Wiki reader doesn't care why you
shouldn't cast the return value of malloc(). If it is true, it's only
because the typical Wiki reader is ignorant. Wikipedia itself is
one way to cure that ignorance.

The advice not to cast the result of malloc() isn't just a "bit of
trivia". It avoids real errors in real programs, and it's something
that any C programmer needs to understand.

Consider this program:

#include <stdio.h>
#ifdef CORRECT
#include <stdlib.h>
#endif

int main(void)
{
int *ptr = (int*)malloc(sizeof *ptr);
printf("ptr = %p\n", (void*)ptr);
*ptr = 42;
printf("*ptr = %d\n", *ptr);
return 0;
}

When I compile this program on a certain system with "-DCORRECT"
(which has the effect of inserting "#define CORRECT 1" to the top of
the program), the output is:

ptr = 0x6000000000000bc0
*ptr = 42

When I compile the same program without "-DCORRECT", the output is:

ptr = 0xbc0
Segmentation fault

The cast masks a serious error. The compiler warns about "cast to
pointer from integer of different size", but that warning is not
required, and another compiler might compile the dangerously incorrect
code without complaint.

If Kenny thinks that this is an example of the difference between
accuracy and pedantry, he's a fool. But we knew that already.

A note to the regulars of this newsgroup. We know that Kenny is a
troll; he's repeatedly admitted it himself. If you use a killfile,
please add him to it. If you don't, please resist the temptation to
respond to him unless he posts some misinformation that needs to be
corrected. If he doesn't get any attention, perhaps some day he'll go
away and this newsgroup will become a much more pleasant place.

 

[Malcolm]

In the real world, there is a difference between accuracy and pedantry.
I (and most reasonable people, that is, those outside of the so-called
"regulars" in this weird ng) claim that the Wiki article about C is
accurate in the parts that matter. That it doesn't measure up to the
level
of pedantry required of posters in this group is not particularly
relevant.

In the real world, there is a difference between accuracy and pedantry.

This newsgroup is a nice little haven for people who can't tell the
difference.

The problem is that computer's aren't intelligent enough to know the
difference.

I can talk about "the ASCII representation of the number is stored in the
file", and we all know what I mean. But the computer does need to know
whether I mean the ASCII representation or the machine character
representation.

 

[Richard Heathfield]

Richard Bos said:

Mr. Heathfield was right all along.

There's no need to sound quite so surprised.

 

[usenet]

Richard Bos said:


There's no need to sound quite so surprised.

Wow, that's *selective* quoting

 

[Nils Weller]

The advice not to cast the result of malloc() isn't just a "bit of
trivia". It avoids real errors in real programs, and it's something
that any C programmer needs to understand.

Consider this program:

#include <stdio.h>
#ifdef CORRECT
#include <stdlib.h>
#endif

int main(void)
{
int *ptr = (int*)malloc(sizeof *ptr);
printf("ptr = %p\n", (void*)ptr);
*ptr = 42;
printf("*ptr = %d\n", *ptr);
return 0;
}

When I compile this program on a certain system with "-DCORRECT"
(which has the effect of inserting "#define CORRECT 1" to the top of
the program), the output is:

ptr = 0x6000000000000bc0
*ptr = 42

When I compile the same program without "-DCORRECT", the output is:

ptr = 0xbc0
Segmentation fault

The cast masks a serious error. The compiler warns about "cast to
pointer from integer of different size", but that warning is not
required, and another compiler might compile the dangerously incorrect
code without complaint.

Hmm, my own compiler says this about your program:

nils/nwcc_ng [0]> ./nwcc junk.c
junk.c:8: Warning: Incorrect call to `malloc' without declaration,
please `#include <stdlib.h>'
int *ptr = (int*)malloc(sizeof *ptr);
^^^^^^ here
/var/tmp/cpp63.cpp - 0 error(s), 1 warning(s)



(I've been thinking about doing a complete standard library function
catalogue for diagnosing incorrect library calls in the absence of a
prototype or declaration for some time but haven't gotten around to
doing it yet.)

 

[pemo]

The advice not to cast the result of malloc() isn't just a "bit of
trivia". It avoids real errors in real programs, and it's something
that any C programmer needs to understand.

Consider this program:

#include <stdio.h>
#ifdef CORRECT
#include <stdlib.h>
#endif

int main(void)
{
int *ptr = (int*)malloc(sizeof *ptr);
printf("ptr = %p\n", (void*)ptr);
*ptr = 42;
printf("*ptr = %d\n", *ptr);
return 0;
}

When I compile this program on a certain system with "-DCORRECT"
(which has the effect of inserting "#define CORRECT 1" to the top of
the program), the output is:

ptr = 0x6000000000000bc0
*ptr = 42

When I compile the same program without "-DCORRECT", the output is:

ptr = 0xbc0
Segmentation fault

The cast masks a serious error. The compiler warns about "cast to
pointer from integer of different size", but that warning is not
required, and another compiler might compile the dangerously incorrect
code without complaint.

Hmm, my own compiler says this about your program:

nils/nwcc_ng [0]> ./nwcc junk.c
junk.c:8: Warning: Incorrect call to `malloc' without declaration,
please `#include <stdlib.h>'
int *ptr = (int*)malloc(sizeof *ptr);
^^^^^^ here
/var/tmp/cpp63.cpp - 0 error(s), 1 warning(s)



(I've been thinking about doing a complete standard library function
catalogue for diagnosing incorrect library calls in the absence of a
prototype or declaration for some time but haven't gotten around to
doing it yet.)

I love compilers that say 'please' - what are you using?

 

[Keith Thompson]

[some stuff]

[some more stuff]

Please stop feeding the troll. Thank you.

 

[Nils Weller]

Hmm, my own compiler says this about your program:

nils/nwcc_ng [0]> ./nwcc junk.c
junk.c:8: Warning: Incorrect call to `malloc' without declaration,
please `#include <stdlib.h>'
int *ptr = (int*)malloc(sizeof *ptr);
^^^^^^ here
/var/tmp/cpp63.cpp - 0 error(s), 1 warning(s)


[...]

I love compilers that say 'please' - what are you using?

nwcc! http://sourceforge.net/projects/nwcc/ !

But it's sort of incomplete and broken in a lot of ways so I do not
really use it yet.

 

[Steve Summit]

I like C. I read the Wikipedia article on C. It's very anti-C, and clearly
written by someone who doesn't know C well enough to use it properly.

The Wikipedia attitude to C is like that of an amateur cook railing against
the dangers of carving knives, and recommending butter knives for all your
carving needs.

From a comp.lang.c perspective, then, Wikipedia sucks.

I'm working on it.

 

[Richard Heathfield]

Steve Summit said:

I'm working on it.

I tried that, too. It's entirely up to you, of course, but it's hard enough
to generate high quality content in a /neutral/ environment, let alone when
anyone can negate your changes on a whim because they think you're wrong
about, say, main returning int or whatever.

 

[Kenny McCormack]

I'm working on it.

Oh great. Just what we need - another outpost of CLC pedantry.

 

[Steve Summit]

Now that basic support for moderation exists, feedback, particularly from
regulars, and in particular from Steve Summit as FAQ maintainer and
copyright holder, is solicited:
* do you support the proposed charter and model of a limited editorial
group?
* do you support the proposed content guidelines?
* is it acceptable/desirable to host the comp.lang.c FAQ on such a wiki?
* any other issues/concerns.

My first comment is that the question of openness versus control
is an extremely important one. Much virtual ink has been spilled
of late about the alleged unreliability of Wikipedia; that debate
seems to have spilled over even into the sacred, narrow-topic
realm of clc. Clearly it's appallingly irresponsible for
Wikipedia to be openly edited by anyone, even unregistered
anonymous users -- but let's think about that for a moment.

It's also clearly the case that Wikipedia has been as successful
as it has been *because* it can be openly edited by anyone.
It's eminently debatable whether unregistered anonymous users
should have equally free reign, but it's undisputable that
Wikipedia would never have achieved its current momentum if it
had been equipped all along with a proper editorial review board
and article approval process. Wikipedia is as successful as it
is -- and as accurate as it is -- not merely in spite of its open
policies, but because of them.

As I once had occasion to write, "People continue to wish that C
were something it is not, not realizing that if C were what they
thought they wanted it to be, it would never have succeeded and
they wouldn't be using it in the first place." And I think wikis
are much the same.

A C Wiki, with its smaller scope and more constrained subject
matter, could probably get away with a little more control (aka
closedness) than the every-topic-is-fair-game Wikipedia, but I
suspect it will still be important that it be relatively open,
where by "relatively" I mean "more than would seem prudent".
If it is open, yes, it may suffer from some of the same kinds
of transient inaccuracy that Wikipedia is notorious for. But if
it is closely controlled, and no matter how well-intentioned that
control is to prevent vandalism and ill-informed speculation,
the project will be at significant risk of never getting off the
ground at all.

I would urge the proponents of the C Wiki to, as Wikipedia puts
it, *be* *bold* and just do it. I didn't ask for anyone's
permission or support when I started compiling the FAQ list lo
those many years ago, and no one needs permission to start a C
Wiki, either. And, more to the point: don't worry too much about
getting the model and the charter and the editorial board and the
voting policy all perfect before you start. There's another
analogy to trot out here, equally if not more applicable in the
context of C, namely: Richard P. Gabriel's old dichotomy between
"MIT" and "New Jersey", the infamous "Worse is Better" philosophy.
If you have a good idea, set it free and let it run. If it's a
truly good idea, it will thrive under this freedom and become
better than you ever imagined. If it founders, perhaps it wasn't
such a good idea anyway, and in any case, it probably wouldn't
have fared any better under too-tight control, either.

On the specific question of "seeding" a C Wiki with the
comp.lang.c FAQ list, I'm still of mixed mind. On the one hand I
do hold the copyright and can do almost anything I want with the
content, but on the other hand Addison Wesley also has a vested
interest and a particular copyright notice they'd like to retain,
so it probably won't be possible to just release the whole FAQ
list under the GFDL. But I'd like to see if we can do something,
because while on the one hand I am (I confess) still possessive
enough about the thing that I'll have some qualms about throwing
it open for anyone to edit, on the other hand I've been wondering
how I'm ever going to cede control over it, since I don't
maintain it as actively as I once did and I'm certainly not going
to maintain it forever. I've been wondering if it's time to fork
it, and doing so in the context of a C Wiki might be just the
thing.

At the very least we could certainly seed the FAQ List section
of a C Wiki with the questions from the existing FAQ list,
bidirectionally cross-referenced with the "static" answers
I maintain, with the more dynamic, Wiki-side answer sections
serving to amplify or annotate or extend or eventually supplant
the static ones. But that would be kind of an awkward split, and
I can probably see my way clear to having the Wiki-side answers
seeded with the existing static answer text also, as long as it's
possible to tag those pages with a different, non-GFDL copyright
notice. I'll keep thinking about this, and maybe raise the
question with the editors I've been talking with at Addison
Wesley lately.

A couple of other notes:

I'm glad to see the Wikimedia software being used, rather than
something being written from scratch!

They're hinted at in the existing topic outline, but it would be
lovely to have a collaboratively written, Wiki-mediated language
tutorial, a language reference manual, and a library reference
manual in there, too.

At any rate, let's see some more discussion about the Wiki idea!
I think it has a lot of promise, which is why I'm blathering at
length about it in this public post, rather than just sending an
email reply to Netocrat.

Steve Summit
(e-mail address removed)

 

[Flash Gordon]

Steve, first off thank you for your support in this.

My first comment is that the question of openness versus control
is an extremely important one. Much virtual ink has been spilled

A C Wiki, with its smaller scope and more constrained subject
matter, could probably get away with a little more control (aka
closedness) than the every-topic-is-fair-game Wikipedia, but I
suspect it will still be important that it be relatively open,
where by "relatively" I mean "more than would seem prudent".
If it is open, yes, it may suffer from some of the same kinds
of transient inaccuracy that Wikipedia is notorious for. But if
it is closely controlled, and no matter how well-intentioned that
control is to prevent vandalism and ill-informed speculation,
the project will be at significant risk of never getting off the
ground at all.

There is always the option of having things wide open initially and
tightening up control if it becomes a problem. My biggest reservations
are about anonymous editing, but I'm only one voice.

I would urge the proponents of the C Wiki to, as Wikipedia puts
it, *be* *bold* and just do it. I didn't ask for anyone's

<snip>

Well, the site is up and running and people are welcome to create
accounts and start editing.

On the specific question of "seeding" a C Wiki with the
comp.lang.c FAQ list, I'm still of mixed mind. On the one hand I
do hold the copyright and can do almost anything I want with the
content, but on the other hand Addison Wesley also has a vested
interest and a particular copyright notice they'd like to retain,
so it probably won't be possible to just release the whole FAQ
list under the GFDL.

I would be happy to add statements like, "The initial content of this
page is copyright Steve Summit with modifications under the GFDL. See
http://c-faq.com/ for the original."

We could also include on the page footer something like, "This site has
been seeded from the C FAQ, copyright Steve Summit, See
http://c-faq.com/ for Steve's work". This could be put in such that it
is impossible for it to be edited.

At the very least we could certainly seed the FAQ List section
of a C Wiki with the questions from the existing FAQ list,
bidirectionally cross-referenced with the "static" answers
I maintain, with the more dynamic, Wiki-side answer sections
serving to amplify or annotate or extend or eventually supplant
the static ones. But that would be kind of an awkward split, and
I can probably see my way clear to having the Wiki-side answers
seeded with the existing static answer text also, as long as it's
possible to tag those pages with a different, non-GFDL copyright
notice. I'll keep thinking about this, and maybe raise the
question with the editors I've been talking with at Addison
Wesley lately.

Indeed. I'm sure something mutually acceptable can be arranged.

One other thing we could do, if you are willing, if have you point
sometime like wiki.c-faq.com at the site. I would have to do a small
edit to my Apache configuration to support it, but it would put the
domain in to hands rather better known than mine.

A couple of other notes:

I'm glad to see the Wikimedia software being used, rather than
something being written from scratch!

We are SW developers, so we are lazy by nature ;-)

They're hinted at in the existing topic outline, but it would be
lovely to have a collaboratively written, Wiki-mediated language
tutorial, a language reference manual, and a library reference
manual in there, too.

Yes, those are all good ideas.

At any rate, let's see some more discussion about the Wiki idea!
I think it has a lot of promise, which is why I'm blathering at
length about it in this public post, rather than just sending an
email reply to Netocrat.

Thanks again for your support.

 

[Giannis Papadopoulos]

In my turn, I also thank you for having such a positive stance for a
wannabe c.l.c wiki.

My first comment is that the question of openness versus control
is an extremely important one. Much virtual ink has been spilled
of late about the alleged unreliability of Wikipedia; that debate
seems to have spilled over even into the sacred, narrow-topic
realm of clc. Clearly it's appallingly irresponsible for
Wikipedia to be openly edited by anyone, even unregistered
anonymous users -- but let's think about that for a moment.

It's also clearly the case that Wikipedia has been as successful
as it has been *because* it can be openly edited by anyone.
It's eminently debatable whether unregistered anonymous users
should have equally free reign, but it's undisputable that
Wikipedia would never have achieved its current momentum if it
had been equipped all along with a proper editorial review board
and article approval process. Wikipedia is as successful as it
is -- and as accurate as it is -- not merely in spite of its open
policies, but because of them.

Although openness would be a major benefit, we ought to think about
people that think they know C, and might try to contribute, whereas they
are propagating errors and misunderstandings.

In Wikipedia it works, because it has many editors, maybe more than a
language-specific wiki (such as the proposed one) will ever have. So a
more restrictive stance seems to be the way to go, at least for the time
being. However, no rule is meant to last for ever.

Moreover, your C FAQ has reached another level of perfection - after so
many years of dedication, corrections and additions - and it would be
very precarious to leave it open for everyone.

A C Wiki, with its smaller scope and more constrained subject
matter, could probably get away with a little more control (aka
closedness) than the every-topic-is-fair-game Wikipedia, but I
suspect it will still be important that it be relatively open,
where by "relatively" I mean "more than would seem prudent".
If it is open, yes, it may suffer from some of the same kinds
of transient inaccuracy that Wikipedia is notorious for. But if
it is closely controlled, and no matter how well-intentioned that
control is to prevent vandalism and ill-informed speculation,
the project will be at significant risk of never getting off the
ground at all.

However, if it manages to get off the ground IMHO it would be a major
contribution.. And I think it worths the risk.

On the specific question of "seeding" a C Wiki with the
comp.lang.c FAQ list, I'm still of mixed mind. On the one hand I
do hold the copyright and can do almost anything I want with the
content, but on the other hand Addison Wesley also has a vested
interest and a particular copyright notice they'd like to retain,
so it probably won't be possible to just release the whole FAQ
list under the GFDL. But I'd like to see if we can do something,
because while on the one hand I am (I confess) still possessive
enough about the thing that I'll have some qualms about throwing
it open for anyone to edit, on the other hand I've been wondering
how I'm ever going to cede control over it, since I don't
maintain it as actively as I once did and I'm certainly not going
to maintain it forever. I've been wondering if it's time to fork
it, and doing so in the context of a C Wiki might be just the
thing.

We can search some other ways to have GNU FDL and copyrighted material
in the same place. I don't think that this is out of the question. It
could, for example, have the copyrighted C FAQ question and answer, and
after that the FDL part that either complements the answer or gives
other directions, hints etc.

At the very least we could certainly seed the FAQ List section
of a C Wiki with the questions from the existing FAQ list,
bidirectionally cross-referenced with the "static" answers
I maintain, with the more dynamic, Wiki-side answer sections
serving to amplify or annotate or extend or eventually supplant
the static ones. But that would be kind of an awkward split, and
I can probably see my way clear to having the Wiki-side answers
seeded with the existing static answer text also, as long as it's
possible to tag those pages with a different, non-GFDL copyright
notice. I'll keep thinking about this, and maybe raise the
question with the editors I've been talking with at Addison
Wesley lately.

FDL is extremely versatile. I am not a lawyer or a patent-guy, but I
think that after some careful discussion, there might be a way.

A couple of other notes:

I'm glad to see the Wikimedia software being used, rather than
something being written from scratch!

It is tested and it works and it is now the heart of the c.l.c wiki
thanks to Netocrat and Flash Gordon.

They're hinted at in the existing topic outline, but it would be
lovely to have a collaboratively written, Wiki-mediated language
tutorial, a language reference manual, and a library reference
manual in there, too.

Yes, that would be nice.. However, the main focus is the FAQ (the first
step is the start for even the longest journey - isn't that a chinese
saying?) just because currently there aren't many people involved...

 

[Al Balmer]

There is always the option of having things wide open initially and
tightening up control if it becomes a problem. My biggest reservations
are about anonymous editing, but I'm only one voice.

I recently read about a new wiki-style encyclopedia which is in the
works. They are using a two-tiered system, as I understand it. There
are invited articles written by experts in a particular field. The
article are identified as being authoritative, and editing is
restricted. However, anyone is free to add and edit other entries on
the same subject. Perhaps something like this would be appropriate.

(Sorry I don't have a reference to the new encyclopedia.)

 

[Jordan Abel]

Jordan Abel said:

Such as? (Yes, he's a troll, but you haven't given any specific examples
of facts claimed that are false, and the article really doesn't look to
me as bad as you claim it is)

I've already pointed out several faults with the lead article.

Observe the first program example on this page:

<http://en.wikipedia.org/wiki/C_syntax>

Further down this page, it gives the following example program:

void setInt(int **p, int n)
{
*p = (int *) malloc(sizeof(int)); // allocate a memory area, using
the pointer given as as a parameter [1]

**p = n;
}

Other than wrapping you introduced, this example looks syntactically
correct, which is what the article's about - and anyway why don't you
fix it - I'm sure that an expert like you working on the article would
be very helpful

int main(void)
{
int *p; // create a pointer to an integer
setInt(&p, 42); // pass the address of 'p'
return 0;
}

[1] Originally presented as a single line.

If this is C90 code, count the bugs.
If it's C99 code instead, count the bugs.

Other than the comments, i don't see any c90 bugs. i don't see any c99
bugs at all. and there certainly are no syntax errors. It's a bit of a
contrived example, but the only real problem with it is the cast [and
the lack of inclusion of stdlib, but it's arguably a mere code snippet,
rather than a complete source file

the more serious problem is that it says "<data-type> varN" - which
implies that it's int[42] a instead of int a[42] to declare an array of
42 ints.