string splitting
Andrea
char * strplit(char* str1, char *str2, char * stroriginal,int
split_point)
that take stroriginal and split in the split_point element of the
string the string into two other strings,
example:
"Hello World"
i want to split this string into "Hello " "World"
thanks in advance,
andrea
Richard Heathfield
What's stopping you? What have you tried? (And with whom lies the
responsibility for storage allocation - the caller or the splitter?)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Ian Malone
> Andrea said:
>
>> I want to write a program that:
>>
>> char * strplit(char* str1, char *str2, char * stroriginal,int
>> split_point)
>>
>> that take stroriginal and split in the split_point element of the
>> string the string into two other strings,
>>
>> example:
>>
>> "Hello World"
>> i want to split this string into "Hello " "World"
>
> What's stopping you?
An inappropriate prototype?
char * strplit(char* str1, char *str2, char * stroriginal,
int split_point)
Questions for the OP:
What should be passed in str1, str2, stroriginal and
split_point? What is the significance of the return
value going to be?
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?
--
imalone
santosh
Please post your attempt. Additionally what does the return value
point to? It's also perhaps better to const qualify the pointer to the
original string since your function need not modify it. You also need
to decide whether memory allocation for str1 and str2 should be done
in the caller or in the callee.
Daniel Rudy
Here's a hint: strsep.
--
Daniel Rudy
Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m
Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep
Ben Pfaff
> Here's a hint: strsep.
strsep is not in the standard C library, so the OP may well not
have it available to him.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery
Tydr Schnubbis
> Daniel Rudy <spam...@spamthis.net> writes:
>
>> Here's a hint: strsep.
>
> strsep is not in the standard C library, so the OP may well not
> have it available to him.
strtok does basically the same thing. But this looks a bit like
homework anyway.
santosh
Daniel Rudy wrote:
> At about the time of 2/21/2007 3:52 AM, Andrea stated the following:
> > I want to write a program that:
> >
> > char * strplit(char* str1, char *str2, char * stroriginal,int
> > split_point)
> >
> > that take stroriginal and split in the split_point element of the
> > string the string into two other strings,
> >
> > example:
> >
> > "Hello World"
> > i want to split this string into "Hello " "World"
>
The OP probably wants to implement the function himself as a learning
exercise. Use an existing function would defeat that purpose.
Richard Bos
> Ben Pfaff wrote:
> > Daniel Rudy <spam...@spamthis.net> writes:
> >
> >> Here's a hint: strsep.
> >
> > strsep is not in the standard C library, so the OP may well not
> > have it available to him.
>
> strtok does basically the same thing.
Almost. strtok won't split "hello world", but it will split an array
containing those characters.
> But this looks a bit like homework anyway.
More than a bit.
Richard
u plz
> Daniel Rudy wrote:
>>
>> Here's a hint: strsep.
>
> The OP probably wants to implement the function himself as a learning
> exercise. Use an existing function would defeat that purpose.
Also the fact that strsep in not defined in the C standard means that the
OP might not be able to use it anyway.
-Alok
Daniel Rudy
> Daniel Rudy <spam...@spamthis.net> writes:
>
>> Here's a hint: strsep.
>
> strsep is not in the standard C library, so the OP may well not
> have it available to him.
It's not?
STRSEP(3) FreeBSD Library Functions Manual STRSEP(3)
NAME
strsep -- separate strings
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <string.h>
char *
strsep(char **stringp, const char *delim);
DESCRIPTION
The strsep() function locates, in the string referenced by *stringp, the
first occurrence of any character in the string delim (or the terminating
`\0' character) and replaces it with a `\0'. The location of the next
character after the delimiter character (or NULL, if the end of the
string was reached) is stored in *stringp. The original value of
*stringp is returned.
An ``empty'' field (i.e., a character in the string delim occurs as the
first character of *stringp) can be detected by comparing the location
referenced by the returned pointer to `\0'.
If *stringp is initially NULL, strsep() returns NULL.
EXAMPLES
The following uses strsep() to parse a string, containing tokens delim-
ited by white space, into an argument vector:
char **ap, *argv[10], *inputstring;
for (ap = argv; (*ap = strsep(&inputstring, " \t")) != NULL;)
if (**ap != '\0')
if (++ap >= &argv[10])
break;
SEE ALSO
memchr(3), strchr(3), strcspn(3), strpbrk(3), strrchr(3), strspn(3),
strstr(3), strtok(3)
HISTORY
The strsep() function is intended as a replacement for the strtok() func-
tion. While the strtok() function should be preferred for portability
reasons (it conforms to ISO/IEC 9899:1990 (``ISO C90'')) it is unable to
handle empty fields, i.e., detect fields delimited by two adjacent delim-
iter characters, or to be used for more than a single string at a time.
The strsep() function first appeared in 4.4BSD.
FreeBSD 6.2 June 9, 1993 FreeBSD 6.2
I guess it's not, but it probably should be... 4.4BSD though is the
original version that FreeBSD is based on, so the function has been
around for a long time.
matevzb
> At about the time of 2/21/2007 1:09 PM, Ben Pfaff stated the following:
> >> Here's a hint: strsep.
> > strsep is not in the standard C library, so the OP may well not
> > have it available to him.
>
> It's not?
>
> STRSEP(3) FreeBSD Library Functions Manual STRSEP(3)
>
> NAME
> strsep -- separate strings
>
> LIBRARY
> Standard C Library (libc, -lc)
specifies (check strdup() for example). HP-UX man pages are really
useful in this area as they contain a "STANDARDS CONFORMANCE" section,
listing the standards that a function conforms to, e.g.:
strcoll(): AES, SVID3, XPG3, XPG4, ANSI C
strdup(): SVID2, SVID3
<snip>
> HISTORY
> The strsep() function is intended as a replacement for the strtok() func-
> tion. While the strtok() function should be preferred for portability
> reasons (it conforms to ISO/IEC 9899:1990 (``ISO C90'')) it is unable to
> handle empty fields, i.e., detect fields delimited by two adjacent delim-
> iter characters, or to be used for more than a single string at a time.
> The strsep() function first appeared in 4.4BSD.
>
> FreeBSD 6.2 June 9, 1993 FreeBSD 6.2
>
> I guess it's not, but it probably should be... 4.4BSD though is the
> original version that FreeBSD is based on, so the function has been
> around for a long time.
--
WYCIWYG - what you C is what you get
Richard Heathfield
> At about the time of 2/21/2007 1:09 PM, Ben Pfaff stated the
> following:
>> Daniel Rudy <spam...@spamthis.net> writes:
>>
>>> Here's a hint: strsep.
>>
>> strsep is not in the standard C library, so the OP may well not
>> have it available to him.
>
> It's not?
No.
> STRSEP(3) FreeBSD Library Functions Manual
What makes you think FreeBSD get to decide what is in the standard C
library?
$ grep -i strsep c89.txt
$
Daniel Rudy
following:
> Daniel Rudy said:
>
>> At about the time of 2/21/2007 1:09 PM, Ben Pfaff stated the
>> following:
>>> Daniel Rudy <spam...@spamthis.net> writes:
>>>
>>>> Here's a hint: strsep.
>>> strsep is not in the standard C library, so the OP may well not
>>> have it available to him.
>> It's not?
>
> No.
>
>> STRSEP(3) FreeBSD Library Functions Manual
>
> What makes you think FreeBSD get to decide what is in the standard C
> library?
>
> $ grep -i strsep c89.txt
> $
>
I didn't say that FreeBSD should decide what goes into the C library.
What I was getting at is the fact that since the function has been
around along time, and that it's superior to strtok (strsep handles
situations that strtok doesn't), why hasn't it been included (at least
in the POSIX standard if not the C standard)?
Now I'm not too up on what functions comprise the standard C library and
what doesn't, reading THIS man page you can see the cause of confusion:
STRTOK(3) FreeBSD Library Functions Manual
NAME
strtok, strtok_r -- string tokens
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <string.h>
char *
strtok(char *str, const char *sep);
char *
strtok_r(char *str, const char *sep, char **last);
DESCRIPTION
This interface is obsoleted by strsep(3).
The strtok() function is used to isolate sequential tokens in a
null-terminated string, str. These tokens are separated in the
I cut it short because of its length. But in the bugs section,
BUGS
The System V strtok(), if handed a string containing only delimiter
char-
acters, will not alter the next starting point, so that a call to
strtok() with a different (or empty) delimiter string may return a
non-NULL value. Since this implementation always alters the next
start-
ing point, such a sequence of calls would always return NULL.
Oh well. Learn something new every day.
CBFalconer
>
... snip ...
>
> This usually refers to libc, which may contain a lot more than ISO
> C specifies (check strdup() for example). HP-UX man pages are
> really useful in this area as they contain a "STANDARDS
> CONFORMANCE" section, listing the standards that a function
> conforms to, e.g.: strcoll(): AES, SVID3, XPG3, XPG4, ANSI C
> strdup(): SVID2, SVID3
> <snip>
>> HISTORY
>> The strsep() function is intended as a replacement for the
>> preferred for portability reasons (it conforms to ISO/IEC
>> 9899:1990 (``ISO C90'')) it is unable to handle empty fields,
>> characters, or to be used for more than a single string at a
>> time. The strsep() function first appeared in 4.4BSD.
>>
>> original version that FreeBSD is based on, so the function has been
>> around for a long time.
>
> It didn't even get into POSIX/SUS, why should it be in C?
You can try the following. The source code has been published here
before, if you want it search google.
/* ------- file toksplit.h ----------*/
#ifndef H_toksplit_h
# define H_toksplit_h
# ifdef __cplusplus
extern "C" {
# endif
#include <stddef.h>
/* copy over the next token from an input string, after
skipping leading blanks (or other whitespace?). The
token is terminated by the first appearance of tokchar,
or by the end of the source string.
The caller must supply sufficient space in token to
receive any token, Otherwise tokens will be truncated.
Returns: a pointer past the terminating tokchar.
This will happily return an infinity of empty tokens if
called with src pointing to the end of a string. Tokens
will never include a copy of tokchar.
released to Public Domain, by C.B. Falconer.
Published 2006-02-20. Attribution appreciated.
*/
const char *toksplit(const char *src, /* Source of tokens */
char tokchar, /* token delimiting char */
char *token, /* receiver of parsed token */
size_t lgh); /* length token can receive */
/* not including final '\0' */
# ifdef __cplusplus
}
# endif
#endif
/* ------- end file toksplit.h ----------*/
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Ben Pfaff
> Now I'm not too up on what functions comprise the standard C library and
> what doesn't, reading THIS man page you can see the cause of confusion:
>
> STRTOK(3) FreeBSD Library Functions Manual
>
> NAME
> strtok, strtok_r -- string tokens
>
> LIBRARY
> Standard C Library (libc, -lc)
File a bug against the FreeBSD manpage then. It's wrong.
--
"It wouldn't be a new C standard if it didn't give a
new meaning to the word `static'."
--Peter Seebach on C99
CBFalconer
> Daniel Rudy said:
>
... snip ...
>
> > STRSEP(3) FreeBSD Library Functions Manual
>
> What makes you think FreeBSD get to decide what is in the standard
> C library?
>
> $ grep -i strsep c89.txt
> $
and similarly for N869.txt (C99)
CBFalconer
>
... snip ...
>
> I didn't say that FreeBSD should decide what goes into the C library.
> What I was getting at is the fact that since the function has been
> around along time, and that it's superior to strtok (strsep handles
> situations that strtok doesn't), why hasn't it been included (at
> least in the POSIX standard if not the C standard)?
Who says it is superior? Another candidate is toksplit (detailed
elsethread). It all depends on what is required. There is no
pressing need for any of these in the standard library, since they
can all easily be written in standard C.
Keith Thompson
> Daniel Rudy <spam...@spamthis.net> writes:
>
>> Now I'm not too up on what functions comprise the standard C library and
>> what doesn't, reading THIS man page you can see the cause of confusion:
>>
>> STRTOK(3) FreeBSD Library Functions Manual
>>
>> NAME
>> strtok, strtok_r -- string tokens
>>
>> LIBRARY
>> Standard C Library (libc, -lc)
>
> File a bug against the FreeBSD manpage then. It's wrong.
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.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Charlton Wilbur
>> NAME strtok, strtok_r -- string tokens
>>
>> LIBRARY Standard C Library (libc, -lc)
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.
On the other hand, the BSDs I have access to at this very moment -- OS
X and OpenBSD - both correctly note in the relevant manpages that
strsep() is an improved version of the standard strtok(), and that
strtok() is ANSI/ISO standard C while strtok_r and strsep are not. So
this is most likely a FreeBSD issue.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Ben Pfaff
> Ben Pfaff <b...@cs.stanford.edu> writes:
>> Daniel Rudy <spam...@spamthis.net> writes:
>>
>>> Now I'm not too up on what functions comprise the standard C library and
>>> what doesn't, reading THIS man page you can see the cause of confusion:
>>>
>>> STRTOK(3) FreeBSD Library Functions Manual
>>>
>>> NAME
>>> strtok, strtok_r -- string tokens
>>>
>>> LIBRARY
>>> Standard C Library (libc, -lc)
>>
>> File a bug against the FreeBSD manpage then. It's wrong.
>
> 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).
Ben Pfaff
>>>>>> "BP" == Ben Pfaff <b...@cs.stanford.edu> writes:
>
> >> NAME strtok, strtok_r -- string tokens
> >>
> >> LIBRARY Standard C Library (libc, -lc)
>
> 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.
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.
Yevgen Muntyan
> Keith Thompson <ks...@mib.org> writes:
>
>> Ben Pfaff <b...@cs.stanford.edu> writes:
>>> Daniel Rudy <spam...@spamthis.net> writes:
>>>
>>>> Now I'm not too up on what functions comprise the standard C library and
>>>> what doesn't, reading THIS man page you can see the cause of confusion:
>>>>
>>>> STRTOK(3) FreeBSD Library Functions Manual
>>>>
>>>> NAME
>>>> strtok, strtok_r -- string tokens
>>>>
>>>> LIBRARY
>>>> Standard C Library (libc, -lc)
>>> File a bug against the FreeBSD manpage then. It's wrong.
>> 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.
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
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Randy Howard
(in article <45DC375A...@cam.ac.uk>):
> Richard Heathfield wrote:
>> Andrea said:
>>
>>> I want to write a program that:
>>>
>>> char * strplit(char* str1, char *str2, char * stroriginal,int
>>> split_point)
>>>
>>> that take stroriginal and split in the split_point element of the
>>> string the string into two other strings,
>>>
>>> example:
>>>
>>> "Hello World"
>>> i want to split this string into "Hello " "World"
>>
>> What's stopping you?
>
> 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 (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Randy Howard
(in article <87d540r...@blp.benpfaff.org>):
> Keith Thompson <ks...@mib.org> writes:
>
>> Ben Pfaff <b...@cs.stanford.edu> writes:
>>> Daniel Rudy <spam...@spamthis.net> writes:
>>>
>>>> Now I'm not too up on what functions comprise the standard C library and
>>>> what doesn't, reading THIS man page you can see the cause of confusion:
>>>>
>>>> STRTOK(3) FreeBSD Library Functions Manual
>>>>
>>>> NAME
>>>> strtok, strtok_r -- string tokens
>>>>
>>>> LIBRARY
>>>> Standard C Library (libc, -lc)
>>>
>>> File a bug against the FreeBSD manpage then. It's wrong.
>>
>> 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.
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
(in article <0001HW.C2130D18...@news.verizon.net>):
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
(in article <87hctcr...@blp.benpfaff.org>):
> Charlton Wilbur <cwi...@chromatico.net> writes:
>
>>>>>>> "BP" == Ben Pfaff <b...@cs.stanford.edu> writes:
>>
>>>> NAME strtok, strtok_r -- string tokens
>>>>
>>>> LIBRARY Standard C Library (libc, -lc)
>>
>> 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.
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.
J. J. Farrell
wrote:
> On Fri, 23 Feb 2007 13:06:22 -0600, Ben Pfaff wrote
>
> >>>> Now I'm not too up on what functions comprise the standard C library and
> >>>> what doesn't, reading THIS man page you can see the cause of confusion:
>
> >>>> STRTOK(3) FreeBSD Library Functions Manual
>
> >>>> NAME
> >>>> strtok, strtok_r -- string tokens
>
> >>>> LIBRARY
> >>>> Standard C Library (libc, -lc)
>
> >>> File a bug against the FreeBSD manpage then. It's wrong.
>
> >> 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.
>
> 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.
CBFalconer
>>>> Daniel Rudy <spam...@spamthis.net> writes:
>>>>
>>>>> Now I'm not too up on what functions comprise the standard C
>>>>> library and what doesn't, reading THIS man page you can see
>>>>> the cause of confusion:
>>>>>
>>>>> STRTOK(3) FreeBSD Library Functions Manual
>>>>>
>
> 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