Why should it return found? If it gets to that line it's always a nullptr.

At this point I think we'd just be looking to use std::string::find, substr

This thread is a great example of why it is important to write tests.  We have at least five different implementations in this thread of `findx`, each with varying levels of “correct”.  Automated tests can provide an empirical measure of correctness.  And since `findx` is a pure function, we can easily write automated tests to help us.

First, a crude testing routine for any `findx` implementation:

const char* findx(const char*, const char*);

void test_findx() {
	struct test_t {
		const char* input;
		const char* subject;
		const char* expected;

		test_t(const char* input, const char* subject, const int pos) {
			this->input    = input;
			this->subject  = subject;
			this->expected = ( pos == -1 ) ? nullptr : (input + pos);
		}
	} tests[] = {
		test_t("abc",         "abc",  0),
		test_t("abcdef",      "abc",  0),
		test_t("ababac",      "abac", 2),
		test_t("ababac-----", "abac", 2),

		test_t("abc",         "xyz",  -1),
		test_t("abc",         "",     -1),
		test_t("",            "",     0),
		test_t("",            "a",    -1),

		// ...
	};

	int failed = 0;
	for ( const auto& test : tests ) {
		const char* result = findx(test.input, test.subject);

		if ( result != test.expected ) {
			failed ++;
			cerr << "Test #" << (&test - tests) << " failed" << endl;
		}
	}

	return failed;
}

And running the full example test here:  https://ideone.com/G2Suog#stdout

Test #0 failed: "abc" in "abc", expected "abc", got nullptr
Test #2 failed: "abac" in "ababac", expected "abac", got nullptr
Test #5 failed: "" in "abc", expected nullptr, got "abc"
Test #6 failed: "" in "", expected "", got nullptr
Failed 4 of 8 tests.

... we can see that there are a few cases we’ve missed.  And while we continually fix the implementation, we can think of more corner cases to add to the tests.

Testing can go along way in helping you write correct code and can also help you keep your sanity in face of bizarre bugs.

As a mathematician, the desired behavior of findx when the second argument is the empty string is obvious: The first instance of the empty string is found at the beginning of the string.

For instance, I could make a function that splits a string into substrings using a separator, like "split" in Perl. This is how that Perl function behaves:

	$ perl -e 'for $x (split ",", "a,b,c") { print "\"$x\"\n";}'
	"a"
	"b"
	"c"
	$ perl -e 'for $x (split "", "a,b,c") { print "\"$x\"\n";}'
	"a"
	","
	"b"
	","
	"c"

So if you look for the empty string, you find it everywhere, and "split" separates every character.

Lol, yes, the thread turned into unit tests because I apparently suck at doing them on the whim. And, yes, It should return found and did originally until I preferred the idea of only returning if strx:'\0' was encountered but did not test it well. My entire point in this thread was to expose marcus to some different coding ideas, and although he *hates* it, I think it has turned out ok, and I will probably continue to do it hopefully with "correctness" in the future. In the words of cartman, "i do wat i want". The function, I think, came a long way since its original conception. I did not realize early that a side-thought of a function project would indeed benefit from a proper unit testing routing or a better programmer, but it did turn out that way.