gets() - dangerous?

[Chuck F.]

I am confused by this implementation of successive src tests.
Are you expecting it to be possible to set src = (char *)
((NULL) - (int)k) or something? The chances that that means
something on a platform seems pretty low. Why wouldn't you just
hoist out the "if (src)" test? (Attention Edward G. Niles: use
my second sentence to determine *WHY* the C compiler cannot do
the hoist automatically.)

Why are you proposing such undefined behavior operations? No sane
programmer would ever pass such a parameter.

Among other things it caters to passing NULL as the src parameter,
and treats it as an empty string. Download the source for some
implications and requirements. The code has been minimized in
anticipation of embedded system use with non-optimizing compilers.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[websnarf]

Why are you proposing such undefined behavior operations? No sane
programmer would ever pass such a parameter.

Its not me -- its *YOU* by the way you wrote the code. What I am
asking is, why not implement it as:

size_t strlcpy(char *dst, const char *src, size_t sz) {
if (src) {
const char *start = src;
if(sz--) {
while ((*dst++ = *src))
if (sz--) src++;
else {
*(--dst) = '\0';
break;
}
}
while (*src++) continue;
return src - start - 1;
}
else if (sz) *dst = '\0';
return 0;
} /* strlcpy */

This saves you one if(src) test, and you avoid setting start if its not
necessary. Its called "hoisting". Of course this transformation is
technically incorrect if your platform lets you define src = (char *)
((NULL) - (int)k), where k = min(sz,strlen(src)) for some reason
because the two if(src) tests that you do will go in opposite
directions. In other words you would still prefer your implementation
to mine if you need to support that bizarre corner case in what is
otherwise undefined behavior.

Whatever dude, it was just a question. I assumed that as an expert on
"strlcpy" you could elucidate on what I was missing; but as I look at
it again, it seems clear that I am not missing anything.

 

[Chuck F.]

Its not me -- its *YOU* by the way you wrote the code. What I am
asking is, why not implement it as:

size_t strlcpy(char *dst, const char *src, size_t sz) {
if (src) {
const char *start = src;
if(sz--) {
while ((*dst++ = *src))
if (sz--) src++;
else {
*(--dst) = '\0';
break;
}
}
while (*src++) continue;
return src - start - 1;
}
else if (sz) *dst = '\0';
return 0;
} /* strlcpy */

Now that you show the proposed code, I can agree, I think. I would
still have to test the various extreme conditions to be sure. I
looked no further than the ridiculous input parameter suggestion.

At any rate I never worried about a few tests outside the mail
loops. They will happen once per call. I did worry about complex
tests within the loops.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Richard Bos]

Some programming activity (in the real world) have to deal with
code already existing and 'proven to work, not to be touched,
but to be used..'.

Yes, and? Sure, strcpy() can be abused. So can printf().

Richard

 

[Kenny McCormack]

Yes, and? Sure, strcpy() can be abused. So can printf().

Richard

You are the master of the non-sequitor, aren't you?
I bow to your mastery of the technique.

 

[Michael Mair]

You are the master of the non-sequitor, aren't you?

ITYM non-sequitur

-Michael

 

[websnarf]

At about the time of 1/3/2006 5:59 AM, Christian Bau stated the following:

There already is a function that does that: strlcpy and strlcat. The
performance is much higher for strlcpy than for strncpy.

Lol! Its *faster* you say? Don't both of them boil down to:

do {
if ('\0' == (*dst++ = *src) break; /* Toddler: "Are we there
yet?" */
src++;
} while (--count); /* Parent: Watching the road signs */

in their inner loops? (There are tricks you can pull to alias the
count and src decrement/increment that useful in x86 ASM, but it likely
won't make a difference in today's modern OOE architectures.)

I thought strlcpy was just marginally safer than strncpy (because of
its more predictable truncation and termination semantics.) If you
want speed you can't beat memcpy() (and neither can I, because I don't
know the assembly language of every architecture where a C compiler has
been made) and that really *DOES* outperform strcpy, strlcpy and
strncpy (think of it as giving the Toddler a tranquelizer).

The number of iterations through the loop in memcpy does not depend on
the raw string data (i.e., searching for '\0's), but rather an
asynchronous count (which is just sitting in a register somewhere) --
this is a lot better for modern CPUs which prefer parallelism to
dependency after dependency.

 

[Chuck F.]

.... snip ...

I thought strlcpy was just marginally safer than strncpy
(because of its more predictable truncation and termination
semantics.) If you want speed you can't beat memcpy() (and
neither can I, because I don't know the assembly language of
every architecture where a C compiler has been made) and that
really *DOES* outperform strcpy, strlcpy and strncpy (think of
it as giving the Toddler a tranquelizer).

The time problem with strncpy is that it always pads the whole
buffer with '\0', and if the buffer has been filled it won't
bother. strlcpy doesn't go any further than it needs to, and
always terminates the string properly. It also returns the size of
the resultant string, so you don't need to spend time executing strlen.

Look a little deeper than the one routine.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Netocrat]

This reply was delayed as I wanted to complete some development on the
wiki and set up a generic domain name before responding to Steve's post.
The wiki's now accessible through clc-wiki.net.

My first comment is that the question of openness versus control is an
extremely important one. t'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. [...]
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. ...

That's probably true, and we can leave editing unrestricted except for
anonymous edits unless problems occur. Email notification now supports
global creation/change watches, although the patch hasn't been applied
live yet, and we'll probably add category and namespace watches too.

I would urge the proponents of the C Wiki to, as Wikipedia puts it, *be*
*bold* and just do it. [D]on't worry too much about getting the model
and the charter and the editorial board and the voting policy all
perfect before you start.

The suggestion to incorporate something as official (as it has become) as
the c.l.c FAQ seemed to require a more perfectionist approach, but in the
FAQ's absence a good-enough approach should work fine. New features can
be added as needed.

Content's more relevant and some starting content has been imported - the
K&R2 solutions from RJH's unmaintained site:
<http://clc-wiki.net/wiki/KR2_Chapter_Index>
or through the original domain name:
<http://clc.flash-gordon.me.uk/wiki/KR2_Chapter_Index>.

[...]

On the specific question of "seeding" a C Wiki with the comp.lang.c FAQ
list, I'm still of mixed mind. ... [W]hile 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.

The wiki model could support a page owner (a review group of one), and the
stable version of the article would need to be approved by the page owner.
The "unmoderated" edit version would still be viewable, but wouldn't be
shown by default. That's one possibility - for the FAQ you would be the
pages' owner and stable version setter.

At the very least we could certainly seed the FAQ List section of a C
Wiki with the questions from the existing FAQ list ... 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. ...

There's probably not a lot of value in starting a separate version of the
FAQ from scratch bar the question wordings, especially when the current
content of the FAQ is so well-regarded by the c.l.c community. If you
decide not to wikify the FAQ answers, then I think a c.l.c wiki should
avoid the role of a FAQ and focus on other content - your suggestions
below are good ones.

A couple of other notes:

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

It's pretty feature-rich and where we add features we'll contribute them
back to the MediaWiki developers.

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.

Another possibility is portable, peer-reviewed standard library function
implementations - I've noticed a few regulars mentioning personal learning
projects around that theme - anyone interested in contributing/reviewing
code?

Contributions of summaries of useful threads with discussion, code,
improvement processes or realistic portable optimisation examples would
also be welcome, as would personal style guidelines with rationale.

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 your support is much appreciated.

 

[Richard Heathfield]

Netocrat said:

Content's more relevant and some starting content has been imported - the
K&R2 solutions from RJH's unmaintained site:
<http://clc-wiki.net/wiki/KR2_Chapter_Index>

I took a quick look, and I think you've made a good job of this. (It was a
/very/ quick look, but what I saw didn't make me think "oh deary deary me",
so I guess that's a good sign.)

I had been contemplating hoiking the whole thing over to my current site,
but now I will gratefully not bother.

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

I hope I'm right in thinking that you won't allow idiots to undo experts'
changes.

(Steve Summit said)
Agreed. I think this newsgroup is the right place to discuss it, too, if we
wish to avoid the problems Wikipedia faces with quality. And it'll make a
pleasant change from wittering on about void main.

I don't know whether clc-wiki.net aims to restrict itself purely to portable
C. If it doesn't, it will need to institute an apartheid principle to make
it abundantly clear what is portable and what is not, and discussion of the
non-portable bits should be done elsenet.

 

[Netocrat]

Netocrat said:


I took a quick look, and I think you've made a good job of this. (It was
a /very/ quick look, but what I saw didn't make me think "oh deary deary
me", so I guess that's a good sign.)

That's good to know. The changes from html to wiki markup were minor
anyhow - the wiki engine does a good job of presentation.

I had been contemplating hoiking the whole thing over to my current
site, but now I will gratefully not bother.

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)

I hope I'm right in thinking that you won't allow idiots to undo
experts' changes.

As it stands there's nothing to prevent anyone from creating an account
and making changes. Given that there's very little traffic on the wiki
it's easy to monitor all changes though (web/RSS) - so any "idiot undos"
can be shortly reverted. I'm monitoring the site and I presume the other
wiki planners are too; more and expert monitors would be useful.

(Steve Summit said)

Agreed. I think this newsgroup is the right place to discuss it, too, if
we wish to avoid the problems Wikipedia faces with quality. And it'll
make a pleasant change from wittering on about void main. I don't know
whether clc-wiki.net aims to restrict itself purely to portable C.

The wiki's topicality follows from comp.lang.c's - the main difference is
that longer articles are possible and it can present tangential
information such as resource lists. This is slightly unrelated, but I've
just added a "Community And Resources" category and two articles in that
category:
* <http://clc-wiki.net/wiki/Home_Pages>
if you have a c-related home-page and you post to comp.lang.c or are a
committee member, feel free to add it to this list; also if you don't
want to be listed there you can remove yourself
* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson agree
that it fairly describes the newsgroup.

If it doesn't, it will need to institute an apartheid principle to make
it abundantly clear what is portable and what is not, and discussion of
the non-portable bits should be done elsenet.

Any non-portable code/discussion should be as incidental and clearly
demarcated as it generally is in posts to this newsgroup.

 

[Richard Heathfield]

Netocrat said:

Netocrat said:

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)

Oh, I don't mind sticking my oar in, as long as I don't have to get my hands
dirty.

As it stands there's nothing to prevent anyone from creating an account
and making changes.

Um, eesh. Why not just take the brewery keys down to the nearest collection
of park benches?

Given that there's very little traffic on the wiki
it's easy to monitor all changes though (web/RSS) - so any "idiot undos"
can be shortly reverted. I'm monitoring the site and I presume the other
wiki planners are too; more and expert monitors would be useful.

If expert monitors have a really easy way to learn what has been changed,
then that sounds like a plan.

The wiki's topicality follows from comp.lang.c's - the main difference is
that longer articles are possible and it can present tangential
information such as resource lists. This is slightly unrelated, but I've
just added a "Community And Resources" category and two articles in that
category:
* <http://clc-wiki.net/wiki/Home_Pages>
if you have a c-related home-page and you post to comp.lang.c or are a
committee member, feel free to add it to this list; also if you don't
want to be listed there you can remove yourself

Here's a suggestion for you - pop over to
http://www.cpax.org.uk/prg/portable/c/resources.php and steal the entire
page. (Make sure you read it over, though, since some of it won't survive a
change of ownership and will need editing.)

* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson agree
that it fairly describes the newsgroup.

I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem to
think he is), his signal-to-noise ratio is way too low.

 

[Kenny McCormack]

* <http://clc-wiki.net/wiki/Reading_And_Posting_To_comp.lang.c>
this page will be complete when Kenny McCormack and Keith Thompson agree
that it fairly describes the newsgroup.

I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem to
think he is), his signal-to-noise ratio is way too low.[/QUOTE]

As anyone can clearly see, its a lot higher than yours. You are
troll-central.

Just out curiosity, what is your definition of "troll"? What would I have
to do or not do to qualify?

 

[Richard Heathfield]

Kenny McCormack said:

Just out curiosity, what is your definition of "troll"? What would I have
to do or not do to qualify?

Don't worry about it; you're doing just fine.

 

[Netocrat]

Netocrat said:

Netocrat said:

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)

Oh, I don't mind sticking my oar in, as long as I don't have to get my
hands dirty.

Let's keep things clean then - starting with a ban on offensive language.

Um, eesh. Why not just take the brewery keys down to the nearest
collection of park benches?

Yes, I understand that you're skeptical of the open approach, and to a
point I am too (one reason the c.l.c wiki interests me is trying to work
out a middle approach). The key difference here is: once the beer's
drunk, it can't be reclaimed; an edit can be reverted and the "theft"
lasts for only as long as it isn't noticed. That's why I think that a
stable version would work well - the theft isn't visible to the casual
reader but it is to anyone monitoring, particularly the review group.

If expert monitors have a really easy way to learn what has been
changed, then that sounds like a plan.

Let us know if you find a deficiency in the rss/atom feeds:
<http://clc-wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=rss>
<http://clc-wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=atom>

I haven't used a proper rss reader to view them, but their xml view seems
complete - diffs are included.

[...]

Here's a suggestion for you - pop over to
http://www.cpax.org.uk/prg/portable/c/resources.php and steal the entire
page. (Make sure you read it over, though, since some of it won't
survive a change of ownership and will need editing.)

Nice; will copy relevant content.

I fail to see how Kenny McCormack's opinion is relevant, since it's
abundantly clear that, even if he isn't a troll (which most of us seem
to think he is), his signal-to-noise ratio is way too low.

It's similar to saying: I'll be confident in this government pamphlet's
fairness when both the party hacks and the most disaffected opposition
party voters endorse it. If someone who is predisposed to disagree ends
up agreeing, then the chances that you've written something with balance
are pretty good (disagreement wouldn't necessarily mean that the page was
unbalanced).

 

[Kenny McCormack]

Kenny McCormack said:


Don't worry about it; you're doing just fine.

Your previous post left it unclear whether you thought I was or not.

 

[Randy Howard]

Netocrat wrote

Let us know if you find a deficiency in the rss/atom feeds:
<http://clc-
wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=rss

<http://clc-
wiki.net/mediawiki/index.php?title=Special:Recentchanges&feed=ato
m

I just tried the RSS feed in NetNewsWire (Mac OS X) and it seems
to work fine.

I haven't used a proper rss reader to view them, but their xml view seems
complete - diffs are included.

It looks find from here.

BTW, thank you for going to the trouble of putting this up. I
have high hopes for it.

Category suggestion: Homework problems.

It's similar to saying: I'll be confident in this government pamphlet's
fairness when both the party hacks and the most disaffected opposition
party voters endorse it. If someone who is predisposed to disagree ends
up agreeing, then the chances that you've written something with balance
are pretty good (disagreement wouldn't necessarily mean that the page was
unbalanced).

I understand your point. Just keep in mind that contrary to
popular belief, there *are* some insurmountable problems.

 

[Richard Heathfield]

Netocrat said:

Netocrat said:

Could anyone wishing to submit K&R2 exercise solutions or critiques of
existing solutions please do so via clc-wiki.net in future? Thank you.

[SFX: washes hands, a la Pontius Pilate.]

Would a scheme similar to that described in my immediately prior post
encourage you to keep your hand in? (stable version review group)

Oh, I don't mind sticking my oar in, as long as I don't have to get my
hands dirty.

Let's keep things clean then - starting with a ban on offensive language.

Excellent idea. Incidentally, I'm curious to know whether you thought
anything in my reply offensive. I don't recall whether you are a native
English speaker, so, in case you weren't aware of it, "to stick one's oar
in" is a conventional English idiom, meaning "to interpose when not asked",
according to my dictionary. A vicar could happily use it at a Mothers'
Union meeting, without blushing.

If someone who is predisposed to disagree ends
up agreeing, then the chances that you've written something with balance
are pretty good (disagreement wouldn't necessarily mean that the page was
unbalanced).

That could take a while. (If it's any help, most of us here are pretty good
at disagreeing!)

 

[Richard Heathfield]

Kenny McCormack said:

Your previous post left it unclear whether you thought I was or not.

Yes, that's right; it did.

 

[Netocrat]

Netocrat said:

Excellent idea. Incidentally, I'm curious to know whether you thought
anything in my reply offensive.

Not at all. It was a case of one idea leading to another:
hands-not-dirty => keep-things-clean => ban-unclean-language.

I also understand that you have a concern to avoid unclean language, so it
seemed appropriate.

[...]