replace substring

[Flash Gordon]

Paul Hsieh wrote, On 06/06/08 21:35:

I gave a disclaimer that I didn't really review it. At least I didn't
eat myself with an incorrect self-aliasing solution that fails, or run
off the end of some unknown sized array.

Well, *you* were the one making a point about how bad the solutions
presented by everyone else were.

Why does your physics professor insist on units at the end of your
calculations?

I haven't had a physics teacher for a lot of years.

Its self documenting even if its unnecessary.

You have char appearing three times on the same line, that is two more
than is needed for it to be self documenting.

I could
have said sizeof(*str2) or something like that I suppose.

Yes, and that would have dealt with your point below, your use of
sizeof(char) would not.

[...] You know that is is 1 by definition so putting it
is is pointless and makes the code harder to read.

And when you decide to substitute char with wchar_t then what?

Your original code won't work, and changing the cast (which is all the
compiler will complain about) will still leave it broken.

[...] The cast is also
pointless and may stop the compiler from producing a warning if he
forgets to include stdlib.h

No it will not. I think at this point, making such claims is willful
deception.

[markg@cpa-re-test ~]1004$ cat t.c
int main(void)
{
char *fred=(char *)malloc(100);
return 0;
}
/* end sample.c */
[markg@cpa-re-test ~]1005$ gcc t.c
[markg@cpa-re-test ~]1006$ cat /etc/issue
Red Hat Enterprise Linux ES release 3 (Taroon Update 8)
Kernel \r on an \m

[markg@cpa-re-test ~]1007$

Seems like it is real life to me. RedHat ES3 is still supported by
RedHat and used by large organisations.

I suppose you just *had* to reverse the order of the comparisons for
taste reasons didn't you? It really bugs you that much doesn't it?

If it really bugged me that much I would have commented about it, but I
didn't.

Take a closer look at your second line.

Which would have been picked up by the compiler using the level of
warnings I normally use, so it would never hit production code where I work.

Anyway, a post correcting errors is meant to have at least one error!

When you have to run *this* much convoluted nonsense through your head
just to do a simple find and replace, you are bound to make this kind
of mistake. That's my *REAL* point, and you've just helped make it.

The only error you spotted in my code would have been spotted by the
compiler for me if I compiled it using the options we normally use at work.

In any event, as to the ramming things into as few lines as possible
thing you are doing here,

I didn't. I even included a redundant condition and a redundant set of
braces.

I have an aversion to code that even *looks*
like it might have UB.

The incrementors/decrementors are specifically
troublesome here since their side effect is being hidden by order of
operations, and C's order of operations is already well known to be
broken.

You may have problems with the order of operations, that does not mean
that everyone does.

And I didn't even manage to avoid bugs here either (it should be &from
and &replace -- I blame it on the fact that I wrote the earlier code)

You think you have problems, I regularly use several other languages!

but the library goes a long way to mitigate them (the compiler would
immediately tell you how to fix it.)

With the options I normally use the compiler I normally use would have
reported my bug too, so that is not such a big benefit.

[...] You
could probably do it with fewer lines of code using a regular expression
library,

I kind of doubt it -- there is still the problem of managing the
memory for the string result, and that's not typically taken care of
by a regex library.

str = str_create("d:\\temp\\data\\test.txt");
if (str_regsub("\\\\", "\\\\", str, 0, 0, 1)) {
/*Use the string */
}
str_destroy(str);


Admittedly this library has rather more than just regular expressions
including expanding strings. Also the reason it is fewer lines is that
only the string being operated on needs to be of the special type.

[...] but for all I know that could a be slower solution.

That too (it is.)

Not always an issue or people would not use interpreted languages.
Anyway, if I wanted the fasted possible I would carefully hand craft a
replacement function as part of my utility library the once and just
keep using it, just as you have with your library.