substring finding problem!

C

Chris M. Thomasson

I'd say that it better. It cannot use Boyer Moore or Knuth Morris
Pratt IF they use tables, and I believe they do, since that implies
(as far as I can tell) state (like malloc) or else an extra parameter
in the call.

If fuc%ing better be more efficient than a naive algorithm!

:^o




[...]
And note that "using strstr" has its own dangers. IT FINDS OVERLAPPING
STRINGS. If you use it to construct a table of replace points you're
gonna have an interesting bug-o-rama:

replace("banana", "ana", "ono")

IF you restart one position after the find point, and not at its end.

Well, I simply did not construct my `replace()' function to detect
overlapping strings. Therefore, if I pass your input to my implementation I
get:
_______________________________________________
src: banana
cmp: ana
xchg: ono
expect: bonona
result: bonona
_______________________________________________


That result is fine with me. Humm... It might be interesting to see if I can
use `strstr()' to build a table that can handle overlapping strings. For the
`banana' example I would have two entries in the table:

1: offset 1
2: offset 3

After processing 1, the destination string is:

bono


After processing 2, the destination string is:

bonono


But that was easy because the exchange string is the exact same size as
comparand string. Things could get "dicey" if the exchange string were,
let's say, bigger '12345'. So, what should the final result look like in an
overlapping replace function for the following input:


replace("banana", "ana", "12345");

?

Would it be:

b1234512345

?


If so, would it be okay for replace("banana", "ana", "ono") to result in:

bonoono


?


We need to work out some rules here... ;^)



Moral: don't let the library do your thinking for you.

How do you feel about a garbage collector doing all the thinking for you? I
think a GC is convenient, and I also feel the same way about certain library
functions. However, there are times when you do want to "re-invent"
something. For instance, I am okay with using various manual memory
management techniques to help relieve the pressure on a GC.
 
C

Chris M. Thomasson

[...]
Update: Willem posted an exciting, if apparently buggy, solution in
the thread where Peter mis-spelled "efficiency" in the name, and I
just had a chance to look at it. It uses recursion in place of any
data structure whatsoever. And in the same thread another poster seems
to claim he did a working (if for me hard to read) solution on day
one: I have asked him to use my test suite.

And yes. A solution WITH BUGS can be more intelligent than a clean
one. A solution that TAKES A LONG TIME can likewise be better than one
that doesn't.


I was also prepared to concede victory to Willem despite

Humm... I need to ask why would you feel the need to concede victory to
anybody? I thought this was not a contest. What am I missing?



his one character identifiers because of the beauty of his idea: use
recursion and not a data structure.

Can I pass it a bomb that can possibly blow the stack? I cannot seem to find
Willem's posting in the thread entitled "Efficency and the standard
library".

[...]
 
S

Seebs

Humm... I need to ask why would you feel the need to concede victory to
anybody? I thought this was not a contest. What am I missing?

When has Nilges ever acted in a way that suggested that he did not view
everything as a contest with winners and losers? I think you're inventing
rationality not in evidence.

-s
 
C

Chris M. Thomasson

Here is my humble little entry that took me around a half an hour or so to
create:

http://clc.pastebin.com/f62504e4c

If you want to avoid using `string.h' then you are going to have to
implment
the following functions:
_________________________________________________ [...]
_________________________________________________
[...]
Any questions?
Yeah, Chris. I have a question. Why did you call it an "entry" when
this (to me, anyway) implied that it was a contest entry to the
Spinoza challenge? Please don't be corrupted by the dishonesty and
brutality of these newsgroups.

Ahh crap. I was thinking that it was sort of a "challenge" so to speak.
Anyway, I apologize for misrepresenting you.



Sure, you do say that I have to implement FOUR (4) non-trivial library
functions.

But by saying "it took me a half hour" I read an implied, perhaps
unintended slight at the approximately six hours I took ... where only
in dysfunctional corporations is it a bad thing to take a little extra
care and a little extra time in anticipation of difficulty.

I actually meant nothing by it. Quite frankly, now that I think about it, I
don't actually know why I posted how long it took me. I mean, who cares
right?



A week late, in this thread, Seebach, Bacarisse et al. seem to be
running into confusion trying to help the OP meet the original
challenge. But I note nobody harassing them or the original poster,
targeting them for abuse.

What challenge?



In a sense, "I have only myself to blame" for this, because a year or
so ago, I jumped all over Seebach for his attacks on Schildt. I feel I
was right to do so, *et je ne regrette rien*. Nonetheless, I'm tired
of his lies.

If your "slight" was unintended, I apologize.

It was totally unintended Edward. I did not even think of insulting anybody
by posting how long it took be to flesh out that code.



Without knowing as much about C as the regs, esp. postmodern C and the
standards (I'll be the first to concede this), I've left them in the
dust as regards my challenge.

Again, what challenge are you referring to?



I've completed my solution, although I
am refining it by adding a stress test and may post a proof elsethread
proving that the code matches the algorithm statement I've posted
elsethread, and in so doing I may find a bug.

Finding a bug is damn good thing! Nothing wrong with that. I hate it when
somebody gets pissed off when I find a bug in some of their code. They don't
even thank you for pointing it out to them!

Bastards!



This is because "knowing C" is different from "knowing how to program"
and given the serious design flaws of C, there could be "knowing too
much about C".

But as far as I can see, no-ones mastered the problem to the same
extent, Seebach perhaps least of all, because he wasted too much time
last week attacking me. He may redeem himself by helping the OP of
this thread, but he's never even tried to write his own solution.

I just cannot really understand why you are trying to avoid `string.h' in
all cases. I mean, if you wanted to re-implement `strstr()', well, that's
fine. However, I don't see a real need to roll your own version of
`strlen()' or `memcpy()'. I mean, how can you do better than a good
implementation of the standard C library? An implementation of `memcpy()'
will most likely be using processor specific instructions that provide a
level of efficiency that cannot be reached with 100% pure portable C code.
 
T

Tom St Denis

I think you're talking to a "wall, wondrous high, and covered with
serpent shapes" (the Wanderer): I don't think Heathfield wants people
to learn, at least as free, critical human beings. I think he wants
them to listen, and repeat rote maxims. If he's a teacher, as he seems
to want to be, he's the gym coach in the History Boys:

Nobody, least of all anyone looking like me asked you for your
opinion.

Tom
 
C

Chris M. Thomasson

Chris M. Thomasson said:
[...]
Update: Willem posted an exciting, if apparently buggy, solution in
the thread where Peter mis-spelled "efficiency" in the name, and I
just had a chance to look at it. It uses recursion in place of any
data structure whatsoever. And in the same thread another poster seems
to claim he did a working (if for me hard to read) solution on day
one: I have asked him to use my test suite.

And yes. A solution WITH BUGS can be more intelligent than a clean
one. A solution that TAKES A LONG TIME can likewise be better than one
that doesn't.


I was also prepared to concede victory to Willem despite [...]
his one character identifiers because of the beauty of his idea: use
recursion and not a data structure.

Can I pass it a bomb that can possibly blow the stack? I cannot seem to
find Willem's posting in the thread entitled "Efficency and the standard
library".

Ahhh, I found his code in the "Warning to newbies" thread:


http://groups.google.com/group/comp.lang.c/msg/7c6bf8fae5249919


I don't think it can blow the stack because the recursion level is limited.
Also, I found a response to Willem from you:


http://groups.google.com/group/comp.lang.c/msg/5b2b278673c86951


in which you clearly state that this is indeed a "Spinoza challenge":
_____________________________________________________________
spinoza111: "2. I was, and remain, very impressed by your solution and as I
created the source file you see below I was rooting for you: for had
it ran with my test suite, I would have handed the "Olympic gold
medal" that I've awarded myself in the Spinoza challenge to you."
_____________________________________________________________


Now you are confusing me here. First you say it's not a challenge, then you
seem to contradict yourself. Can you please clear this up for me? Thanks.
 
S

Seebs

I actually meant nothing by it. Quite frankly, now that I think about it, I
don't actually know why I posted how long it took me. I mean, who cares
right?

Right.

That said, I *did* mean a slight at the alleged six hours Nilges took to
produce a much buggier implementation, because that suggests that his
methodology is bad -- and since he posted his originally specifically as
a criticism of my off-the-cuff example I posted in another thread, I
figured he was looking for comparisons.

In short, he posted a large rant about how unprofessional and unconsidered
and badly-designed my code was, which point he "proved" by demonstrating
that, in only ten times as many lines of code, with four or five times as
many bugs, he could nearly solve a sort of similar problem. Very persuasive.
What challenge?

I have no clue.

This whole thing started because I posted a snippet of code I found
interesting to make for some vaguely topical stuff. Nilges responded with
angry rants about how bad my code was and a gigantic, buggy, "solution"
to the problem.
Again, what challenge are you referring to?

The one he thinks it's very offensive that you implied existed.

He's not exactly consistent. At any given time, he believes whatever he
feels makes him look best. This can result in him believing wildly
contradictory things over the course of a post.
Finding a bug is damn good thing! Nothing wrong with that. I hate it when
somebody gets pissed off when I find a bug in some of their code. They don't
even thank you for pointing it out to them!
Agreed!

I just cannot really understand why you are trying to avoid `string.h' in
all cases. I mean, if you wanted to re-implement `strstr()', well, that's
fine. However, I don't see a real need to roll your own version of
`strlen()' or `memcpy()'. I mean, how can you do better than a good
implementation of the standard C library? An implementation of `memcpy()'
will most likely be using processor specific instructions that provide a
level of efficiency that cannot be reached with 100% pure portable C code.

I have no clue. I also don't see why he thinks my posts about his buggy
code have anything to do with the time or effort it takes to get this done.
When he proposed a more general problem than the one my original effort
solved, I posted a proposed solution, which took about ten minutes to write,
and in which one bug was found so far. (It went into an infinite loop if you
had it matching a zero-length substring.) I fixed that, and it's done. So
far as I can tell, it works for all inputs that don't exhaust memory or
size_t or something similar, and is otherwise unexceptional because the
task is fundamentally a very trivial one.

-s
 
W

Willem

Seebs wrote:
)> I just cannot really understand why you are trying to avoid `string.h' in
)> all cases. I mean, if you wanted to re-implement `strstr()', well, that's
)> fine. However, I don't see a real need to roll your own version of
)> `strlen()' or `memcpy()'. I mean, how can you do better than a good
)> implementation of the standard C library? An implementation of `memcpy()'
)> will most likely be using processor specific instructions that provide a
)> level of efficiency that cannot be reached with 100% pure portable C code.
)
) I have no clue. I also don't see why he thinks my posts about his buggy
) code have anything to do with the time or effort it takes to get this done.
) When he proposed a more general problem than the one my original effort
) solved, I posted a proposed solution, which took about ten minutes to write,
) and in which one bug was found so far. (It went into an infinite loop if you
) had it matching a zero-length substring.) I fixed that, and it's done. So
) far as I can tell, it works for all inputs that don't exhaust memory or
) size_t or something similar, and is otherwise unexceptional because the
) task is fundamentally a very trivial one.

I wouldn't call matching a zero-length substring a bug, really. More of an
oversight in the specification. It's comparable to dividing by zero.

The reason I enjoyed coding it up without using string.h functions is
because it's an academic challenge/puzzle. Not a hard one, mind.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
S

Seebs

I wouldn't call matching a zero-length substring a bug, really. More of an
oversight in the specification. It's comparable to dividing by zero.

My code's behavior was a bug, though -- bad inputs shouldn't cause an
infinite loop.
The reason I enjoyed coding it up without using string.h functions is
because it's an academic challenge/puzzle. Not a hard one, mind.

It's interesting, and the recursive strategy is fascinating.

-s
 
C

Chris M. Thomasson

Seebs said:
My code's behavior was a bug, though -- bad inputs shouldn't cause an
infinite loop.


It's interesting, and the recursive strategy is fascinating.

Yes, I agree that the solution based on recursion is neat. However, any
recursive function tends to make me worry about blowing the stack. Perhaps I
worry to much!

;^)
 
S

spinoza1111

I'd say that it better. It cannot use Boyer Moore or Knuth Morris
Pratt IF they use tables, and I believe they do, since that implies
(as far as I can tell) state (like malloc) or else an extra parameter
in the call.

If fuc%ing better be more efficient than a naive algorithm!

:^o

[...]


And note that "using strstr" has its own dangers. IT FINDS OVERLAPPING
STRINGS. If you use it to construct a table of replace points you're
gonna have an interesting bug-o-rama:
replace("banana", "ana", "ono")
IF you restart one position after the find point, and not at its end.

Well, I simply did not construct my `replace()' function to detect
overlapping strings. Therefore, if I pass your input to my implementation I
get:
_______________________________________________
src:    banana
cmp:    ana
xchg:   ono
expect: bonona
result: bonona
_______________________________________________

That result is fine with me. Humm... It might be interesting to see if I can
use `strstr()' to build a table that can handle overlapping strings. For the
`banana' example I would have two entries in the table:

1: offset 1
2: offset 3

After processing 1, the destination string is:

bono

After processing 2, the destination string is:

bonono

But that was easy because the exchange string is the exact same size as
comparand string. Things could get "dicey" if the exchange string were,
let's say, bigger '12345'. So, what should the final result look like in an
overlapping replace function for the following input:

replace("banana", "ana", "12345");

?

Would it be:

b1234512345

?

If so, would it be okay for replace("banana", "ana", "ono") to result in:

bonoono

?

We need to work out some rules here...   ;^)
Moral: don't let the library do your thinking for you.

How do you feel about a garbage collector doing all the thinking for you? I


Fine, since garbage collection is simpler than software design. We
have the right to think of software entities coming into existence and
dying without having to be midwifes or funeral directors.
 
S

spinoza1111

When has Nilges ever acted in a way that suggested that he did not view
everything as a contest with winners and losers?  I think you're inventing

It's better to have a contest with winners and losers than a rigged
game with bullies and victims, Seebach. You've forced me to
demonstrate that you're not competent to judge Schildt, but I would
much prefer not having to do this. If you'd behave yourself and start
a night school course in comp sci, then I won't start contests.
 
S

spinoza1111

Here is my humble little entry that took me around a half an hour or so to
create:

If you want to avoid using `string.h' then you are going to have to
implment
the following functions:
_________________________________________________ [...]
_________________________________________________

[...]
Any questions?
Yeah, Chris. I have a question. Why did you call it an "entry" when
this (to me, anyway) implied that it was a contest entry to the
Spinoza challenge? Please don't be corrupted by the dishonesty and
brutality of these newsgroups.

Ahh crap. I was thinking that it was sort of a "challenge" so to speak.
Anyway, I apologize for misrepresenting you.

No prob.
I actually meant nothing by it. Quite frankly, now that I think about it, I
don't actually know why I posted how long it took me. I mean, who cares
right?

Sorry for gettin' hot on the collar but as you can see there are a lot
of ill-intentioned people here.
What challenge?
Write a replace() function without using string.h.
It was totally unintended Edward. I did not even think of insulting anybody
by posting how long it took be to flesh out that code.


Again, what challenge are you referring to?


Finding a bug is damn good thing! Nothing wrong with that. I hate it when
somebody gets pissed off when I find a bug in some of their code. They don't
even thank you for pointing it out to them!

Bastards!

Swine!

Let's hear it for the good guys! YAY
Let's hear it for the bad guys! BOO
I just cannot really understand why you are trying to avoid `string.h' in
all cases. I mean, if you wanted to re-implement `strstr()', well, that's
fine. However, I don't see a real need to roll your own version of
`strlen()' or `memcpy()'. I mean, how can you do better than a good
implementation of the standard C library? An implementation of `memcpy()'

Actually, in terms of efficiency one often can. Library writers are
men of flesh and blood, and women too.
will most likely be using processor specific instructions that provide a
level of efficiency that cannot be reached with 100% pure portable C code..

How is that possible? The compiler of the library code will emit
"processor specific" instructions, to be sure, but it will do the same
for me, or any man. And if the library code forces out assembler code,
then it will only work on one processor, or at best small n processor.

Without any examples in front of me at the time, I'd say that well-
written library routines are basically simple and correct. They have
to run on multiple processors, and can no where assume instructions
that execute in one or small n machine cycles.
 
S

spinoza1111

[...]
Update: Willem posted an exciting, if apparently buggy, solution in
the thread where Peter mis-spelled "efficiency" in the name, and I
just had a chance to look at it. It uses recursion in place of any
data structure whatsoever. And in the same thread another poster seems
to claim he did a working (if for me hard to read) solution on day
one: I have asked him to use my test suite.
And yes. A solution WITH BUGS can be more intelligent than a clean
one. A solution that TAKES A LONG TIME can likewise be better than one
that doesn't.
I was also prepared to concede victory to Willem despite [...]
his one character identifiers because of the beauty of his idea: use
recursion and not a data structure.
Can I pass it a bomb that can possibly blow the stack? I cannot seem to
find Willem's posting in the thread entitled "Efficency and the standard
library".

Ahhh, I found his code in the "Warning to newbies" thread:

http://groups.google.com/group/comp.lang.c/msg/7c6bf8fae5249919

I don't think it can blow the stack because the recursion level is limited.
Also, I found a response to Willem from you:

http://groups.google.com/group/comp.lang.c/msg/5b2b278673c86951

in which you clearly state that this is indeed a "Spinoza challenge":
_____________________________________________________________
spinoza111: "2.  I was, and remain, very impressed by your solution and as I
created the source file you see below I was rooting for you: for had
it ran with my test suite, I would have handed the "Olympic gold
medal" that I've awarded myself in the Spinoza challenge to you."
_____________________________________________________________

Now you are confusing me here. First you say it's not a challenge, then you
seem to contradict yourself. Can you please clear this up for me? Thanks.

It is a challenge.
 
S

spinoza1111

Right.

That said, I *did* mean a slight at the alleged six hours Nilges took to
produce a much buggier implementation, because that suggests that his
methodology is bad -- and since he posted his originally specifically as
a criticism of my off-the-cuff example I posted in another thread, I
figured he was looking for comparisons.

In short, he posted a large rant about how unprofessional and unconsidered
and badly-designed my code was, which point he "proved" by demonstrating
that, in only ten times as many lines of code, with four or five times as
many bugs, he could nearly solve a sort of similar problem.  Very persuasive.

You only knew about the bugs because I fixed them, Peter, whereas you
never fixed the bugs you reported in your first attempt. I haven't
been tracking your other code in detail because it doesn't interest
me, but I see in your posts nothing like diligence in testing. You're
so worried about taking "too long", having been in my view corrupted
by corporate life, that you created nothing like a systematic and
growing test suite (I did) nor did you systematically track and
document bugs and changes (I did).

In fact, most of the "six hours" I spent was in documentation and test
creation, not coding. How dare you even compare your buggy and
amateurish work?

If you look at the latest text of "my" replace, you'll see in the
Change Record that each bug save one is labeled with "bug:": one is
labeled "bug fix".

There were, in fact, only five bugs.

And, of course, you're counting in "lines of code" the test suite that
many other posters including Willem have found useful, but which you
probably dare not use.
I have no clue.

This whole thing started because I posted a snippet of code I found
interesting to make for some vaguely topical stuff.  Nilges responded with
angry rants about how bad my code was and a gigantic, buggy, "solution"
to the problem.

Five bugs. All fixed. YOU NEVER FIXED the %s bug.

The one he thinks it's very offensive that you implied existed.

He's not exactly consistent.  At any given time, he believes whatever he
feels makes him look best.  This can result in him believing wildly
contradictory things over the course of a post.

Your limitations are not my contradictions,
Your failures are not mine,
Your misery is your own history,
So, dear boy, don't whine.



Asshole. I've bent over backward to acknowledge whatever contributions
you've made. You won't even respond to email.
I have no clue.  I also don't see why he thinks my posts about his buggy
code have anything to do with the time or effort it takes to get this done.
When he proposed a more general problem than the one my original effort
solved, I posted a proposed solution, which took about ten minutes to write,

It uses string.h. It doesn't meet the challenge. God damn, boy, you
are a liar, aren't you?

If I missed where you wrote a bug free replace() without using
string.h, post it

*HERE*

so we can evaluate it.
 
B

bartc

spinoza1111 said:
Actually, in terms of efficiency one often can. Library writers are
men of flesh and blood, and women too.

But different men for different implementations. When you write your
strlen() equivalent, you are only going to write one, not dozens. And if you
stick to portable C, it might not be faster.
How is that possible? The compiler of the library code will emit
"processor specific" instructions, to be sure, but it will do the same
for me, or any man. And if the library code forces out assembler code,
then it will only work on one processor, or at best small n processor.

I think standard library routines can be written in a language other than C,
or some mix. For example, hand-written assembly.

And the library you use comes with the processor; switch processors, and
there could be a different library routine, optimised a different way (or
just optimised down by the compiler to a couple of inline machine
instructions).
 
S

spinoza1111

spinoza1111wrote:


But different men for different implementations. When you write your
strlen() equivalent, you are only going to write one, not dozens. And if you
stick to portable C, it might not be faster.



I think standard library routines can be written in a language other than C,
or some mix. For example, hand-written assembly.

Correct. Wonder how many library routines are written in assembler.
Don't know.
And the library you use comes with the processor; switch processors, and
there could be a different library routine, optimised a different way (or
just optimised down by the compiler to a couple of inline machine
instructions).

Correct o mundo
 
N

Nick Keighley

Correct. Wonder how many library routines are written in assembler.
Don't know.


Correct o mundo

you've been spoilt by the "portable assembler" nature of C. C is
unusual in that much of it's standard library can be written in C.
Since Windows and most Unixes are also written in C, calls into the OS
are easy as well.

Many other languages will have the low level parts of their libraries
written in C.
 
F

fedora

Hi all!

Have finished my program for spinoza's challenge. rewrote everything and
this time i made each statement as simple as posible, so that i can
understand the program. The allSubstr procedure can search for over lapping
sub-string too like spinoza wanted, but the replace routine doesnt use that
since i cant think how to replace over lapping ones!

haven't used any function from string.h! it works for strings i could think
of but maybe it got bugs since i'm just a beginner...

how's mine spinoza111? :)

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

size_t strLength(char *cstr) {
size_t index = 0;

while (cstr[index] != '\0') ++index;
return index;
}

char *strFirstCh(char *str, char ch, size_t lstr) {
char *chpos = 0;
size_t current;

for (current = 0; current < lstr; current++) {
if (str[current] == ch) {
chpos = str + current;
break;
}
}
return chpos;
}

int strComp(char *s, char *t, size_t len) {
int ret = 0;
size_t index;

for (index = 0; index < len; index++) {
if (s[index] != t[index]) {
ret = 1;
break;
}
}
return ret;
}

char *strSubstr(
char *str,
char *sub,
size_t lstr,
size_t lsub) {
char *substr = 0;
char *anchor = str;
size_t remaining_len = (lstr - lsub) + 1;

assert(str && sub && lstr && lsub && lstr >= lsub);
while (remaining_len > 0 && anchor) {
if (anchor = strFirstCh(anchor, *sub, remaining_len)) {
if (strComp(anchor, sub, lsub) == 0) {
substr = anchor;
break;
}
anchor++;
remaining_len--;
}
}
return substr;
}

unsigned allSubstr(
char *str,
char *sub,
size_t lstr,
size_t lsub,
char ***ps,
int overlap) {
unsigned occurs = 0;
unsigned ctr;
char *orig_str = str;
size_t orig_lstr = lstr;
size_t step;

if (overlap == 1)
step = 1;
else
step = lsub;

while (lstr >= lsub) {
str = strSubstr(str, sub, lstr, lsub);
if (str == 0)
break;
occurs++;
str += step;
lstr = (orig_str + orig_lstr) - str;
}

if (occurs > 0 && ps) {
str = orig_str;
lstr = orig_lstr;
*ps = malloc(occurs * sizeof **ps);
if (*ps) {
for (ctr = 0; ctr < occurs; ctr++) {
ps[0][ctr] = str = strSubstr(str, sub, lstr, lsub);
str += step;
lstr = (orig_str + orig_lstr) - str;
}
}
}
return occurs;
}

char *replace(char *str, char *substr, char *rep) {
char *new = 0;
size_t lstr, lsubstr, lrep, lnew, strc, newc, repc, replaced;
unsigned replacements;
char **subpos;

assert(str && substr && rep);
lstr = strLength(str);
lsubstr = strLength(substr);
lrep = strLength(rep);
if (lstr == 0 || lsubstr == 0 || lsubstr > lstr)
return 0;
replacements = allSubstr(str, substr, lstr, lsubstr, &subpos, 0);
if (replacements > 0) {
lnew = (lstr - (replacements * lsubstr)) + (replacements * lrep);
new = malloc(lnew + 1);
if (!new)
return 0;
strc = newc = replaced = 0;
while (strc <= lstr) {
if (str + strc == subpos[replaced]) {
for (repc = 0; repc < lrep; repc++) {
new[newc] = rep[repc];
newc++;
}
replaced++;
strc += lsubstr;
}
else {
new[newc] = str[strc];
strc++;
newc++;
}
}
free(subpos);
}
else {
new = malloc(lstr + 1);
if (!new)
return 0;
for (strc = 0; strc <= lstr; strc++)
new[strc] = str[strc];
}
return new;
}

int main(int argc, char **argv) {
char *newstr;

assert(argc == 4);
newstr = replace(argv[1], argv[2], argv[3]);
if (newstr)
printf("%s\n", newstr);
else
printf("replace() -> null\n");
free(newstr);
return 0;
}

thanks a lot all who helped!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,143
Latest member
SterlingLa
Top