S
spinoza1111
THOU SHALT NOT says Richard NOT USE STRING.H, even for shits and
giggles.
Because thou are virtuous, shall there be no more cakes and ale?
THOU SHALT NOT says Richard NOT USE STRING.H, even for shits and
giggles.
Because thou are virtuous, shall there be no more cakes and ale?
I
Ike Naar
Not sure if this is your problem, but you should be aware that
you're doing a comparison between a signed number (the difference
between the pointers (orig_str+orig_lstr) and str), and an unsigned
number (step).
This will give unexpected results if the lefthandside of the comparison
is a small negative value; the value will be converted to unsigned
before it is compared to the righthandside, and becomes a huge positive
value. As a result, the comparision yields false.
You can work around the problem by rewriting the comparison as
(orig_str + orig_lstr <= str + step)
where both sides of the comparision are pointers.
F
fedora
Ike said:
Hi Ike!
Gcc warned me of this too, but i ignored it since i couldn't think of a
better way.
Initially i thought of writing it exactly like yours but then when str is <
step bytes before it's end, adding step to it would be undefined behaviour
so i coded like i did. Maybe i can cast step to signed long and then compare
with (orig_str+orig_lstr) - str? is this ok?
thanks
F
fedora
Ben said:
I wanted to write my own functions partly for learning as i'm just beginning
and also because if i used string.h, i couldn't have submitted to spinoza's
challenge...
but motly it was just for learning. as we see, i was correct since i'm
having so much difficulty.
i'm not a skilled programmer
Okay i see. Thanks.
I added the one because when both string and sub string are equal length the
diff will give zero, so to make the while loop below work properly, i add
one.
i cant compare remaining_len >= 0 since that'll always be true for unsigned.
i hate it when i cant get a mental image of how a function will behave for
all combinations of legal ainput values. boundary values complicate
everything and unsigned seems to be more trouble than i thought.
See above.
am thinking if string programing in C is naturally so difficult or i'm
just stupid
No, it is hard to get the details right but you are not helping
yourself by not breaking your program up into helpful simple
functions. You have some nice functions to help find the strings, but
you stopped there. I'd have some functions to help build the copy
with the replacements.
Yes i'm not happy with the replace routine. It's too big. i'll code versions
of strcpy and make it shorter and try again. maybe the bug is in replace...
by this replace function do you mean mine above?
I
Ike Naar
Whoops you're right I did not think about that.
That is a possibility. If your compiler supports prtdiff_t then perhaps
it's better to cast step to that type, so that the types on both sides
of the comparison operator are the same.
What about (orig_str + orig_lstr - step <= str) ?
K
Kenny McCormack
spinoza1111 said:
Now you've gone and done it! From here on in, they will gleefully refer
to you as a "self-confessed troll".
It happened to me about 5 years ago - and they still use it in their
diatribes. The fact, of course, being that they define things so that
anyone with even a glimmer of intelligence becomes defined as "troll".
F
fedora
Ike said:
This is perfect thanks!! After changing that line to the comparison above,
i've stopped getting the strange seg faults as far as i can see.
so it seems this failed test allowed lstr to wrap around to very big values
and access foreign memory locations. now it works!
thanks again Ike
S
spinoza1111
There's no point, Kenny, in evading their stupid, childish labels. But
I predict that if I continue posting great code and incisive writing,
things will change here.
Hasta la victoria siempre!
S
spinoza1111
They think they can define the world,
Their poison they have hurled,
Because they can't stand freedom:
They recreate their corporate kingdom.
They actually do this for fun
Thinking by lies they have won,
But when you look at their code,
You see quite a load,
Of the bugs they condemn in others.
Seebach can't get string length right
He's off by one in plain sight,
And they dare to call you a "troll"
When you can write above the level of O,
When you code above the level of Joe.
They've taken structured programming
And made it a dog's dinner:
They think it is a ban on thinking.
Dijsktra died at seventy-two
In part from life long depression
At the nonsense and voodoo
That passed for good computing.
Now they invoke his name
To speak it they should feel shame.
S
Seebs
Unless you're expecting to spend most of your programming career working
for people who have major obsessive problems with using technology in ways
that generally work, because of personal grudges never adequately explained,
I would suggest that perhaps what Nilges accepts or doesn't accept should
not be a component of any technical decision, ever.
The obvious way to do it would be:
size_t
callstrlen(const char *s) {
#ifdef ME
/* your code here */
#else
return strlen(s);
#endif
}
-s
S
Seebs
am thinking if string programing in C is naturally so difficult or i'm just
stupid
It takes quite a while to get used to it, at the very least. When you're
doing multiple string operations, you have a lot of things to keep track
of. Consider a simple strcpy() replacement:
char *cpystr(char *dest, char *src) {
char *start = dest;
while ((*(dest++) = *(src++)) != '\0')
;
return start;
}
This isn't actually all that simple; I write a lot of code which is
much harder for me to figure out, but which would be easier to figure
out without years of experience with strings. It can be a bit easier
to read done the other way:
char *cpystr(char *dest, char *src) {
int i;
for (i = 0; src; ++i) {
dest = src;
}
dest = '\0';
return dest;
}
This one is often easier for people to read because the pointers stay
pointing to the same things. So for some cases, you may find array
notation simpler. What I have found is usually that array notation is
simpler as long as I only have one index to use. If I have multiple indexes,
it can be easier for me to think about the problem if I write it in
terms of pointers, but not necessarily tersely:
while (*src) {
*dest = *src;
++dest;
++src;
}
*dest = '\0';
That's certainly simpler to understand than the original version. What this
does is trade the simplicity of having the pointers stay fixed -- they always
point to the same things -- for the simplicity of having the semantic content
of the pointers stay fixed -- they always point to the next character you
need to copy.
Which of those is better is a bit arbitrary, and may vary from one person to
another, or one algorithm to another. Once you start getting into stuff like
strstr() implementations, it's often important to pick descriptive names.
I don't recommend names like thePointerToTheThingIWasGoingToCopyInto. I tend
to prefer short nickname length things; something that's easy to recognize,
visually distinct, and tells me what I'm doing.
So...
char *findstr(char *needle, char *haystack) {
while (*haystack) {
if (*haystack == *needle) {
char *h = haystack, *n = needle, *first = NULL;
while (*n && *n == *h) {
if (!first && *h == *needle) {
first = h;
}
++n;
++h;
}
if (!*n) {
return haystack;
} else {
haystack = first - 1;
}
}
++haystack;
}
return NULL;
}
I don't know whether this will work, but it's approximately a standard cheap
strstr(), with the one optimization being an attempt to not rescan a chunk
of the haystack looking for the first character of the needle when it's not
needed. The names aren't very long, and the inner loop uses short names
which clearly refer back to their sources.
You're invited to look for errors in this, as there may well be some, not
the least of which is that I have no idea whether or not it will compile.
-s
K
Kenny McCormack
Clearly then, you are not a troll.[/QUOTE]
Don't quit your day job.
M
Malcolm McLean
That's the ad hominem fallacy. It's not a pretentious term for
"insult" but a common falacy, which is to suppose that an argument is
wrong because of the person who is making it.
In fact there are good reasons for deprecating string.h. chars
effectively have to be octets, whilst often programs need to accept
non-Latin strings. Then the functions are all very old, with certain
weaknesses (no protection from buffer overun in strcpy, an O(N)
performance for strcat and strlen, an inconvenient interface for
strcat, const inconsistencies with strchr, very poor functionality
with strfind and const inconsiencies here too, very serious buffer
problems with sprintf, an overly difficult interface and buffer
problems with sscanf, thread problems with strtok and a non-intuitive
interface.
S
Seebs
No, it's not an ad hominem fallacy. It's the very well supported view
that what Nilges accepts or doesn't accept should not be a component of any
technical decision. I'm not saying that an argument is wrong because of
the person who is making it. I'm saying that a conclusion should be ignored
(neither accepted nor rejected) based on the person who has offered it.
Which is to say, if you know someone is a clown, knowing his position on an
issue tells you nothing for or against the issue. Now, if he had advanced
an argument, it could be worth discussing that argument, but as long as
we're just talking about his conclusion, it's not an ad hominem fallacy to
suggest disregarding the conclusions reached by someone who is demonstrably
very bad at the topic in question.
For some purposes, yes.
For manipulation of sequences of non-NUL chars, terminated by a char, not so
much.
True. This is addressed in no small part by the multibyte stuff, which you
would presumably use for multibyte strings.
I'm not aware of "strfind".
While the various interfaces are certainly flawed, consider that the Nilges
alternative is to duplicate the flaws of the interface without even the
benefit of already having been debugged. Or, worse, to just not even come
close.
There are certainly cases where the <string.h> functions are not the right
tool. However, that Nilges argues against it is not an argument either way
in that. His arguments might be an argument either way; his conclusion is
not.
-s
B
Ben Bacarisse
Malcolm McLean said:
It's easy to switch to wide character versions if you used the
equivalent str* versions. A few macros and you can build versions for
either character type very simply.
Those are arguments for using something better, not arguments for not
using C's string functions. If the "challenge" had been: "use this
improved string library to write replace" or "design a string library
so that replace is easy to write" I for one would have no objection.
The problem is that rejecting what is already there (rather than using
something better) leads to a /more/ complex and buggy solution.
K
Kaz Kylheku
Just watch out for C99 braindamage!
swprintf has an argument interface similar to the wide character
equivalent of snprintf, but you may be bitten by the gratuitously
different return value convention.
W
Walter Banks
Ben said:
This whole project thread has been filled how not to engineer software.
Application code specifically avoiding libraries, Not Invented Here,
random design with moving target specifications or no specifications,
ad hoc testing with a dose of 20+ Year old unresolved office battles,
interpersonal rivalry and off topic rants.
As several have stated not the environment that we are used to.
Regards
w..
S
Seebs
Yes, but it's important to be prepared to program in some of the many
environments which real programmers often end up having to work in.
To be fair, I've never had a coworker in the same class as Nilges. Not
even particularly close. But I have had to work with arbitrary or
bad specifications, specifications which change repeatedly during
implementation, old office battles, and vehement opposition to things which
were Not Invented Here.
At one point, I was asked to develop a linked list implementation. The
proposed design looked like this:
struct list_node {
struct list_node *next;
void *data;
};
struct list {
struct list_node *head;
struct list_node *tail;
};
The specification was much as you'd expect. Except for one TINY detail.
Which was that the formal specification was that
(struct list *) (x->tail->next) == x
whenever tail was not null.
That is to say, if the list contained any members, the "next" pointer for
the last member of the list was a pointer (suitably converted) to the list
object.
So iteration would look roughly like:
for (l = x->head; l->next != x; l = l->next) {
/* ... */
}
It took a day or so of effort for me to round up enough senior developers
to all sit on the guy and tell him that:
1. He was wrong.
2. He was micro-managing, which is presumptively wrong.
before we were allowed to use a more conventional design.
Having had to deal with things like a database in which the formal schema
description begins with "all fields are VARCHAR for simplicity", I found the
Nilges String Replace Challenge to be a surprisingly good approximation of
what programming work is often like in the real world.
(Disclaimer: All the above memories are faded with age. My current
environment is pretty good about this kind of stuff. I have no clue about
the office politics, as our management put a great deal of time and effort
into ensuring that they are Not Our Problem.)
-s
C
Chris M. Thomasson
[...]
Bingo! :^)
Bingo! :^)
W
Walter Banks
Seebs said:
I saw this 20 years ago and it became nothing but a memory as better
more effective approaches prevailed.
Software development practices have improved a lot as applications
have become more complex and requirements better defined.
w..