string splitting

[Ben Pfaff]

BP> File a bug against the FreeBSD manpage then. It's wrong.

Depends on which standard is being referred to, and which function;
strtok() is in fact standard C. The word "standard" may also not be
used in the c.l.c sense of ISO/ANSI standard C, but to refer to the C
library generally shipped with FreeBSD.

I missed the fact that the article I was directly following up
was quoting from the strtok manpage. The article a few layers up
was in fact quoting from the strsep manpage, which also claims
that strsep is in the standard C library. That's the one that
needs a bug report.

 

[Ben Pfaff]

The phrase "Standard C Library" doesn't necessarily imply that the
function is defined by the C standard. Probably "libc" implements
(most of) the functions defined by the C standard, plus some others.

If you call something the Standard C Library then you're just
going to confuse people if it, in fact, isn't just the standard C
library. At least the GNU folks don't call their library the
Standard C Library (they call it the GNU C library).

 

[Yevgen Muntyan]

If you call something the Standard C Library then you're just
going to confuse people if it, in fact, isn't just the standard C
library.

In many situations "Standard C library" is simply a synonym of "libc"
which in turn is a word denoting the C library shipped with the
operating system. May be confusing, indeed.

At least the GNU folks don't call their library the
Standard C Library (they call it the GNU C library).

Perhaps because there is no (real) GNU operating system?

Yevgen

 

[Dik T. Winter]

> The phrase "Standard C Library" doesn't necessarily imply that the
> function is defined by the C standard. Probably "libc" implements
> (most of) the functions defined by the C standard, plus some others.
> (I suspect the math functions are in a different library.)

The man page of the version of Linux I am using has a CONFORMING TO
section:

strtok():
SVr4, POSIX.1-2001, 4.3BSD, C89.
strtok_r():
POSIX.1-2001
strsep():
4.4BSD

 

[Randy Howard]

An inappropriate prototype?
char * strplit(char* str1, char *str2, char * stroriginal,
int split_point)

Namespace violation with strplit() ??

Plus, wouldn't strsplit() make more sense anyway, if you didn't care
about that? How about splitstr() instead?

A purist might also say that stroriginal should be const.

Questions for the OP:
What should be passed in str1, str2, stroriginal and
split_point?

What is the expected behavior if str1 is NULL? If str2 is NULL? If
stroriginal should be NULL?

What is the significance of the return value going to be?

Right. Since you can only return one of them, I wonder what the point
of that is.

As written I suspect that you plan to put the two sub-
strings into the memory pointed to by str1 and str2,
how will your function know that the objects pointed
to by these are large enough to hold the sub-strings?

Indeed.

 

[Randy Howard]

If you call something the Standard C Library then you're just
going to confuse people if it, in fact, isn't just the standard C
library.

Take it up with almost every man page on any UNIX or Linux distro.
This is a very common problem, where all the kitchen sink addons get
stuck in there, and what they mean is really "No additional libraries
need to be included to get this function".

The key point was lower down in the man page posted upthread, where it
said it was in the C standard (incorrectly).

 

[Randy Howard]

Take it up with almost every man page on any UNIX or Linux distro.
This is a very common problem, where all the kitchen sink addons get
stuck in there, and what they mean is really "No additional libraries
need to be included to get this function".

The key point was lower down in the man page posted upthread, where it
said it was in the C standard (incorrectly).

Correction on the last paragraph of my previous post, I read it too
quickly, it was referring to strtok, not strsep in that portion, and in
fact did refer to the portability issue with strsep().

 

[Randy Howard]

I missed the fact that the article I was directly following up
was quoting from the strtok manpage. The article a few layers up
was in fact quoting from the strsep manpage, which also claims
that strsep is in the standard C library. That's the one that
needs a bug report.

It's a convention thing. That top section is indicating that it is in
the "standard" library, in the sense that no additional -lfoo type
incantations are required to link in an extra library. By convention,
man pages like that do not care an iota about ANSI or ISO standards
there, but only in one gets linked without extra effort. The section
near the end of the same man pages usually calls out a source, either
as a version of a UNIX platform first supporting it, POSIX, ISO, or an
add-on library.

 

[CBFalconer]

.... snip ...

The key point was lower down in the man page posted upthread,
where it said it was in the C standard (incorrectly).

One of us is confused. I find strtok in the C standard.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[J. J. Farrell]

Take it up with almost every man page on any UNIX or Linux distro.
This is a very common problem, where all the kitchen sink addons get
stuck in there, and what they mean is really "No additional libraries
need to be included to get this function".

This is a question of history. The term "standard C library" was in
widespread use long before the C Standard came along. As Randy says,
it referred to the library which was searched by default when linking
a C program. There are archived discussions in this newsgroup from
before the Great Renaming (and hence years before the C Standard)
which use it in this way. The definitive write-up about the Internet
Worm of 1988 refers to gets() as a function in the "standard C
library" and goes on to remark that it probably won't go away any time
soon as it's slated to be included in the upcoming C Standard.

The confusion was caused when the Johnny-come-lately C Standard
appeared and usurped the term. The man pages in many UNIXalikes
continue to use the term in its traditional sense, which causes
confusion for those who don't know the history. It's perhaps time the
authors spotted that using "C" and "standard" together might make
readers think they are referring to the C Standard.