How to learn C ?

[pete]

Re: How to learn C ?

Harald van Dijk wrote:

On Thu, 26 Jun 2008 16:29:01 +0000, Richard Tobin wrote:

>In article <lzabh8tbsg.fsf @stalkings.ghot i.net>, Keith Thompson
><kst-u@mib.orgwrote:

>>Chuck's page, if I recall correctly, has *implementation s* in standard C
>>of these two functions (which are not specified in the C standard).

>I detect a failure of pedantry. Since identifiers beginning with "str"
>and a lower-case letter are reserved, there cannot be an implementation
>of strlcpy() in standard C :-)

>
Assuming <string.his not included, a user function by that name is
permitted if it is declared static. :)

It doesn't matter whether or not <string.his included.

N869
7.26 Future library directions

[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

7.26.10 General utilities <stdlib.h>

[#1] Function names that begin with str and a lowercase
letter (possibly followed by any combination of digits,
letters, and underscore) may be added to the declarations in
the <stdlib.hheader .


--
pete

[pete]

Re: How to learn C ?

Keith Thompson wrote:

pete <pfiland@mindsp ring.comwrites:

>Nick Keighley wrote:
>>

>>for pedants

>;)
>>

>>[1] "string" means C string. That is a sequence of charcaters
>>terminated by a nul character.
>>[2] a string function is one that operates on strings

>A string function is one which is described in <string.h>,
>as being useful for manipulating arrays of character type
>and other objects treated as arrays of character type.
>>
>The mem* functions, are also string functions.
>>
>N869
> 7.21 String handling <string.h>
> 7.21.1 String function conventions
> [#1]
> Various methods are used for
> determining the lengths of the arrays,
> but in all cases a char * or void * argument
> points to the initial (lowest addressed)
> character of the array.

>
I disagree, in spite of the fact that the standard strongly implies
that all the functions in <string.hare "string functions".
>
The standard provides rigorous defintions of the terms "string" and
"function". It does not provide a definition of the term "string
function". The mem* functions are declared in <string.hfor
convenience and consistency with historical practice. Nick's
definition of "string function" is much more reasonable than the one
implicitly used by the standard, and more consistent with the terms
that the standard does define.
>
Of course you're free to disagree (and agree with the standard), but I
suggest that the term "string function" is at least ambiguous, and we
should be careful to clarify what we mean by it (as Nick did above).

It's not just what the standard suggests.

It's also what Ritchie and Kernighan wrote plainly.

K&R2, Section B3, says unambiguously:

"There are two groups of string functions
defined in the header <string.h>.
The first have names beginning with str;
the second have names beginning with mem."


--
pete

[CBFalconer]

Re: How to learn C ?

Richard Heathfield wrote:

>

.... snip carping about strlcpy ...

>
The header is not C90-conforming, since it introduces illegal
syntax if the implementation has defined the __cplusplus macro.
(Strictly, it's not C99-conforming either, since ISO/IEC
9899:1999 says that "The implementation shall not predefine the
macro _ _cplusplus, nor shall it define it in any standard
header", but that's really just a bug in the C99 document.)

No it isn't. strlcpy.h is not part of the implementation. That
provision in the header is simply a general practice that allows
the code to be called from C++ programs. I gather you disapprove
of that capability.

>
The code for strlcpy (I didn't look at strlcat) looks rather flaky
to me, although I'd be glad to be reassured that my interpretation
is mistaken. If we pass an empty string, say "" or calloc(1, 1),
for src and a value of sz 1 (an erroneous input state that could
easily occur and easily be detected), then src ends up pointing
outside owned memory. Sure, you can point outside owned memory
with strcpy too (albeit for dst rather than src), but I would have
thought a "safe strcpy" ought to be safe, wouldn't you?

It works. I guess that source was too complex for you. You
apparently did not recognize that defining TESTING compiles a
testing sequence. The occurance of "ifdef TESTING" just after the
four line function for strlcat should have alerted you. I added
one line to main (on my machine) to ensure that this article is
accurate.

That module has been published several times here in c.l.c since
2003, and you have had lots of opportunity to criticize it before.
Now you decide to generate false criticisms. I wonder why.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Re: How to learn C ?

Harald van D?k wrote:

CBFalconer wrote:

>Richard Bos wrote:

>>CBFalconer <cbfalconer@yah oo.comwrote:
>>>
>>>Look up strspam and strspammy. You can find them on my page.
>>>
>>Yes, jacob, we know.

>>
>You are committing the henious Usenet crime of seriously altering
>allegedly quoted material. I never wrote anything of that nature.
>I thought you were a more reliable contributor.

>
You wrote, and this is an exact quote:
>
"Look up strlcpy and strlcat. You can find them on my page."
>
Richard Bos did not "seriously alter" the quoted material. He
removed what he considered (seriously or not -- I don't know) spam,
and made a clear indication of this. This is obvious to me, and if
it was also obvious to you (I don't see how it can't be, but I'm
willing to give you the questionable benefit of the doubt), your
own message is a flat out lie and serious accusation to someone
who did nothing to deserve that.

No, he altered the quote, with NO indication that he had altered
it. If he had left the quote and added his altered version, I
would not be seriously annoyed. There was no clear indication of
anything.

We now know that we cannot trust the accuracy of any quotations in
messages from Richard Bos.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Keith Thompson]

Re: How to learn C ?

CBFalconer <cbfalconer@yah oo.comwrites:

Harald van D?k wrote:

CBFalconer wrote:

Richard Bos wrote:
>CBFalconer <cbfalconer@yah oo.comwrote:
>>
>>Look up strspam and strspammy. You can find them on my page.
>>
>Yes, jacob, we know.
>
You are committing the henious Usenet crime of seriously altering
allegedly quoted material. I never wrote anything of that nature.
I thought you were a more reliable contributor.

You wrote, and this is an exact quote:

"Look up strlcpy and strlcat. You can find them on my page."

Richard Bos did not "seriously alter" the quoted material. He
removed what he considered (seriously or not -- I don't know) spam,
and made a clear indication of this. This is obvious to me, and if
it was also obvious to you (I don't see how it can't be, but I'm
willing to give you the questionable benefit of the doubt), your
own message is a flat out lie and serious accusation to someone
who did nothing to deserve that.

>
No, he altered the quote, with NO indication that he had altered
it. If he had left the quote and added his altered version, I
would not be seriously annoyed. There was no clear indication of
anything.
>
We now know that we cannot trust the accuracy of any quotations in
messages from Richard Bos.

What Richard did was rude, and it's certainly not something I would
have done. But it was clear enough, at least to me, that he wasn't
being deliberately deceptive.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: How to learn C ?

CBFalconer <cbfalconer@yah oo.comwrites:

Richard Heathfield wrote:

[...]

The code for strlcpy (I didn't look at strlcat) looks rather flaky
to me, although I'd be glad to be reassured that my interpretation
is mistaken. If we pass an empty string, say "" or calloc(1, 1),
for src and a value of sz 1 (an erroneous input state that could
easily occur and easily be detected), then src ends up pointing
outside owned memory. Sure, you can point outside owned memory
with strcpy too (albeit for dst rather than src), but I would have
thought a "safe strcpy" ought to be safe, wouldn't you?

>
It works. I guess that source was too complex for you. You
apparently did not recognize that defining TESTING compiles a
testing sequence. The occurance of "ifdef TESTING" just after the
four line function for strlcat should have alerted you. I added
one line to main (on my machine) to ensure that this article is
accurate.

Huh? Richard didn't say anything about the TESTING macro, and I saw
no indication, either in what he posted or in what you quoted, that he
had any difficulty understanding it.

His complaint, to paraphrase, was that strlcpy() is unsafe if the size
argument exceeds the actual size of the array pointed to by the
destination argument. (I don't agree that that's a real problem.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Re: How to learn C ?

CBFalconer said:

Richard Heathfield wrote:

>>

... snip carping about strlcpy ...

>>
>The header is not C90-conforming, since it introduces illegal
>syntax if the implementation has defined the __cplusplus macro.
>(Strictly, it's not C99-conforming either, since ISO/IEC
>9899:1999 says that "The implementation shall not predefine the
>macro _ _cplusplus, nor shall it define it in any standard
>header", but that's really just a bug in the C99 document.)

>
No it isn't. strlcpy.h is not part of the implementation.

Firstly, only an implementation (i.e. a translator/library pair) has
licence to define strlcpy (because the name is reserved for the
implementation) . But secondly, you appear to have missed my point. I
haven't claimed that you defined __cplusplus. I'm claiming that, if the
implementation (i.e. the software that a user uses to compile your code)
has defined __cplusplus, your code will fail to compile. Allow me to
demonstrate, by pretending that gcc defines __cplusplus (I know it doesn't
- I'm just demonstrating what would happen if it did):

me@heregcc -D__cplusplus=1 -o strlcpy.o -c strlcpy.c
In file included from strlcpy.c:16:
strlcpy.h:6: parse error before string constant
In file included from strlcpy.c:16:
strlcpy.h:37: parse error before `}'

In C99, of course, that objection is moot, since C99 requires the
implementation not to define that macro (or at least that's what it means
to require - whether the doc actually says that depends on how picky we
are, I guess).

That
provision in the header is simply a general practice that allows
the code to be called from C++ programs. I gather you disapprove
of that capability.

No, I don't disapprove of being able to call C code from C++ code, but I do
disapprove of polluting C code unnecessarily.

The provision of this C++ header makes your hack unnecessary:

/* strlcpy.hpp */
#ifndef HPP_STRLCPY
#define HPP_STRLCPY 1
extern "C"
{
#include "strlcpy.h"
}
#endif

This way, you get the best of both worlds - C code that is robust in the
face of unusual but nevertheless conforming implementations , *and*
accessibility from C++.

>The code for strlcpy (I didn't look at strlcat) looks rather flaky
>to me, although I'd be glad to be reassured that my interpretation
>is mistaken. If we pass an empty string, say "" or calloc(1, 1),
>for src and a value of sz 1 (an erroneous input state that could
>easily occur and easily be detected), then src ends up pointing
>outside owned memory. Sure, you can point outside owned memory
>with strcpy too (albeit for dst rather than src), but I would have
>thought a "safe strcpy" ought to be safe, wouldn't you?

>
It works.

Perhaps it does. I could easily be mistaken, after all.

I guess that source was too complex for you.

Perhaps it was. You claim the source is safe. I'd like to believe you.
Could you please demonstrate why you think it is safe? Specifically, can
you show why src and dst always point somewhere legal, no matter what the
inputs (given that they point somewhere legal at entry)?

You may find that explaining this to me leads you to write a clearer
version of the code.

You
apparently did not recognize that defining TESTING compiles a
testing sequence.

I didn't even look at your testing code. You are chasing a strawman. I was
talking about your strlcpy code, not your testing code.

That module has been published several times here in c.l.c since
2003, and you have had lots of opportunity to criticize it before.

My attitude towards so-called "safe" string functions is well-documented.

Now you decide to generate false criticisms. I wonder why.

I might be mistaken, in which case please point out the mistake, but there
is a huge difference between criticising erroneously and criticising
falsely, and you would do well to keep that in mind.

So - if I'm wrong, please show me why. If it helps, pretend (and this might
not be too hard for you to imagine) that you're explaining to a newbie
*why* the code is robust.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[mike.rosset+gnus@gmail.com]

Re: How to learn C ?


Thank you I'm glad someone else noticed that this is c.l.c. And that yes
it might be important to suggest something is not standard to someone
new.

But this need to endlessly debate standard C, is IMO the wrong group to
do it in.

If people go back and read threads like this, all with topic's like "How
to learn C". How do topics like this break down into debates about the C
standard?


Mike.

[lawrence.jones@siemens.com]

Re: How to learn C ?

Richard Heathfield <rjh@see.sig.in validwrote:

>
My quote is exact. The C99 Standard literally *does not mention* a
__cplusplus macro. Instead, it refers to a _ _cplusplus macro. But macro
names cannot contain spaces. That's a bug in the Standard document. (The
intent is clear but the transcription is imprecise.)

The Standard has a thin space between the underscores to ensure that
they are visually distinct in the printed version. Tools that search
the PDF file and/or convert it to ASCII vary in their treatment of such
thin spaces, but the expectation is that they should be ignored.

-- Larry Jones

Who, ME? Who?! Me?? WHO... Me?! Who, me??? -- Calvin

[Richard Heathfield]

Re: How to learn C ?

lawrence.jones@ siemens.com said:

Richard Heathfield <rjh@see.sig.in validwrote:

>>
>My quote is exact. The C99 Standard literally *does not mention* a
>__cplusplus macro. Instead, it refers to a _ _cplusplus macro. But macro
>names cannot contain spaces. That's a bug in the Standard document. (The
>intent is clear but the transcription is imprecise.)

>
The Standard has a thin space between the underscores to ensure that
they are visually distinct in the printed version. Tools that search
the PDF file and/or convert it to ASCII vary in their treatment of such
thin spaces, but the expectation is that they should be ignored.

The expectation is not met by either xpdf or pdftotext. (gv doesn't have a
search option as far as I can tell.) And the behaviour of these tools was
well-established at the time that the Standard was prepared.

-- Larry Jones
>
Who, ME? Who?! Me?? WHO... Me?! Who, me???

IIRC, yes, you. :-)

-- Calvin

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[lawrence.jones@siemens.com]

Re: How to learn C ?

Richard Heathfield <rjh@see.sig.in validwrote [quoting me]:

Tools that search
the PDF file and/or convert it to ASCII vary in their treatment of such
thin spaces, but the expectation is that they should be ignored.

>
The expectation is not met by either xpdf or pdftotext. (gv doesn't have a
search option as far as I can tell.) And the behaviour of these tools was
well-established at the time that the Standard was prepared.

Such is life; it's easily worked around once you know about it. For
what it's worth, Acrobat Reader (8.1.2) drops the thin spaces when
converting to text (although it leaves a lot to be desired in other
ways), but it doesn't ignore it when searching. I'll see if I can tweak
it to work better in the future.

-- Larry Jones

Who, ME? Who?! Me?? WHO... Me?! Who, me???

>
IIRC, yes, you. :-)

You do recall correctly (drat it). :-)

-- Larry Jones

Monopoly is more fun when you make your own Chance cards. -- Calvin

[Kenny McCormack]

Re: How to learn C ?

In article <87skuxabrx.fsf @gmail.com>, <mike.rosset+gn us@gmail.comwro te:

>
>Thank you I'm glad someone else noticed that this is c.l.c. And that yes
>it might be important to suggest something is not standard to someone
>new.
>
>But this need to endlessly debate standard C, is IMO the wrong group to
>do it in.
>
>If people go back and read threads like this, all with topic's like "How
>to learn C". How do topics like this break down into debates about the C
>standard?

Because its all they know. Well, that and how to prototype main().
And, of course, whether or not to cast the return value of malloc().

[Kenny McCormack]

Re: How to learn C ?

In article <48653C95.728BE 880@yahoo.com>,
CBFalconer <cbfalconer@mai neline.netwrote :
.... (blah, blah, blah)

>That module has been published several times here in c.l.c since
>2003, and you have had lots of opportunity to criticize it before.
>Now you decide to generate false criticisms. I wonder why.

It couldn't happen to a nicer guy.

[Kenny McCormack]

Re: How to learn C ?

In article <g42bdk$4f0$1@r enpen.nelsonbe. com>,
Bob Nelson <bnelson@nelson be.comwrote:
....

>Thus when someone asks something in c.l.c concerning, for instance, network
>sockets, I think the appropriate reply is:
>
``That doesn't exist in C.''
>
>Period. Paragraph. EOF. The implication is that C is standard C, which is
>the ONLY acceptable discussion topic here (aside from the matter of
>topicality itself).

The real question here is: Whose sock puppet is this "Bob Nelson"
character?

[Richard]

Re: How to learn C ?

Bob Nelson <bnelson@nelson be.comwrites:

Keith Thompson wrote:
>

>Richard Heathfield <rjh@see.sig.in validwrites:

>>CBFalconer said:
>pete wrote:
>>vippstar@gmail. com wrote:
>>>>
>>>Take this for example
>>><http://www.cprogrammin g.com/tutorial/c/lesson9.html>
>>>
>>[...]
>>>
>>Also, I am against "strncpy is a safer strcpy".
>>
>Look up strlcpy and strlcat.
>>>
>>I did. They don't exist.

>>
>By "They don't exist", I presume you mean "They're non-standard". The
>do in fact exist.

>
<OT meta="...but to the point of the disagreement">
Think of the classic diagnostic message for some *nix applications:
>
``You don't exist, go away.''
>
Obviously the entity viewing the message does indeed exist but in the
absence of proper credentials, the text of the message is accurate.
</OT>
>
In this newsgroup, I think it's not a stretch at all to deny the existence
of entities unless they are defined by the international standard for the C
language.
>
As an admitted hard-liner, I actually object to the qualified usage of the
term ``standard C''. It is either C or not. Within c.l.c., standard C == C.
My personal fundamentalist viewpoint is such that if someone contends that
the ``ls'' (or ``dir'' or some form of directory listing) program is
written in C, they are wrong in that assertion. Once the translation unit
is ``tainted'' by an inclusion of a ``system'' header not among those
enumerated by the ISO 9899:1999 document (including current TR), the
translation unit is something other than C.
>
Thus when someone asks something in c.l.c concerning, for instance, network
sockets, I think the appropriate reply is:
>
``That doesn't exist in C.''
>
Period. Paragraph. EOF. The implication is that C is standard C, which is
the ONLY acceptable discussion topic here (aside from the matter of
topicality itself).

And having read this rubbish, my assertion is that you're more
interested in showing off than helping people.

Many questions here which involve, say sockets, come down to a
fundamental C issue.