Implementing strstr
spinoza1111
program was trying to get out. Here it is: an implementation of strstr
including a call that returns the offset of the found substring. Two
hours including all comments and dedicatory ode, written for this
occasion.
#include <stdlib.h>
#include <stdio.h>
// ***************************************************************
// * *
// * strstr *
// * *
// * This function (strstr) finds a string, probably as fast as *
// * possible without extra memory usage over and above brute *
// * force. *
// * *
// * In searching a Nul terminated string for a substring, there *
// * are logically three possibilities in a left to right *
// * traversal of the master string that (1) looks for the *
// * first character of the target and then (2) matches all the *
// * remaining characters:
// * *
// * * (Erroneous): on the failure of a partial match, *
// * restart at the first nonmatching character. This is *
// * fast but wrong, since the matching string may *
// * overlap the partial match. *
// * *
// * * (Too slow): on the failure of a partial match, start*
// * one past the first character (of the partial match) *
// * *
// * * (Just right): while matching characters, note the *
// * leftmost character in the searched string, to the *
// * right of the first matched character, that matches *
// * both that character and, of course, the first *
// * character of the target. *
// * *
// * C H A N G E R E C O R D --------------------------------- *
// * DATE PROGRAMMER DESCRIPTION OF CHANGE *
// * -------- ---------- --------------------------------- *
// * 03 18 10 Nilges Version 1.0 *
// * *
// * ----------------------------------------------------------- *
// * *
// * To find a string, oh Muse! I sing, inside another String! *
// * Alternatives to me come in Three, ah, that's the thing: *
// * For the one thing for which the Wise must watch is mayhap, *
// * Partial occurences that most melancholy, overlap. *
// * The first is base, mechanical, low, and tragicomical: *
// * It's to restart from the previous beginning plus but One *
// * Oh what Mayhem to true Programming is thereby, done! *
// * But the job it will do, as did Hercules, *
// * His Labors for the Goddess cruel in Seneca's tragedies: *
// * Arduously and ignobly like unto the meanest Hind *
// * That knoweth not his Elbow from his Behind. *
// * The second is worse, a boner, a solecism, and a Seebach: *
// * The second restarts at the character that doth match! *
// * Oh muse! Such hellish Sights before me yawn: *
// * But be assur'd, 'tis darkest just before the Dawn. *
// * Shout for Victory, oh Thrace, and smite the Harp, and Grin: *
// * For lo, we start at the leftmost "handle" of the string *
// * When it occureth in *
// * The tragic partial match that hath failed us. *
// * If no such handle exists, then we can restart *
// * At the point of match failure: no, 'tis not a brain fart. *
// * Now we spy our magic bus: *
// * For this is the best Al Gore ithm *
// * That we can hope for in C, a language without Rhyme, or *
// * for that matter, Oh Muse! rhythm. *
// * *
// ***************************************************************
#define TRUTH -1
#define FALSITY 0
#define NULLITY 0
char * strstrWithIndex(char *strMaster,
char *strTarget,
int *ptrIndex)
{
char *ptrMaster = NULLITY;
char *ptrTarget = NULLITY;
char *ptrHandle = NULLITY;
int booFound = FALSITY;
if (!*strMaster || !*strTarget) return 0;
for (ptrMaster = strMaster; *ptrMaster;)
{
for (;
*ptrMaster && *ptrMaster != *strTarget;
ptrMaster++);
ptrTarget = strTarget;
*ptrIndex = ptrMaster - strMaster;
ptrHandle = 0;
for (;
*ptrTarget
?
(*ptrMaster
?
(*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
:
FALSITY)
:
(booFound = TRUTH, FALSITY);
ptrMaster++, ptrTarget++)
{
if (ptrHandle = 0
&&
ptrMaster > strMaster
&&
*ptrMaster == *strTarget)
ptrHandle = ptrTarget;
}
if (booFound) return strMaster + *ptrIndex;
if (ptrHandle) ptrMaster = ptrHandle + 1;
}
*ptrIndex = 0;
return 0;
}
char * strstr(char *strMaster, char *strTarget)
{
int ptrIndex = 0;
return strstrWithIndex(strMaster, strTarget, &ptrIndex);
}
int main(void)
{
char *ptrIndex1 = NULLITY;
int intIndex1 = 0;
printf("strstr Simplified\n\n");
printf("Expect 0: %d\n", strstr("", ""));
printf("Expect 0: %d\n", strstr("0123456789", ""));
printf("Expect 0: %d\n", strstr("", "0"));
printf("Expect 0: %d\n", strstr("Here", "There"));
ptrIndex1 = strstrWithIndex("There", "here", &intIndex1);
printf("Expect 1: %d\n", intIndex1);
ptrIndex1 = strstrWithIndex("They seek him here",
"here",
&intIndex1);
printf("Expect 14: %d\n", intIndex1);
ptrIndex1 = strstrWithIndex("They seek him there",
"here",
&intIndex1);
printf("Expect 15: %d\n", intIndex1);
ptrIndex1 = strstrWithIndex
("The clc regs seek him everywhere",
"here",
&intIndex1);
printf("Expect 28: %d\n", intIndex1);
printf("Expect 'h': %c\n", *ptrIndex1);
ptrIndex1 = strstrWithIndex
("Is he in Heaven? Or in Hell?",
"?",
&intIndex1);
printf("Expect 15: %d\n", intIndex1);
printf("Expect '?': %c\n", *ptrIndex1);
ptrIndex1 = strstrWithIndex
("That damn'd elusive Spinoza won't tell!",
"Spinoza",
&intIndex1);
printf("Expect 20: %d\n", intIndex1);
printf("Expect 'p': %c\n", *(ptrIndex1+1));
printf("Expect '0': %c\n", *strstr("0123456789", "0"));
printf("Expect '1': %c\n", *strstr("0123456789", "1"));
printf("Expect '0': %c\n", *strstr("0123456789", "0"));
printf("Expect '9': %c\n", *strstr("0123456789", "9"));
printf("Expect '5': %c\n", *strstr("0123456789", "345") + 2);
printf("Expect '8': %c\n", *strstr("0123456789", "89"));
ptrIndex1 = strstrWithIndex("0123456789A89AB",
"89AB",
&intIndex1);
printf("Expect 11: %d\n", intIndex1);
return 0;
}
Dr Malcolm McLean
>
> // * This function (strstr) finds a string, probably as fast as *
> // * possible without extra memory usage over and above brute *
> // * force. *
>
know the characteristics of the strings (natural English language,
protein sequence C code etc).
This is to scan the query string and take the two characters with the
least probability of appearing in your set. Eg for English language,
if the query is "quaker" you'd take 'q' and 'k'. Ypou then scan
looking only for that pair. If you find an exact match to the pair ypu
do a full scan.
Branimir Maksimovic
spinoza1111 <spino...@yahoo.com> wrote:
>
> // ***************************************************************
> // * *
> // * strstr *
> // * *
> // * This function (strstr) finds a string, probably as fast as *
Problem with strstr is that there is no strnstr.
For example:
if(!strcmp(readBuf_,"\r\n"))
{
rc = true;
}
else if((end = strstr(readBuf_,"\r\n\r\n")) && size_t(end-readBuf_)<=readBufSize_)
{
res_.append(readBuf_,end-readBuf_);
rc = true;
}
Disregard res_ as it is c++, but c++ doesn't have strnstr either!
How to use strstr safely when there is o strnstr and you work
with httpd 512 byte buffer eg?
Greets
Sometimes online sometimes not
pete
>
> In the replace() program of last month's flame festival, a little
> program was trying to get out. Here it is: an implementation of strstr
> including a call that returns the offset of the found substring. Two
> hours including all comments and dedicatory ode, written for this
> occasion.
> printf("Expect 0: %d\n", strstr("", ""));
> printf("Expect 0: %d\n", strstr("0123456789", ""));
That's not what strstr is supposed to do.
When the second argument to strstr points to an empty string,
then strstr is supposed to return the first argument,
which happens to be a non null pointer in the above cases.
#include <stddef.h>
char *str_str(const char *s1, const char *s2);
size_t str_len(const char *s);
char *str_chr(const char *s, int c);
int str_ncmp(const char *s1, const char *s2, size_t n);
char *str_str(const char *s1, const char *s2)
{
const int c = *s2++;
if (c != '\0') {
const size_t n = str_len(s2);
s1 = str_chr(s1, c);
while (s1 != NULL && str_ncmp(s1 + 1, s2, n) != 0) {
s1 = str_chr(s1 + 1, c);
}
}
return (char *)s1;
}
size_t str_len(const char *s)
{
size_t n;
for (n = 0; *s != '\0'; ++s) {
++n;
}
return n;
}
char *str_chr(const char *s, int c)
{
while (*s != (char)c) {
if (*s == '\0') {
return NULL;
}
++s;
}
return (char *)s;
}
int str_ncmp(const char *s1, const char *s2, size_t n)
{
const unsigned char *p1 = (const unsigned char *)s1;
const unsigned char *p2 = (const unsigned char *)s2;
for (;;) {
if (n-- == 0) {
return 0;
}
if (*p1 != *p2) {
return *p2 > *p1 ? -1 : 1;
}
if (*p1 == '\0') {
return 0;
}
++p1;
++p2;
}
}
--
pete
spinoza1111
wrote:
Interesting insight. I'd add a third overload allowing an optional
ranking of characters, with a #define symbol giving the ranking for
English text. I don't want the program to "learn" by remembering older
frequencies, since that is state, and state is best handled by object
oriented languages.
Why not scan for the least frequent character and then look around it
to see if it is in a substring?
spinoza1111
> On Fri, 19 Mar 2010 03:34:06 -0700 (PDT)
>
>
> > // ***************************************************************
> > // * *
> > // * strstr *
> > // * *
> > // * This function (strstr) finds a string, probably as fast as *
>
> Problem with strstr is that there is no strnstr.
> For example:
>
> if(!strcmp(readBuf_,"\r\n"))
> {
> rc = true;
> }
> else if((end = strstr(readBuf_,"\r\n\r\n")) && size_t(end-readBuf_)<=readBufSize_)
> {
> res_.append(readBuf_,end-readBuf_);
> rc = true;
> }
>
> Disregard res_ as it is c++, but c++ doesn't have strnstr either!
> How to use strstr safely when there is o strnstr and you work
> with httpd 512 byte buffer eg?
I don't see the problem. "My" strstr simply assumes it will be passed
a Nul terminated string. If it falls off the edge of a cliff, isn't
this the user's problem?
I grant that there is a genuine problem in C tools that modify memory
such as printf. But in general, strstr and suchlike tools have no way
of protecting themselves that I'm aware of against bad data.
>
> Greets
>
> --http://maxa.homedns.org/
>
> Sometimes online sometimes not
spinoza1111
> spinoza1111 wrote:
>
> > In the replace() program of last month's flame festival, a little
> > program was trying to get out. Here it is: an implementation of strstr
> > including a call that returns the offset of the found substring. Two
> > hours including all comments and dedicatory ode, written for this
> > occasion.
> > printf("Expect 0: %d\n", strstr("", ""));
> > printf("Expect 0: %d\n", strstr("0123456789", ""));
>
> That's not what strstr is supposed to do.
> When the second argument to strstr points to an empty string,
> then strstr is supposed to return the first argument,
> which happens to be a non null pointer in the above cases.
Ill-defined. I don't choose to simulate mistakes, here. A null master
string is one in which a target string can never occur: a null target
could only occur in a null master string, but see rule one.
Perhaps I'm being narrow minded.
I suppose you could make a case, in a world biased towards left to
right, that all strings start with a magic invisible null string,
including a null master string.
So test for a null target, and if it is found, return the master
string's address and an index of 0 in strstrWithIndex().
Then, and only then, return 0 (not found) if the master string is
null.
You know what? Done.
#include <stdlib.h>
#include <stdio.h>
// ***************************************************************
// * *
// * strstr *
// * *
// * This function (strstr) finds a string, probably as fast as *
// * possible without extra memory usage over and above brute *
// * force. *
// * *
// * In searching a Nul terminated string for a substring, there *
// * are logically three possibilities in a left to right *
// * traversal of the master string that (1) looks for the *
// * first character of the target and then (2) matches all the *
// * remaining characters: *
// * *
// * * (Erroneous): on the failure of a partial match, *
// * restart at the first nonmatching character. This is *
// * fast but wrong, since the matching string may *
// * overlap the partial match. *
// * *
// * * (Too slow): on the failure of a partial match, start*
// * one past the first character (of the partial match) *
// * *
// * * (Just right): while matching characters, note the *
// * leftmost character in the searched string, to the *
// * right of the first matched character, that matches *
// * both that character and, of course, the first *
// * character of the target. *
// * *
// * C H A N G E R E C O R D --------------------------------- *
// * DATE PROGRAMMER DESCRIPTION OF CHANGE *
// * -------- ---------- --------------------------------- *
// * 03 18 10 Nilges Version 1.0 *
// * *
// * 03 19 10 Nilges Version 1.1 *
// * *
// * 1. Incorporates Pete's suggestion*
// * that a null target string is *
// * always found at the start of *
// * the master string. *
// * *
// * 2. Results display enhanced *
// * *
// * 3. Poem corrected (doth NOT *
// * match) *
// * *
// * ----------------------------------------------------------- *
// * *
// * To find a string, oh Muse! I sing, inside another String! *
// * Alternatives to me come in Three, ah, that's the thing: *
// * For the one thing for which the Wise must watch is mayhap, *
// * Partial occurences that most melancholy, overlap. *
// * The first is base, mechanical, low, and tragicomical: *
// * It's to restart from the previous beginning plus but One *
// * Oh what Mayhem to true Programming is thereby, done! *
// * But the job it will do, as did Hercules, *
// * His Labors for the Goddess cruel in Seneca's tragedies: *
// * Arduously and ignobly like unto the meanest Hind *
// * That knoweth not his Elbow from his Behind. *
// * The second is worse, a boner, a solecism, and a Seebach: *
// * The second restarts at the character that doth not match! *
// * Oh muse! Such hellish Sights before me yawn: *
// * But be assur'd, 'tis darkest just before the Dawn. *
// * Shout for Victory, oh Thrace, and smite the Harp, and Grin: *
// * For lo, we start at the leftmost "handle" of the string *
// * When it occureth in *
// * The tragic partial match that hath failed us. *
// * If no such handle exists, then we can restart *
// * At the point of match failure: no, 'tis not a brain fart. *
// * Now we spy our magic bus: *
// * For this is the best Al Gore ithm *
// * That we can hope for in C, a language without Rhyme, or *
// * for that matter, Oh Muse! rhythm. *
// * *
// ***************************************************************
#define TRUTH -1
#define FALSITY 0
#define NULLITY 0
char * strstrWithIndex(char *strMaster,
char *strTarget,
int *ptrIndex)
{
char *ptrMaster = NULLITY;
char *ptrTarget = NULLITY;
char *ptrHandle = NULLITY;
int booFound = FALSITY;
*ptrIndex = 0; // Rel. 1.1
if (!*strTarget) return strMaster; // Rel. 1.1
if (!*strMaster) return 0; // Rel. 1.1
printf("strstr\n\n");
printf("Expect 0: %x\n", *strstr("", ""));
printf("Expect '0': '%c'\n", *strstr("0123456789", ""));
>
spinoza1111
One reason for submitting this was to show how very wrong it is to
claim that "nothing useful is learnt in uni".
Note, please, the three-way reasoning in the above. It selects three
cases which seem almost tangential to the focus of the code, where in
business it's sooooo important to be focused (in a pseudo-scientific
spirit that deserves to be described as the quick, attentive motions
of the servant and not the attention of the scientist).
But in logic the alternatives "just happen" to exhaust all possible
cases! Which means that if we focus as the scientist and not the
servant on each case in turn, we've proved something, which rarely, in
my experience, happens in the profit and rent seeking world.
I first encountered this type of disection, trisection, dilemma and
trilemma in a book on formal automata, and would have preferred to
encounter it in a college classroom cleared of thugs.
spinoza1111
I suppose that in rel. 1.3 I should check for NULL values of strMaster
and strTarget to forestall a Pedant Attack. But there is no SIMPLE
way, is there, of interrupting yourself as in a C Sharp try..catch
when you refer to memory that is not yours when a string without a Nul
terminator is passed to you.
Ersek, Laszlo
> Problem with strstr is that there is no strnstr.
> For example:
>
> if(!strcmp(readBuf_,"\r\n"))
> {
> rc = true;
> }
> else if((end = strstr(readBuf_,"\r\n\r\n")) && size_t(end-readBuf_)<=readBufSize_)
> {
> res_.append(readBuf_,end-readBuf_);
> rc = true;
> }
>
> Disregard res_ as it is c++, but c++ doesn't have strnstr either!
> How to use strstr safely when there is o strnstr and you work
> with httpd 512 byte buffer eg?
(Presumably I have no idea of the real topic of this thread, but I won't
let that disturb me.)
If you work with a "httpd buffer", you'll make that "char unsigned", not
plain char. Then you won't use strstr() but memmem() (not standard C) or
your own equivalent implementation.
#define _GNU_SOURCE
#include <string.h>
void *memmem(const void *haystack, size_t haystacklen,
const void *needle, size_t needlelen);
Finally, I hate to pull the EBCDIC card again (chill out, Kaz :) --
simply killfile me if you haven't done so yet), but "\r\n" is *not* what
you mean. RFC 2616 2.2 "Basic Rules" says,
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
So that would be, unless you say "this program works only with ASCII":
{
char unsigned buffer[BUFSIZE];
size_t loaded;
/* disservice to whomever signs your paycheck */
static const char unsigned crlf[] = { 0x0Du, 0x0Au };
char unsigned *found;
/* ... */
found = memmem(buffer, loaded, crlf, sizeof crlf);
/* ... */
}
lacos
Branimir Maksimovic
la...@ludens.elte.hu (Ersek, Laszlo) wrote:
> In article <20100319123852.523bdec1@maxa>, Branimir Maksimovic
> <bm...@hotmail.com> writes:
>
> > Problem with strstr is that there is no strnstr.
> > For example:
> >
> > if(!strcmp(readBuf_,"\r\n"))
> > {
> > rc = true;
> > }
> > else if((end = strstr(readBuf_,"\r\n\r\n")) &&
> > size_t(end-readBuf_)<=readBufSize_) {
> > res_.append(readBuf_,end-readBuf_);
> > rc = true;
> > }
> >
> > Disregard res_ as it is c++, but c++ doesn't have strnstr either!
> > How to use strstr safely when there is o strnstr and you work
> > with httpd 512 byte buffer eg?
>
> (Presumably I have no idea of the real topic of this thread, but I
> won't let that disturb me.)
>
> If you work with a "httpd buffer", you'll make that "char unsigned",
> not plain char.
True, but that complicates things. Simplier is to use compiler switch ;)
to make char unsigned by default, and when signed one is needed o
use "signed char" type. Yes, implementation can default either
signed or unsigned ;)
> Then you won't use strstr() but memmem() (not
> standard C) or your own equivalent implementation.
that is the problem, I want to use standard strstr, not
some myself cooked string functions or such!
Pretty impossible in standard C ;)
>
> #define _GNU_SOURCE
> #include <string.h>
>
> void *memmem(const void *haystack, size_t haystacklen,
> const void *needle, size_t needlelen);
>
Thanks, I didn't new there is memmem.
> Finally, I hate to pull the EBCDIC card again (chill out, Kaz :) --
> simply killfile me if you haven't done so yet), but "\r\n" is *not*
> what you mean. RFC 2616 2.2 "Basic Rules" says,
>
> CR = <US-ASCII CR, carriage return (13)>
> LF = <US-ASCII LF, linefeed (10)>
>
> So that would be, unless you say "this program works only with ASCII":
>
> {
> char unsigned buffer[BUFSIZE];
> size_t loaded;
>
> /* disservice to whomever signs your paycheck */
> static const char unsigned crlf[] = { 0x0Du, 0x0Au };
You are right, in this case, we must be sure \r\n is 0xd0xa.
One question here. In c++ Im pretty sure that when you write 0xff
it defaults to unsigned type? Is that same in C or different.
It's pretty difficult to write C/C++ and not make such errors.
Thanks, again and
Greets!
Ersek, Laszlo
> One question here. In c++ Im pretty sure that when you write 0xff
> it defaults to unsigned type? Is that same in C or different.
C90 6.1.3.2 Integer constants
----v----
hexadecimal-constant
0x hexadecimal-digit
0X hexadecimal-digit
hexadecimal-constant hexadecimal-digit
[...]
The type of an integer constant is the first of the corresponding list
in which its value can be represented. Unsuffixed decimal: int, long
int, unsigned long int; unsuffixed octal or hexadecimal: int, unsigned
int, long int, unsigned long int; [...]
----^----
Same effect by C99 6.4.4.1 "Integer constants" p5.
C++98 and C++03 2.13.1 "Integer literals" p2:
----v----
[...] If it is octal or hexadecimal and has no suffix, it has the first
of these types in which its value can be represented: int, [...]
----^----
-> 0xff has type int "everywhere".
lacos
Seebs
> spinoza1111 wrote:
>> In the replace() program of last month's flame festival, a little
>> program was trying to get out. Here it is: an implementation of strstr
>> including a call that returns the offset of the found substring. Two
>> hours including all comments and dedicatory ode, written for this
>> occasion.
*snerk*
>> printf("Expect 0: %d\n", strstr("", ""));
>> printf("Expect 0: %d\n", strstr("0123456789", ""));
> That's not what strstr is supposed to do.
You're arguing with someone who is not a first-year CS student and
claims to have needed TWO HOURS to implement strstr.
Is there any genuine point in pointing out errors?
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Scott Fluhrer
"Seebs" <usenet...@seebs.net> wrote in message
news:slrnhq7d2j.rt9...@guild.seebs.net...
> On 2010-03-19, pete <pfi...@mindspring.com> wrote:
>> spinoza1111 wrote:
>>> In the replace() program of last month's flame festival, a little
>>> program was trying to get out. Here it is: an implementation of strstr
>>> including a call that returns the offset of the found substring. Two
>>> hours including all comments and dedicatory ode, written for this
>>> occasion.
>
> *snerk*
>
>>> printf("Expect 0: %d\n", strstr("", ""));
>>> printf("Expect 0: %d\n", strstr("0123456789", ""));
>
>> That's not what strstr is supposed to do.
>
> You're arguing with someone who is not a first-year CS student and
> claims to have needed TWO HOURS to implement strstr.
>
> Is there any genuine point in pointing out errors?
Maybe one hour and fifty minutes was taken writing the poem in the
comments???
--
poncho
spinoza1111
> On 2010-03-19, pete <pfil...@mindspring.com> wrote:
>
> >spinoza1111wrote:
> >> In the replace() program of last month's flame festival, a little
> >> program was trying to get out. Here it is: an implementation of strstr
> >> including a call that returns the offset of the found substring. Two
> >> hours including all comments and dedicatory ode, written for this
> >> occasion.
>
> *snerk*
>
> >> printf("Expect 0: %d\n", strstr("", ""));
> >> printf("Expect 0: %d\n", strstr("0123456789", ""));
> > That's not what strstr is supposed to do.
>
> You're arguing with someone who is not a first-year CS student and
> claims to have needed TWO HOURS to implement strstr.
Peter, once more:
The time it takes is not even a crude measure of competence save in
the nastiest form of business office, such as yours, in which you post
the following Coding Horror:
while ((prefix[prefix_len - 1] == '/') && (prefix_len > 0))
in order to steal intellectual production and transform it into
intellectual property of Wind River Systems, by getting unsuspecting
people to find your bugs. The above bug demonstrates even more clearly
than your off by one strlen, your script kiddie %s filter that didn't
find %s and "the heap is a DOS term" that you, sir, are incompetent.
I'm not a subservient, autistic little code monkey as you increasingly
seem to be who makes messes in minutes and then expects others to fix
or forgive his errors, while assaulting hard working and best-selling
computer authors and their families, you dig me?
Furthermore, you missed the part where I said that the documentation
(which is ten times more literate and well formatted than the crap you
published as the pseudo root) and dedicatory ode (an original poem
recapitulating the essay) was part of the two hours.
Finally, you need to stop opening your punk byotch mouth about what
people do in first-year cs classes. I've TAUGHT computer science,
asshole. You were afraid to take ANY computer science classes
whatsoever, and you majored in the favorite college major of people
who can neither write nor do mathematics, that being computer science.
So, once more, asshole. How do you know the assignments in a first
year CS class?
You backstabbed Herb Schildt and paid your way into your current job,
and you're here for commercial gain as an employee of Wind River
Systems. I suggest you leave.
>
> Is there any genuine point in pointing out errors?
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> "Seebs" <usenet-nos...@seebs.net> wrote in message
>
> news:slrnhq7d2j.rt9...@guild.seebs.net...
>
>
>
>
>
> > On 2010-03-19, pete <pfil...@mindspring.com> wrote:
> >>spinoza1111wrote:
> >>> In the replace() program of last month's flame festival, a little
> >>> program was trying to get out. Here it is: an implementation of strstr
> >>> including a call that returns the offset of the found substring. Two
> >>> hours including all comments and dedicatory ode, written for this
> >>> occasion.
>
> > *snerk*
>
> >>> printf("Expect 0: %d\n", strstr("", ""));
> >>> printf("Expect 0: %d\n", strstr("0123456789", ""));
>
> >> That's not what strstr is supposed to do.
>
> > You're arguing with someone who is not a first-year CS student and
> > claims to have needed TWO HOURS to implement strstr.
>
> > Is there any genuine point in pointing out errors?
>
> Maybe one hour and fifty minutes was taken writing the poem in the
> comments???
Probably forty minutes to code, forty minutes to document, forty
minutes to write the poem. But only in nasty little business offices
is time taken the sole measure of quality. In my book, someone who
takes extra time loves his work and is trying to do a better job.
spinoza1111
Correction: "that being psychology", not "that being "computer
science".
Peter, I'd resolved to stay away from the pseudo root code but then
you came in here. I've complained to Apress about your behavior. The
gloves are off, and I will win.
bartc
You might be interested in this language then instead:
http://en.wikipedia.org/wiki/Shakespeare_(programming_language)
(you might need to add ")" on url)
--
Bartc
spinoza1111
found we set the ptrIndex to the master string at one past the handle:
this is incorrect, for the start of the main loop will then search for
the first character of the NEXT occurence, missing the overlapping
occurence.
Here is the corrected code.
#include <stdlib.h>
#include <stdio.h>
// * 03 19 10 Nilges Version 1.1 *
// * *
// * 1. Incorporates Pete's suggestion*
// * that a null target string is *
// * always found at the start of *
// * the master string. *
// * *
// * 2. Results display enhanced *
// * *
// * 03 19 10 Nilges Version 1.11: bug: ptrMaster was *
// * incorrectly set one past the *
// * ptrHandle *
*ptrIndex = 0; // Rel. 1.1
if (!*strTarget) return strMaster; // Rel. 1.1
if (!*strMaster) return 0; // Rel. 1.1
for (ptrMaster = strMaster; *ptrMaster;)
{
for (;
*ptrMaster && *ptrMaster != *strTarget;
ptrMaster++);
ptrTarget = strTarget;
*ptrIndex = ptrMaster - strMaster;
ptrHandle = 0;
for (;
*ptrTarget
?
(*ptrMaster
?
(*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
:
FALSITY)
:
(booFound = TRUTH, FALSITY);
ptrMaster++, ptrTarget++)
{
if (ptrHandle = 0
&&
ptrMaster > strMaster
&&
*ptrMaster == *strTarget)
ptrHandle = ptrTarget;
}
if (booFound) return strMaster + *ptrIndex;
if (ptrHandle) ptrMaster = ptrHandle; // Rel. 1.11 bug fix
}
*ptrIndex = 0;
return 0;
}
char * strstr(char *strMaster, char *strTarget)
{
int ptrIndex = 0;
return strstrWithIndex(strMaster, strTarget, &ptrIndex);
}
int main(void)
{
char *ptrIndex1 = NULLITY;
int intIndex1 = 0;
printf("strstr\n\n");
printf("Expect 0: %x\n", *strstr("", ""));
printf("Expect '0': '%c'\n", *strstr("0123456789", ""));
spinoza1111
> spinoza1111wrote:
Thanks, very interesting link and "esoteric" programming language.
Ben Bacarisse
> The first two releases had a bug: after a one character "handle" is
> found we set the ptrIndex to the master string at one past the handle:
> this is incorrect, for the start of the main loop will then search for
> the first character of the NEXT occurence, missing the overlapping
> occurence.
You have a == vs = type that makes this explanation unlikely. As far
as I can tell, ptrHandle is never anything other a null pointer and
none of the code involving it as any effect at all. That includes
this supposed fix.
<snip>
--
Ben.
spinoza1111
if (ptrHandle = 0 <- wrong, should be ==
&&
ptrMaster > strMaster
&&
*ptrMaster == *strTarget)
ptrHandle = ptrTarget;
Oops....very good call, thanks. I clearly need more test cases: the
overlaps are never found.
I will post a fixed version after I get back from class.
>
> <snip>
> --
> Ben.
Dr Malcolm McLean
>
> You're arguing with someone who is not a first-year CS student and
> claims to have needed TWO HOURS to implement strstr.
>
> Is there any genuine point in pointing out errors?
>
/*
quick and nasty strstr. Untested. Posted to comp.lang.c "as is"
without warrantry or guarantee of any kind, including implied
warrantry of merchanability or fitness for any particular purpose.
*/
char *mystrstr(char *str, char *sub)
{
size_t i; /* If you think this is ugly, join the campaign for 64-bit
ints */
while(*str)
{
for(i=0;str[i]==sub[i] && str[i];i++);
if(!sub[i])
return str;
str++;
}
return 0;
}
However it's a bit cryptic, particularly the for loop.
Whilst there's always the argument that as long as the interfaces are
nice, the code doesn't matter, I'd like to see a rather better job.
Then it will return a match to the first character if sub is the
empty string. I don't know offhand whether this is allowed. I'd have
to check the standard for a real implementation intended to be shipped
to someone else.
Two hours isn't unreasonable for a production-quality strstr.
spinoza1111
wrote:
Well, I'm not done, as Ben has pointed out. There's a serious bug in
the code, and when I fixed it, further bugs arose.
However, I'd remark that one of the reasons I left the programming
field for far greener pastures after a successful thirty year career,
apart from not having to work with personalities like Seebach, was the
constant subordination of human needs (including the human need for
creative expression and helping one's fellow man) to "business" needs,
corporate speak for the profits of the few at the expense of the many.
Therefore, I'm not trying to either create a "production" quality
strstr nor even an instructional strstr. Nobody needs any lessons in
practical programming since it is rare today and today involves too
many lessons in subservience and backstabbing which I am unqualified
to teach.
Instead, as what Kant would call "a citizen of a better world" I am
writing code slowly to create solutions optimal in all directions
(efficiency and clarity) "as if" the world as presently constituted
needed any such thing. And while the efficiency is mathematical and
the same for everyone, it appears that my predicates of clarity
(greater use of literate English, somewhat longer identifiers, pre-
Szymonyi "Hungarian") are very different from those of others,
although the sustainability of the criminal argot of most programming
styles today is questionable.
Therefore, this, bugs and all, is a purely artistic gesture with
religious overtones, referring back to a time when art and religion
were fused. It's cave painting at the end of time.
PS. None of this is tongue in cheek and I shit you not.
spinoza1111
About ten minutes of work produces rel 1.12. This fixes the bug that
Ben noted, where a = was used in place of ==. Another bug was found
such that we noted the char "handle" starting, not one after the start
of the string being tested for a match, but at the start of that
string.
The code once again executes the test suite, but:
* Far more tests are needed.
* A correctness proof in English is clearly needed. Dijkstra would
have done this first.
#include <stdlib.h>
#include <stdio.h>
// * 03 19 10 Nilges Version 1.1 *
// * *
// * 1. Incorporates Pete's suggestion*
// * that a null target string is *
// * always found at the start of *
// * the master string. *
// * *
// * 2. Results display enhanced *
// * *
// * 03 19 10 Nilges Version 1.11: bug: ptrMaster was *
// * incorrectly set one past the *
// * ptrHandle *
// * *
// * 03 20 10 Nilges Version 1.12 *
// * *
// * 1. Bug (reported by BB): *
// * assignment used in place of *
// * equality test *
// * *
// * 2. Bug: incorrect test for noting *
// * char handle goes all the way *
// * back to start of string *
// * *
// * *
char *ptrMasterStart = NULLITY;
int booFound = FALSITY;
*ptrIndex = 0; // Rel. 1.1
if (!*strTarget) return strMaster; // Rel. 1.1
if (!*strMaster) return 0; // Rel. 1.1
for (ptrMaster = strMaster; *ptrMaster;)
{
for (;
*ptrMaster && *ptrMaster != *strTarget;
ptrMaster++);
ptrTarget = strTarget;
*ptrIndex = ptrMaster - strMaster;
ptrHandle = 0;
ptrMasterStart = ptrMaster; // Rel 1.12
for (;
*ptrTarget
?
(*ptrMaster
?
(*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
:
FALSITY)
:
(booFound = TRUTH, FALSITY);
ptrMaster++, ptrTarget++)
{
if (ptrHandle == 0 // Rel 1.12
&&
ptrMaster > ptrMasterStart
&&
*ptrMaster == *strTarget)
ptrHandle = ptrTarget;
}
if (booFound) return strMaster + *ptrIndex;
if (ptrHandle) ptrMaster = ptrHandle; // Rel. 1.11 bug fix
}
*ptrIndex = 0;
return 0;
}
char * strstr(char *strMaster, char *strTarget)
{
int ptrIndex = 0;
return strstrWithIndex(strMaster, strTarget, &ptrIndex);
}
int main(void)
{
char *ptrIndex1 = NULLITY;
int intIndex1 = 0;
printf("strstr Version 1.12\n\n");
printf("Expect 0: %x\n", *strstr("", ""));
printf("Expect '0': '%c'\n", *strstr("0123456789", ""));
Seebs
> A quick and nasty strstr should only take a minute or so to write.
Right.
> However it's a bit cryptic, particularly the for loop.
> Whilst there's always the argument that as long as the interfaces are
> nice, the code doesn't matter, I'd like to see a rather better job.
> Then it will return a match to the first character if sub is the
> empty string. I don't know offhand whether this is allowed. I'd have
> to check the standard for a real implementation intended to be shipped
> to someone else.
> Two hours isn't unreasonable for a production-quality strstr.
I'm not sure about that. It's a pretty simple function. And yes, yours
is fine -- the first occurrence of an empty string is the zero bytes
before the first character of the haystack.
But, that said... It's not as though Nilges produced one of production
quality. He spent two hours producing something that wouldn't get a
passing grade in a first-semester programming course. That's why I
have concluded that it's simply not worth trying to explain his bugs
to him.
spinoza1111
>
> > You're arguing with someone who is not a first-year CS student and
> > claims to have needed TWO HOURS to implement strstr.
>
> > Is there any genuine point in pointing out errors?
>
> A quick and nasty strstr should only take a minute or so to write.
I hate those words, "quick and dirty", or "quick and nasty", whether
they're from Seebs or you, Malcolm. But I understand that in your
case, but not Seebs, that you distance yourself from them, since like
me you don't have to be a programmer, subordinate in the programming
dreamtime to enslaving myths.
What they mean is that programmers, rather in the way that symphony
orchestra members who don't get adequate rehearsal time, are never
given, in capitalist second nature, enough time as a matter of course.
And, this is for the same reason that no real, ordinary programmers
have anything like economic security by virtue of being programmers,
only if they live in France, or some such country which gives dignity
and self-respect to all in the form of a safety net and worker
ownership.
As a minatory phrase, "quick and dirty" means that the programmer is
regarded, without any chance for appeal or review, as one of Frederick
Taylor's "typical", average and therefore definitional worker, who
will, if given enough time, use most of that time to loaf on the job.
It makes invisible the countless actual programmers who would, like
most other human beings, be delighted to do a good to great job if
given a decent amount of time in a humane (four day) work week.
The final irony is that Seebach, who barges in here to call me names
and condemn me for taking "too long" while pretending in a cowardly
fashion to speak to others, takes megatime to deliver anything useful
and in all cases in terms of my standards of literate programming,
delivers a mess. Over in another thread, he presents a pseudo root
simulator for Linux that, he says, took two months and yet has code
that tests indexes for usability after using them.
These bugs are, I believe, different in kind from the normal
programmer bug, for reasons I have outline elsewhere, because while a
C programmer might mistakenly type "=" meaning "==", it takes real
work to put the index test after the &&. It also takes what I feel to
be an insensitivity to the elegance of lazy evaluation. The
distinction between = & == in C has long been recognized as a "bug" in
the sense of a language design boner.
I believe Seebach does so because he's exclusively a creature of the
reified and second-hand world of corporate programming, not having any
academic preparation in freedom of thought and collegiality and indeed
contemptuous of any notion that any such things exist. In this
twittering world, a constructed Concept (the "bug") is uninterrogated
to show differences in bugs other than convenient taxonomies, and the
Concept becomes naturally more important than human lives (in the case
of collateral damage in military software where the de minimis
connotation of "bug" dates from hasty and high pressure WWII projects)
and reputation (in the case of Schildt).
Nick
> On 19 Mar, 17:27, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> You're arguing with someone who is not a first-year CS student and
>> claims to have needed TWO HOURS to implement strstr.
>>
>> Is there any genuine point in pointing out errors?
>>
> A quick and nasty strstr should only take a minute or so to write.
I've seen it implemented using strchr and strcmp - something like this:
/* written straight into newsreader - utterly untested */
a_strstr(const char *substrate, const char *pattern) {
while(substrate = strchr(substrate,*pattern) {
if(strcmp(substrate,pattern) == 0)
return substrate;
}
return NULL;
}
You can make it fractionally more efficient by advancing the pointers by
one before comparing but you need to be careful then with short
substrates.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Dr Malcolm McLean
> Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > On 19 Mar, 17:27, Seebs <usenet-nos...@seebs.net> wrote:
>
> >> You're arguing with someone who is not a first-year CS student and
> >> claims to have needed TWO HOURS to implement strstr.
>
> >> Is there any genuine point in pointing out errors?
>
> > A quick and nasty strstr should only take a minute or so to write.
>
> I've seen it implemented using strchr and strcmp - something like this:
>
> /* written straight into newsreader - utterly untested */
> a_strstr(const char *substrate, const char *pattern) {
> while(substrate = strchr(substrate,*pattern) {
> if(strcmp(substrate,pattern) == 0)
> return substrate;
> }
> return NULL;
>
> }
>
> You can make it fractionally more efficient by advancing the pointers by
> one before comparing but you need to be careful then with short
> substrates.
>
You need strncmp, which entails a call to strlen() to get the length
of the pattern.
Nick
Good point. I said I'd not tested it. That's exactly what the BSD code
you can find on the web (written by Chris Torek, no less) does -
although it walks the string explicitly char by char.
spinoza1111
> On 2010-03-20, Dr Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
>
> > A quick and nasty strstr should only take a minute or so to write.
>
> Right.
>
> > However it's a bit cryptic, particularly the for loop.
> > Whilst there's always the argument that as long as the interfaces are
> > nice, the code doesn't matter, I'd like to see a rather better job.
> > Then it will return a match to the first character if sub is the
> > empty string. I don't know offhand whether this is allowed. I'd have
> > to check the standard for a real implementation intended to be shipped
> > to someone else.
> > Two hours isn't unreasonable for a production-quality strstr.
>
> I'm not sure about that. It's a pretty simple function. And yes, yours
> is fine -- the first occurrence of an empty string is the zero bytes
> before the first character of the haystack.
>
> But, that said... It's not as though Nilges produced one of production
> quality. He spent two hours producing something that wouldn't get a
> passing grade in a first-semester programming course. That's why I
I'll ask you again, and I will keep asking you, if necessary in a
courtroom.
How would you know?
By your own admission, you have never taken a single class in
computer science. Because you're a pretentious autistic twit, you
interfered with homework assignments as a tutor, and we have no
information as to whether your "assistance", based as it was with
playing with the toys in your bedroom, was of any value.
If your academic family homeschooled you, this is merely a reason for
outlawing homeschooling altogether. I have long suspected that it will
create a generation of creeps who shit on people, because they haven't
learned how to work in groups.
You scorn the simplicity of strstr (having proven yourself incompetent
at the simplest of problems: strlen). Having taught computer science
and read Dijkstra, I am aware that simple problems are the best for
exposition and contain depths. Malcolm has made some interesting
comments in this regard. I'm not interested in hiding my incompetence
(as you seem to be) by pretending you're writing OS code ("pseudo" is
apposite in your case).
Peter, you took two months to write a pseudo root simulator of
questionable utility in which you test an index for validity after you
use it, and use the letter o as a variable name.
So fuck off. Businessmen like to reference academia because it's
something they think they can buy and sell. It's not. You're not even
a businessman, nor even anything resembling a man. You're a nasty
little clerk and an incompetent programmer who's here, apparently on
behalf of your employer, to get incompetent code debugged by slaves.
> have concluded that it's simply not worth trying to explain his bugs
> to him.
No, but I had to explain order-of-magnitude more egregious bugs (off
by one strlen) to you, and Kiki. You claim elsewhere that you get the
simple things wrong but are good at the complex things because Mommy's
little darling gots ADHD (an unprofessional revelation which damages
your employer), but what's interesting is the Popperian
unfalsifiability of this claim.
Sure, Einstein (cf Kaufmann 2007) was bad at math in fact. However,
Einstein NEVER attacked his colleauges as you attack Schildt (that was
Edward Teller, the genocide who invented the hydrogen bomb, and your
attacks suggest a deep insecurity based on a lack of real technical
accomplishment. I've searched for accomplishments comparable to what I
did when I was your age, and have found nothing. According to
Kaufmann, Einstein compensated for his mathematical deficiencies
(where in fact he was merely not a mathematician like Godel) by being
an excellent visual and physical reasoner. But your lack of talent in
the small doesn't scale. It don't turn into fine wine, Peter. And you
give me little reason to give you "the benefit of the doubt".
>
> -s
> --
spinoza1111
wrote:
Good point. It's why I write complete and literate documentation
before coding. We need to think ahead. I missed that bug in Fred's
code.
The only reason I didn't use pre-existing str functions is I refuse to
use string.h.
spinoza1111
Gee, no Heathfield Factor. Wonder where the big lug is.
pete
> On 2010-03-19, pete <pfi...@mindspring.com> wrote:
>> spinoza1111 wrote:
>>> In the replace() program of last month's flame festival, a little
>>> program was trying to get out. Here it is: an implementation of strstr
>>> including a call that returns the offset of the found substring. Two
>>> hours including all comments and dedicatory ode, written for this
>>> occasion.
>
> *snerk*
>
>>> printf("Expect 0: %d\n", strstr("", ""));
>>> printf("Expect 0: %d\n", strstr("0123456789", ""));
>
>> That's not what strstr is supposed to do.
>
> You're arguing with someone who is not a first-year CS student and
> claims to have needed TWO HOURS to implement strstr.
>
> Is there any genuine point in pointing out errors?
I like to discuss C.
Sometimes I make mistakes and then other people correct me.
Sometimes, when I don't make a mistake,
other people will attempt to correct me.
--
pete
pete
> The only reason I didn't use pre-existing str functions is I refuse to
> use string.h.
You can write all of these portably in C,
using only <stddef.h> for size_t
void *memset(void *s, int c, size_t n);
void *memcpy(void *s1, const void *s2, size_t n);
void *memmove(void *s1, const void *s2, size_t n);
void *memchr(const void *s, int c, size_t n);
int memcmp(const void *s1, const void *s2, size_t n);
size_t strlen(const char *s);
char *strcpy(char *s1, const char *s2);
char *strncpy(char *s1, const char *s2, size_t n);
char *strcat(char *s1, const char *s2);
char *strncat(char *s1, const char *s2, size_t n);
char *strchr(const char *s, int c);
char *strrchr(const char *s, int c);
int strcmp(const char *s1, const char *s2);
int strncmp(const char *s1, const char *s2, size_t n);
size_t strspn(const char *s1, const char *s2);
size_t strcspn(const char *s1, const char *s2);
char *strpbrk(const char *s1, const char *s2);
char *strstr(const char *s1, const char *s2);
char *strtok(char *s1, const char *s2);
--
pete
spinoza1111
> spinoza1111wrote:
Yes, you can. But even your rewrite will preserve Nul termination,
which I claim sucks.
Ben Bacarisse
<snip>
> About ten minutes of work produces rel 1.12. This fixes the bug that
> Ben noted, where a = was used in place of ==.
I did not claim that = in place of == was a bug. In fact it is
obvious that putting == back introduces more bugs. My point was that
you did not know what your code was doing: you reported favourably on
a bug fix that could not possibly have any effect. You can't fix (or
do pretty much anything with) code you don't understand.
I don't expect you to change your style -- you've evolved it to
provoke a response here rather than make your code clear -- but if
there are any people learning C who are tempted to copy it: please
don't -- it confuses even the author of it.
<snip>
--
Ben.
Seebs
> I like to discuss C.
> Sometimes I make mistakes and then other people correct me.
> Sometimes, when I don't make a mistake,
> other people will attempt to correct me.
You have a point. I fell into the trap of assuming that a post in
reply to something written by Nilges was offered in the hopes that he'd
comprehend it.
Seebs
>> The only reason I didn't use pre-existing str functions is I refuse to
>> use string.h.
> You can write all of these portably in C,
> using only <stddef.h> for size_t
You can.
However, the statement by Nilges above highlights a particular kind of
madness.
Why doesn't he use string.h? From the rest of what he's written, I'd guess
that it's because he thinks null-terminated strings are error-prone and
poorly designed.
So. Avoiding null-terminated strings? A plausible solution.
Writing your own code to manipulate them, demonstrating repeatedly that,
at least for you, the design is indeed highly error-prone, and simply beyond
your abilities to debug in a reasonable amount of time? Stupid.
If you have to use null-terminated strings, the sane thing to do would
be to use the *already debugged* standard tools, reducing your exposure
to the sorts of errors that crop up when you start messing with strings
directly.
pete
> On 2010-03-20, pete <pfi...@mindspring.com> wrote:
>> spinoza1111 wrote:
>>> The only reason I didn't use pre-existing str functions is I refuse to
>>> use string.h.
>
>> You can write all of these portably in C,
>> using only <stddef.h> for size_t
>
> You can.
>
> However, the statement by Nilges above highlights a particular kind of
> madness.
>
> Why doesn't he use string.h? From the rest of what he's written, I'd guess
> that it's because he thinks null-terminated strings are error-prone and
> poorly designed.
I only write like that as a programming exercise.
There is no end of places in C programming to make mistakes in.
In my opinion, the main usefulness of this newsgroup,
is to learn how to write so as to avoid making mistakes in C.
After a while, I don't think that you will continue to wonder
about why Nilges does what he does.
--
pete
Seebs
> I only write like that as a programming exercise.
Yup.
> There is no end of places in C programming to make mistakes in.
> In my opinion, the main usefulness of this newsgroup,
> is to learn how to write so as to avoid making mistakes in C.
That can be a very good idea.
> After a while, I don't think that you will continue to wonder
> about why Nilges does what he does.
I probably will until either I can confirm the specific insanity or
come up with a rational explanation. Nilges does not write like someone
who thinks he is trying to learn to avoid mistakes; he writes like
someone who is trying to prove that everyone else is wrong about how
to do things.
Morris Keesan
wrote:
> #define TRUTH -1
> #define FALSITY 0
> #define NULLITY 0
What's the point of defining TRUTH as -1, instead of accepting the
language-defined truth value of 1, especially since the only thing
you ever do with this value (based on an admittedly quick scan of your
code) is assign it, under some conditions, to booFound, whose value
is then tested by "if (booFound)"?
Likewise, why obfuscate things by defining your own NULLITY macro
instead of using the standard-defined NULL?
...
> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
If TRUTH were defined in the expected way, this would be equivalent to
(*ptrMaster == *ptrTarget)
which would be much clearer to the reader. The larger expression,
> *ptrTarget
> ?
> (*ptrMaster
> ?
> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
> :
> FALSITY)
appears to have been composed solely for its confusion factor, since as
a boolean expression it's equivalent to
(*ptrTarget && *ptrMaster && (*ptrMaster == *ptrTarget))
or the even simpler
(*ptrTarget && (*ptrTarget == *ptrMaster))
--
Morris Keesan -- mke...@post.harvard.edu
Dr Malcolm McLean
>
> What's the point of defining TRUTH as -1, instead of accepting the
> language-defined truth value of 1,
>
also, if booleans are one bit, a set bit is -1 in two's complement
notation.
As an added bonus you get an error if you try to get the root of
TRUTH, unless you accept that the answer is complex.
Seebs
> On Fri, 19 Mar 2010 06:34:06 -0400, spinoza1111 <spino...@yahoo.com>
> wrote:
>> #define TRUTH -1
>> #define FALSITY 0
>> #define NULLITY 0
> What's the point of defining TRUTH as -1, instead of accepting the
> language-defined truth value of 1, especially since the only thing
> you ever do with this value (based on an admittedly quick scan of your
> code) is assign it, under some conditions, to booFound, whose value
> is then tested by "if (booFound)"?
He's an idiot.
Specifically, he's picked it because, on some machines, it's all-bits-one,
thus "less like zero". However, this is overwhelmed by the much stronger
arguments in favor of 1:
* It's what boolean operators generate for truth.
* It's not a negative value -- which values are often used
to indicate failure, by contrast to meaningful yes/no values.
> Likewise, why obfuscate things by defining your own NULLITY macro
> instead of using the standard-defined NULL?
He's an idiot.
So far as we can tell, he's become convinced of two things:
1. He's really good at programming, and will show us all how C should be
used.
2. Everything C does is wrong.
Therefore, he goes out of his way to avoid using C in a way consistent with
the language's design. Which is interesting, because even if a language's
design is utter pants, carefully violating that design is one of the few
things you can do that genuinely makes things worse.
> ...
>> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
> If TRUTH were defined in the expected way, this would be equivalent to
> (*ptrMaster == *ptrTarget)
> which would be much clearer to the reader.
Do you honestly think that someone who named variables "ptrIndex0" through
"ptrIndex3" is concerned with "clear to the reader"?
For that matter, note that he's missed the point anyway; he's already
relying on the standard boolean behavior. What he should do, of course,
is:
int truth_values_internal = { TRUTH, FALSITY, TRUTH };
int *truth_of = truth_values_internal[1];
Thus,
truth_of[TRUTH] == TRUTH
truth_of[FALSITY] == FALSITY
truth_of[1 == 1] == TRUTH
>> *ptrTarget
>> ?
>> (*ptrMaster
>> ?
>> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
>> :
>> FALSITY)
> appears to have been composed solely for its confusion factor, since as
> a boolean expression it's equivalent to
> (*ptrTarget && *ptrMaster && (*ptrMaster == *ptrTarget))
> or the even simpler
> (*ptrTarget && (*ptrTarget == *ptrMaster))
Oh, come on. It's not confusion factor. It's that when you first learn
about the ternary operator, it's SO COOL. Also, remember, he doesn't want
to rely on the standard boolean operators, because by definition, since
they're part of C, their designs are of course completely wrong. So he
doesn't rely on &&, because if you use &&, that's a pointless premature
optimization because the short-circuiting rule is a stupid optimization that
shows that the language designers were incompetent and the standard has been
driven by autistic twerps.
Read his psychotic-break rants about the meaning of the word "clear" sometime
before you suggest that he would try to write for clarity. In short, I don't
think it's on the table.
... I should point out, it's not that I in any way disagree with your
criticisms. It's just that, by phrasing them as though you expect him to
have a response which is even recognizably lucid, let alone coherent,
you're giving the impression that you're speaking to the wrong audience.
Write for the rest of the readers.
Ben Bacarisse
> On 20 Mar, 22:16, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>>
>> What's the point of defining TRUTH as -1, instead of accepting the
>> language-defined truth value of 1,
>>
> ~TRUTH == FALSITY;
!FALSITY != TRUTH and !!TRUTH != TRUTH. There is no reason to favour
the action of ~ over that of !. In fact there are good reasons *not*
to favour it. For example, your claim (~TRUTH == FALSITY) is not the
case in two out of the three valid number representations that C
permits.
> also, if booleans are one bit, a set bit is -1 in two's complement
> notation.
There is no reason to assume that one bit Booleans are signed rather than
unsigned. "If they are 1 bit, a set bit is 1 in binary" is just a
valid a supporting statement.
> As an added bonus you get an error if you try to get the root of
> TRUTH, unless you accept that the answer is complex.
And you find that TRUTH is less the FALSITY when it should be so much
more.
Any number of cute facts can be used to try to support one or other
side but the non-cute, boring fact that C's logical operators produce
0 and 1 trumps them all. Doing anything else is likely to come over
as an affectation at best and at worst will lead to confusion.
--
Ben.
Ike Naar
Seebs <usenet...@seebs.net> wrote:
>For that matter, note that he's missed the point anyway; he's already
>relying on the standard boolean behavior. What he should do, of course,
>is:
>
> int truth_values_internal = { TRUTH, FALSITY, TRUTH };
> int *truth_of = truth_values_internal[1];
That is not valid C; do you mean:
int truth_values_internal[] = { TRUTH, FALSITY, TRUTH };
int *truth_of = &truth_values_internal[1];
Johannes Baagoe
> And you find that TRUTH is less the FALSITY when it should be so much
> more.
I beg to differ. FALSITY => TRUTH, /ex falso sequitur quodlibet/.
Besides, I really like the root of TRUTH being complex.
--
Johannes
Seebs
Uh, yeah. That.
Actually, I think I meant "truth_values_internal + 1", but in any event,
you get what I mean.
In my defense, I may have spent a *tiny* bit less than two full hours thinking
about that.
Rob Kendrick
Seebs <usenet...@seebs.net> wrote:
> In my defense, I may have spent a *tiny* bit less than two full hours
> thinking about that.
That, and I don't know of any news readers with built-in C syntax
checkers. And it's not as if anybody writes valid C perfectly first
time all the time.
(Time to go off and patch Claws, I think...)
B.
Seebs
> That, and I don't know of any news readers with built-in C syntax
> checkers. And it's not as if anybody writes valid C perfectly first
> time all the time.
I'm particularly prone to trivial and obvious mistakes, while I tend
to get other stuff right more easily. This is apparently stereotypical
for severe ADHD. As a result, I'm quite likely to, say, have fencepost
errors in string processing, or try to compile something only to discover
that I changed the name for a variable halfway through an implementation.
On the other hand, I added thread safety to pseudo, using a part of the
POSIX thread API I'd probably seen maybe once before, and (once I got past
the obvious and trivial errors) the actual thread safety design worked
flawlessly on the first try.
The hard part is easy; the easy part is hard. This pattern has been with me
all my life.
spinoza1111
I'm afraid you don't know what you're talking about, and you seem to
have little experience in actual debugging outside of the corporate
environment, one in which people are simultaneously pressured and
mollycoddled so as to get Seebach's eternal sunshine of the spotless
mind, where he, after what he claims to is several years of
experience, gets && out of order in a common pattern. I already fixed
the other bug as noted above, and make no claim that the code is bug
free. In fact, I shall be making an informal correctness proof in
order to make that claim in the future, and above I mention this fact,
along with my plan to test more comprehensively.
You're an idiot, Bacarisse. To relax on a 30 minute ferry ride, I get
my notebook out and spend a little time documenting and then writing
code that even with bugs is better than any of the crap posted here.
You find a typo but now that you've been infantilized and deskilled
from last year, probably from a combination of this ng and some silly
job, you don't suggest a fix like the pros here, nor alternatives. The
bug was fixed, along with my own off by one, which resulted not from
the incompetence of a Seebach but from an excess of diligence.
This is what collective programming is all about. Finding and fixing
bugs without this adolescent behavior which results from your
emotional and sexual anxieties; most programmers fail and any number
of actual living tasks (Seebach being exhibit A) and for them, making
a mistake in programming is the last straw, something they fear and a
fault, therefore, they transfer to scapegoats like Schildt.
>
> <snip>
> --
> Ben.
spinoza1111
> On 2010-03-20, pete <pfil...@mindspring.com> wrote:
>
> >spinoza1111wrote:
> >> The only reason I didn't use pre-existing str functions is I refuse to
> >> use string.h.
> > You can write all of these portably in C,
> > using only <stddef.h> for size_t
>
> You can.
>
> However, the statement by Nilges above highlights a particular kind of
> madness.
>
> Why doesn't he use string.h? From the rest of what he's written, I'd guess
> that it's because he thinks null-terminated strings are error-prone and
> poorly designed.
Duh yeah.
>
> So. Avoiding null-terminated strings? A plausible solution.
>
> Writing your own code to manipulate them, demonstrating repeatedly that,
> at least for you, the design is indeed highly error-prone, and simply beyond
> your abilities to debug in a reasonable amount of time? Stupid.
Amazing. You act as if I work for you since the corporate mindset has
so "colonized your lifeworld" as in Habermas you have no other mental
model beyond that. Dear Peter, I do not work for you and would never
hire you.
You are unable to hold down any other job besides the mollycoddled
paraprogrammer who's been snugly fit into a corporate role where he
can do the least amount of damage, and in that role, you have chosen
not to grow up, and start addressing your serious personal issues. You
can't clean houses on a corporate schedule, you'd fail as a
telemarketer, and you cannot teach I'd wot. You're a loser, and you
know it, on artificial life support in a matrix (the American
corporation which has been bought by Intel) prone to fail.
For despite the mythos of the lower middle class, that "programming is
a secure job", corporations design programming jobs very, very
carefully to ensure that at any time, should Wall Street so desire,
entire chunks/modules/assemblies of programmers and similar drones can
be unplugged neatly even as the astronaut unplugs "memory modules"
from Hal to have Hal only gracefully degrade.
This is in fact why you lack the skill to see (in the case of your
absurd %s tool) that starting with strchr and not strstr was an error.
Corporations (in my direct experience: also cf. Kraft 1878,
Programmers and Managers) people with end to end skills who, when
designing a filter for %s would see that %s is a string, and not two
characters, are precisely the kind of people who, especially if women,
were hounded out of the field (or left in disgust) in 1980s, once the
class war of the rich on the middle class got under way.
This is why you lack the skill to create code that, if buggy,
converges on nonbuggy. Your ridiculous filter for %s is precisely the
kind of code that diverges from nonbuggy because it starts off on the
wrong foot. And because you've never seen code whose developers have
been given enough time to converge on nonbuggy and documented by the
literate programmers themselves, you mistake the bug rate in 1.0 for a
linear function.
>
> If you have to use null-terminated strings, the sane thing to do would
> be to use the *already debugged* standard tools, reducing your exposure
> to the sorts of errors that crop up when you start messing with strings
> directly.
Well, dear Peter, far be it from you to put yourself in any situation
of risk where the fact that you've become a nonprogramming and
overpaid programmer through script kiddiedom, backstabbing, and
posting attacks on people like Schildt is something you seek to hide
at all costs.
Bacarisse, who used to be a good programmer but has been corrupted by
the ethos of this newsgroup, found a bug: I assigned zero to ptrHandle
and did not compare it to zero as was planned, which meant that
release 1.0 would never find overlap strings. I fixed the bug (which
results from a bug in the design in C: as I've said, there are
different types of bugs including your far less competent genre) and
also found that I was incorrectly incrementing the char handle. At
that point, the code resumed giving correct results for a test suite
which is smaller than my test suite for replace() but useful for
others here, but I did not claim the code is correct, since this is
collective debugging which is meant to allow others to participate and
hone their skills.
[You don't come here to participate and hone your skills though God
knows they could use a good honing. You come here to claim that
although you can't write a strlen bug free you are nonetheless a Great
Programmer, which you really aren't. You are here as a paid (indeed,
overpaid) employee of Wind River Systems to have unpaid slaves debug
your incompetent code.]
As I've said, the next step for me is twofold: to make the test suite
more exacting, and to post an informal correctness proof in English of
the sort used in extreme pair programming and structured walkthroughs
after people like you have been asked to leave.
>
> -s
> --
spinoza1111
> On 2010-03-20, pete <pfil...@mindspring.com> wrote:
>
> > I only write like that as a programming exercise.
>
> Yup.
>
> > There is no end of places in C programming to make mistakes in.
> > In my opinion, the main usefulness of this newsgroup,
> > is to learn how to write so as to avoid making mistakes in C.
>
> That can be a very good idea.
>
> > After a while, I don't think that you will continue to wonder
> > about why Nilges does what he does.
>
> I probably will until either I can confirm the specific insanity or
> come up with a rational explanation. Nilges does not write like someone
> who thinks he is trying to learn to avoid mistakes; he writes like
> someone who is trying to prove that everyone else is wrong about how
> to do things.
No, not everyone else, merely people like you, who in my experience
are strikingly common. As common as dirt.
It is to me an amusing paradox that I'm the best C programmer in this
newsgroup while not really knowing dick about C.
>
> -s
> --
spinoza1111
> On Fri, 19 Mar 2010 06:34:06 -0400,spinoza1111<spinoza1...@yahoo.com>
On Mar 21, 6:16 am, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
> On Fri, 19 Mar 2010 06:34:06 -0400,spinoza1111<spinoza1...@yahoo.com>
> wrote:
>
> > #define TRUTH -1
> > #define FALSITY 0
> > #define NULLITY 0
>
> What's the point of defining TRUTH as -1, instead of accepting the
> language-defined truth value of 1, especially since the only thing
> you ever do with this value (based on an admittedly quick scan of your
> code) is assign it, under some conditions, to booFound, whose value
> is then tested by "if (booFound)"?
Well, if you must know, I have three reasons.
One is a desire to offend pompous idiots who've confused their
knowledge of C with knowledge of computer science, and who actually
believe that coding in shibboleth style exhibits great genius.
The other is that today I teach English (and history, law, and
politics at uni level), and true is an adjective whereas the use of
the preprocessor symbol is as a NOUN.
The third is the fable of the sheep, who demanded to be hanged as
sheep and not as a lamb. There's really no point in coding for
localized and shibboleth understandability for people who don't
understand English over a small lower bound of complexity, and who,
like dear Peter Seebach, claim to have ADHD when asked to pay
attention to something that doesn't fit their mental patterns, mental
patterns outside of which they cannot think because they were
mollycoddled in school.
> Likewise, why obfuscate things by defining your own NULLITY macro
> instead of using the standard-defined NULL?
>
> ...> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
Good point: that particular subexpression was what was left over as
the container expression was modified and of course, it can be
simplified (it might be by an optimizing compiler, but we cannot count
on that). It will be fixed in the next release and you shall be
credited.
>
> If TRUTH were defined in the expected way, this would be equivalent to
> (*ptrMaster == *ptrTarget)
> which would be much clearer to the reader.
The larger expression,
>
> > *ptrTarget
> > ?
> > (*ptrMaster
> > ?
> > (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
> > :
> > FALSITY)
>
> appears to have been composed solely for its confusion factor, since as
> a boolean expression it's equivalent to
> (*ptrTarget && *ptrMaster && (*ptrMaster == *ptrTarget))
This is to me at this time the most sensible simplification. OK, let's
try it out.
No it doesn't work. That is because you got the original statement
wrong:
*ptrTarget
?
(*ptrMaster ?
*ptrMaster==*ptrTarget
:
FALSITY)
:
(booFound = TRUTH, FALSITY)
You omitted the part where I need to assign booFound, and that need is
why the expression was designed as above. You omitted the second colon
subexpression.
You see, the above was composed not for shibboleth readability but
based on the actual need in the code to avoid evaluating the wrong
things. Your basic question is whether you're out of target.
If you have come to the end of the target, it seems unavoidable that
you must indicate that ONLY IN THIS SITUATION do you have booFound. In
other words, we never have a found unless we get to end of target.
If you have not then the question is whether you have come to the end
of the master string. If you have not then, and only then, it is safe
to compare the chars in the master and target, breaking out of the
loop if they fail to match and continuing if not.
But if you have come to the end of the master string, then it's Miller
time.
Nope, my code is best, and the reason is that it follows the logic of
the problem as expressed in an outline or complex sentence. The reason
it is not popular is that younger programmers, as products of a racist
educational system declining in quality at both the high and low ends,
no longer have to make outlines in English class, and half-educated
teachers, who can neither write nor parse English above a low lower
bound, actively discourage higher level sentence construction in their
students lest they have to grade papers the teachers themselves do not
understand.
In a talk at the defunct Data Processing Management Association in
1976, I pointed out that "understandability of code" is a function of
education, therefore, no set of stylistic standards or shibboleths can
create truly understandable code. For this reason, I write for
understandability not as a denizen of a real world (which contains
people like Seebach whom I cannot stand and who won't read my code
because iddums has ADHD) but as what Kant called the citizen of a
better world, in which people think in outlines and use and understand
complex sentences.
> or the even simpler
> (*ptrTarget && (*ptrTarget == *ptrMaster))
> --
> Morris Keesan -- mkee...@post.harvard.edu
Wow, a Harvard alumni, faculty or student. I'm honored. But you're
wrong about the second change unless I don't know what the hell I'm
talking about, which is possible at all times for all of us, for all
men are mortal, even Harvard men.
spinoza1111
wrote:
Also, Truth is all ones and no zeroes which looks terrific on a blue
screen of death.
spinoza1111
> On 2010-03-20, Morris Keesan <mkee...@post.harvard.edu> wrote:
>
> > On Fri, 19 Mar 2010 06:34:06 -0400,spinoza1111<spinoza1...@yahoo.com>
> > wrote:
> >> #define TRUTH -1
> >> #define FALSITY 0
> >> #define NULLITY 0
> > What's the point of defining TRUTH as -1, instead of accepting the
> > language-defined truth value of 1, especially since the only thing
> > you ever do with this value (based on an admittedly quick scan of your
> > code) is assign it, under some conditions, to booFound, whose value
> > is then tested by "if (booFound)"?
>
> He's an idiot.
Fuck you, asshole.
>
> Specifically, he's picked it because, on some machines, it's all-bits-one,
> thus "less like zero". However, this is overwhelmed by the much stronger
> arguments in favor of 1:
> * It's what boolean operators generate for truth.
> * It's not a negative value -- which values are often used
> to indicate failure, by contrast to meaningful yes/no values.
Well, in some situations, such as the trial of Socrates or Jesus or
here, Truth is failure whereas you seem to be a success by way of
lies: about Schildt, about your capabilities, about many things.
Perhaps Truth should be negative in order to show that in a world of
lies such as you propagate, it is on the side of the "losers".
>
> > Likewise, why obfuscate things by defining your own NULLITY macro
> > instead of using the standard-defined NULL?
>
> He's an idiot.
Fuck you, asshole.
>
> So far as we can tell, he's become convinced of two things:
>
> 1. He's really good at programming, and will show us all how C should be
> used.
Hey, you're getting warmer. Yes, dear heart, I am really, really,
really good at programming, and I shall show you how to use C even
though I don't really know dick about C. You see, deep knowledge of C
corrupts the soul.
> 2. Everything C does is wrong.
Not everything.
>
> Therefore, he goes out of his way to avoid using C in a way consistent with
> the language's design. Which is interesting, because even if a language's
> design is utter pants, carefully violating that design is one of the few
> things you can do that genuinely makes things worse.
That's false.
Barney Stroustrup buttfucked C
And hee hee hee
He created C plus plus
And gave it to the rest of us
C teaches adjustment to a reified administered world. I don't have to
adjust.
>
> > ...
> >> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
> > If TRUTH were defined in the expected way, this would be equivalent to
> > (*ptrMaster == *ptrTarget)
> > which would be much clearer to the reader.
>
> Do you honestly think that someone who named variables "ptrIndex0" through
> "ptrIndex3" is concerned with "clear to the reader"?
Yes. This is because indexes are used in a certain sequence and have
limited useful life inside the module that declares them, and, for
this reason, are often used for different purposes. Therefore it makes
the most sense, for indexes and only indexes are misleading if labeled
by the name of only one of their uses.
>
> For that matter, note that he's missed the point anyway; he's already
> relying on the standard boolean behavior. What he should do, of course,
> is:
>
> int truth_values_internal = { TRUTH, FALSITY, TRUTH };
> int *truth_of = truth_values_internal[1];
>
> Thus,
> truth_of[TRUTH] == TRUTH
> truth_of[FALSITY] == FALSITY
> truth_of[1 == 1] == TRUTH
>
> >> *ptrTarget
> >> ?
> >> (*ptrMaster
> >> ?
> >> (*ptrMaster==*ptrTarget ? TRUTH : FALSITY)
> >> :
> >> FALSITY)
> > appears to have been composed solely for its confusion factor, since as
> > a boolean expression it's equivalent to
> > (*ptrTarget && *ptrMaster && (*ptrMaster == *ptrTarget))
> > or the even simpler
> > (*ptrTarget && (*ptrTarget == *ptrMaster))
>
> Oh, come on. It's not confusion factor. It's that when you first learn
> about the ternary operator, it's SO COOL.
Yes, asshole. I learned about lazy evaluation in a UNIVERSITY
CLASSROOM and a class in Logic taught by a brilliant faculty member,
who later asked me to teach that same class. I took this class two
years before I had access to a computer. Had you been man enough to
take Logic as you should have if you wanted to be a programmer, and
had you used as is standard Copi's introduction to logic, and had you
done the work and paid attention instead of running home to Mommy with
ADHD, you would have learned how to make truth tables, and then
simplify them using lazy evaluation.
But you didn't. You were too busy playing computer games.
The fact is that great programmers think that important ideas are
cool, and only important ideas. They don't think that "sequence
points" are cool.
> Also, remember, he doesn't want
> to rely on the standard boolean operators, because by definition, since
> they're part of C, their designs are of course completely wrong. So he
That might be your logic. But I've been C-aware since the 1970s when
you were probably masturbating to the girl in Scooby Doo, and while it
was better than Cobol, it was not as good or Java, or Visual Basic.
> doesn't rely on &&, because if you use &&, that's a pointless premature
> optimization because the short-circuiting rule is a stupid optimization that
> shows that the language designers were incompetent and the standard has been
> driven by autistic twerps.
Got that shit right, asshole.
>
> Read his psychotic-break rants about the meaning of the word "clear" sometime
> before you suggest that he would try to write for clarity. In short, I don't
> think it's on the table.
Those "rants" were based in fact on the following sources:
(1) The definition of clarity in the Oxford English Dictionary,
compact edition
(2) The theory of knowledge
Peter's attack on Schildt called Schildt clear. But "clarity" is being
conducive to understanding, and understanding is justified belief in
that which is true. The fact is that most programmers, including
programmers who like Seebach claim they can write, are very, very poor
at language skills, and when they write rely upon urban legends and
shibboleths to get their point across. The fact is that since
corporate life depends on obscuring the real conditions of life from
corporate people, the only metric of "clarity" is a formal adherence
to grammar and orthography which has nothing to do with truth.
>
> ... I should point out, it's not that I in any way disagree with your
> criticisms. It's just that, by phrasing them as though you expect him to
> have a response which is even recognizably lucid, let alone coherent,
> you're giving the impression that you're speaking to the wrong audience.
> Write for the rest of the readers.
>
> -s
> --
spinoza1111
> On 2010-03-21, Ike Naar <i...@localhost.claranet.nl> wrote:
>
> > Seebs <usenet-nos...@seebs.net> wrote:
> >>For that matter, note that he's missed the point anyway; he's already
> >>relying on the standard boolean behavior. What he should do, of course,
> >>is:
> >> int truth_values_internal = { TRUTH, FALSITY, TRUTH };
> >> int *truth_of = truth_values_internal[1];
>
> Uh, yeah. That.
>
> Actually, I think I meant "truth_values_internal + 1", but in any event,
> you get what I mean.
>
...and you got it wrong, and ask for a charity you don't show Schildt
or anyone else.
"You stupid fucking cunt. You, Williamson, I'm talking to you,
shithead. You just cost me $6,000. Six thousand dollars, and one
Cadillac. That's right. What are you going to do about it? What are
you going to do about it, asshole? You're fucking shit. Where did you
learn your trade, you stupid fucking cunt, you idiot? Who ever told
you that you could work with men? Oh, I'm gonna have your job,
shithead."
- David Mamet, Glengarry Glen Ross
spinoza1111
> On 2010-03-21, Rob Kendrick <n...@rjek.com> wrote:
>
> > That, and I don't know of any news readers with built-in C syntax
> > checkers. And it's not as if anybody writes valid C perfectly first
> > time all the time.
>
> I'm particularly prone to trivial and obvious mistakes, while I tend
"You, Williamson, I'm talking to you, shithead."
> to get other stuff right more easily.
This is conveniently uncheckable.
As I investigate the large number of facts you have in some cases
inappropriately and to your employers' disadvantage revealed about
yourself I find that at the age of forty, Peter, you've not
accomplished a fraction of what I'd accomplished by the time I was
your age. You've basically, like most of us, been able to get and keep
jobs, but as I've said, programming jobs today are carefully designed
to make you a dime a dozen, since Wall Street needs companies like
your employers to be able to shed programmers quickly.
> This is apparently stereotypical
> for severe ADHD.
This is false. In fact, in ADHD, the sufferer is good at small, short
and definable tasks such as writing a strlen without errors.
Larry Ellison, currently the CEO of Oracle, had ADHD and received
neither a proper diagnosis nor treatment, nor even a name for his
disease in the classist and racist Chicago public school system of the
1960s. This was compounded by the collapse of his family owing to the
beginnings of the deindustrialization of Chicago and the betrayal of
its lower middle class.
Nonetheless, Ellison succeeded beyond his expectations in an infamous
Fortran class at the University of Illinois which many of my friends
took, BECAUSE he found that he could (like me) get the first problem,
which was making change in code for a ten dollar bill. In my class
which was designed like the U of I, I wrote the code in Northwestern's
library on a cold January night, and it had one bug, for I decided to
load the (IBM 1401 machine code in my case, not Fortran) on top of
where the professor had independently chosen to store his loader for
our code. After we fixed this my code ran perfectly.
Crazy men like me use sources, so my source for my facts about Larry
Ellison is
Softwar: An Intimate Portrait of Larry Ellison and Oracle by Matthew
Symonds and Larry Ellison.
In fact, people who write big programs end to end, removing the bugs
steadily albeit in some cases slowly depending on other duties, also
tend not to make silly mistakes (apart from typos based on poor
language design) in one line and small programs. Nor do they, after
making each such mistake, hasten to tell people (without being able to
give EXAMPLES) that they do big, wonderful things offstage or out
back; if they do so consistently, sensible men, even crazy homeless
men with the sense of King Lear or Tom o' Bedlam, tend to laugh at
them.
Really great programmers are also unafraid of revisiting simple
programs to find unexpected depths for the same reason great
mathematicians like integer number theory and, in some cases, such as
John Horton Conway, recreational math.
I conclude that you're incompetent in the large and in the small,
Peter, and that you've learned to claim ADHD (which claim is a call
for a charity you do not extend others when you call them "morons",
asshole), and today, you come here to get your awful code in "pseudo"
repaired by unwitting slaves.
> As a result, I'm quite likely to, say, have fencepost
> errors in string processing, or try to compile something only to discover
> that I changed the name for a variable halfway through an implementation.
> On the other hand, I added thread safety to pseudo, using a part of the
> POSIX thread API I'd probably seen maybe once before, and (once I got past
> the obvious and trivial errors) the actual thread safety design worked
> flawlessly on the first try.
And so Peter, a vain and foolish man, raises the cry,
But my important code works flawlessly on the first try.
He's too much the Fool to see he's deceived:
For a good Programmer, when such a gift, he's received
Will not slaughter a bullock, nor quaff of the grape
But get to work in order his own Vanity to Rape:
Yea, he shall desire if good and if competent
The clothes of his Goddess, his pride, to remove in an instant
By designing more tests to show that he's wrong
So that real satisfaction will last and be long.
I'm willing to wager that we will never see these versions of Peter
that work, after he's stolen the work of people like Ersek Laszlo in
pointing out Peter's failure to get a test for an index's usability.
Despite his claim that his employer (client?) Wind River Systems will
let him release the code for free, we'll get the versions with the
bugs left in in return for versions with Laszlo's unpaid slave labor,
which Wind River will make proprietary.
I have long noticed that this is how Open Source works. Content is
stolen from people in many cases in an environment of bullying, as in
Wikipedia. Jaron Lanier, in "You Are Not a Gadget" calls this "digital
Maoism".
"Fuck you, Dave. You know you got a big mouth. You make a close, this
whole place stinks with your farts for a week - how much you just
ingested. Oh, what a big man you are! 'Hey, let me buy you a pack of
gum. I'll show you how to chew it.' Whoof! Your pal closes, and all
that comes out of your mouth is bile. Ooh, how fucked-up you are! "
- David Mamet, Glengarry Glen Ross
>
> The hard part is easy; the easy part is hard. This pattern has been with me
> all my life.
Oh, fuck off.
>
> -s
> --
spinoza1111
>
> > That, and I don't know of any news readers with built-in C syntax
> > checkers. And it's not as if anybody writes valid C perfectly first
> > time all the time.
>
> I'm particularly prone to trivial and obvious mistakes, while I tend
> to get other stuff right more easily. This is apparently stereotypical
> for severe ADHD. As a result, I'm quite likely to, say, have fencepost
> errors in string processing, or try to compile something only to discover
> that I changed the name for a variable halfway through an implementation.
> On the other hand, I added thread safety to pseudo, using a part of the
> POSIX thread API I'd probably seen maybe once before, and (once I got past
> the obvious and trivial errors) the actual thread safety design worked
> flawlessly on the first try.
>
> The hard part is easy; the easy part is hard. This pattern has been with me
> all my life.
>
> -s
> --
The following code, from Peter's "pseudo root simulator", is submitted
to this discussion group as evidence that he is incompetent, and is
unethically using this newsgroup to get debugging assistance for code
that he will then claim as his own. And because he is incompetent, he
has defamed Herb Schildt and myself in a legally actionable sense.
If I am wrong I will apologize for basing this charge on this evidence
but will not withdraw the charge, since other evidence exists. I am
the best programmer in this newsgroup, but by no means the best C
programmer, so I may have missed something.
Sources: the thread starts at http://groups.google.com.hk/group/comp.lang.c/msg/54dfb34c84373f26?hl=en
("A hunk of not-very-portable code I've written"). This post
references code in github at http://github.com/wrpseudo/pseudo/blob/master/pseudo.c
line 664 at this moment in time.
int
pseudo_server_response(pseudo_msg_t *msg, const char *tag) {
switch (msg->type) {
case PSEUDO_MSG_PING:
msg->result = RESULT_SUCCEED;
if (opt_l)
pdb_log_msg(SEVERITY_INFO, msg, tag, "ping");
return 0;
break;
case PSEUDO_MSG_OP:
return pseudo_op(msg, tag);
break;
case PSEUDO_MSG_ACK:
case PSEUDO_MSG_NAK:
default:
pdb_log_msg(SEVERITY_WARN, msg, tag, "invalid message");
return 1;
}
}
OK. My understanding of C is that for ACK and NAK, the code will fall
through to "invalid message", and this is not intended. Good style
alone demands a break after the ack and nak cases. The same sort of
error is repeated above the code at github above this code, therefore
this isn't "ADHD". It is, as far as I can see, incompetence which
taken together to an out of order and in the same code, means that
Seebach has not mastered the C programming language as of this year,
and did not know C when he published "C: The Complete Reference", his
defamatory attack on Herb Schildt.
I am making very serious charges involving legal liability to Peter or
myself, and possibly involving Wind River Systems, so due diligence is
essential.
First as to authorship: this is from Peter's readme for the pseudo
root simulator:
"My various coworkers, both engineering and management, made this
possible.
While I did most of the actual typing, this code has benefitted
greatly
from detailed code reviews, excellent reproducers for bugs, and the
consistent support of the whole group for the project. It's been a
great
deal of fun, and I'm pretty happy that we're finally ready to make it
available for other people to look at."
The claim that there were "detailed code reviews" appears to be a lie.
This use of case is a common bug but one that never is concealed in
testing and one that is typically found in code reviews. Furthermore,
Seebach's online conduct here in this ng demonstrates that in a code
review, he is probably disruptive and cannot function.
I believe that Peter, hopefully without authorization from Wind River
Systems, who is either a client or former employer or something else
in relation to him (the relation is not clear) is submitting
unacceptable code to this newsgroup for review by competent people in
a relationship of slave labor. As in the case of wikipedia editors,
who are like him masquerading as competent, he knows enough to
recognize competent people who can write such as myself, and he fears
these people because they may expose his scam. This is the reason for
his vicious attacks on me.
My "due diligence" was to reread the 2005 C99 standard PDF, since good
programmers, unlike Seebach, always put breaks in null cases so that
they can forget in part just how poorly the switch statement was
designed by Ritchie, or Pike, or Kernighan, or Kermit the Frog. This
means we're not always "up to speed" on the actual rules of C, which
are in some part, mistakes masquerading as rules.
The standard has an example of a fallthrough, but it may be that
Seebach believes that the logic doesn't fall through if there is no
code in the case. So, I tested this using Microsoft C++ .Net in C
mode:
switch(1)
{
case 1:
case 2:
default: printf("foo\n");
};
The above code printed foo.
Dr Malcolm McLean
> "Dr Malcolm McLean" <malcolm.mcle...@btinternet.com> ha scritto nel
>
>
> if(str==0||sub==0||*sub==0)
>
Apparently the canonical strstr returns a pointer to the search string
if passed an empty sub, so you don't need the last part of this test.
Moi
> On 2010-03-21, Rob Kendrick <nn...@rjek.com> wrote:
>> That, and I don't know of any news readers with built-in C syntax
>> checkers. And it's not as if anybody writes valid C perfectly first
>> time all the time.
>
> I'm particularly prone to trivial and obvious mistakes, while I tend to
> get other stuff right more easily. This is apparently stereotypical for
> severe ADHD. As a result, I'm quite likely to, say, have fencepost
> errors in string processing, or try to compile something only to
I think most of us do, actually.
First, you get the basics right (the "skeleton" of the algorithm/program)
, then you polish the corner cases and tackle the fencepost errors.
See for example Knuth's "never getting binary search right the first time"
musing.
> discover that I changed the name for a variable halfway through an
> implementation. On the other hand, I added thread safety to pseudo,
> using a part of the POSIX thread API I'd probably seen maybe once
> before, and (once I got past the obvious and trivial errors) the actual
> thread safety design worked flawlessly on the first try.
>
> The hard part is easy; the easy part is hard. This pattern has been
> with me all my life.
Focussing on the hard part at first and leaving the trivialities
for the future is a good strategy, IMHO. Trivial things will show up.
For a two-loop problem (like strstr()) there are four possible corner-cases.
You could even enumerate them!
AvK
Willem
) I think most of us do, actually.
) First, you get the basics right (the "skeleton" of the algorithm/program)
) , then you polish the corner cases and tackle the fencepost errors.
) See for example Knuth's "never getting binary search right the first time"
) musing.
Some of the time I even don't bother figuring out which way a corner case
should fall; I just code it up one way, run a test against the corner case,
and then if it fails, I just flip the case. Easy-peasy.
Same with 'should this be greater than or smaller than ?' questions.
Run a test, if the order seems reversed, flip the comparison.
Of course, you have to know when to do this and when not (cue the story
about the idiot^Wprogrammer who, after a 99% test success, saw a test
failure report, where a complex expression did the opposite of what was
expected, and put a 'not' at the base of said expression, resulting in
that one test being passed.)
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
spinoza1111
> "Dr Malcolm McLean" <malcolm.mcle...@btinternet.com> ha scritto nel messaggionews:bd8bd2e1-e695-44f3...@g10g2000yqh.googlegroups.com...
>
>
>
>
>
> > On 19 Mar, 17:27, Seebs <usenet-nos...@seebs.net> wrote:
>
> >> You're arguing with someone who is not a first-year CS student and
> >> claims to have needed TWO HOURS to implement strstr.
>
> >> Is there any genuine point in pointing out errors?
>
> > A quick and nasty strstr should only take a minute or so to write.
>
> > /*
> > quick and nasty strstr. Untested. Posted to comp.lang.c "as is"
> > without warrantry or guarantee of any kind, including implied
> > warrantry of merchanability or fitness for any particular purpose.
> > */
> > char *mystrstr(char *str, char *sub)
> > {
> > size_t i; /* If you think this is ugly, join the campaign for 64-bit
> > ints */
> > while(*str)
> > {
> > for(i=0;str[i]==sub[i] && str[i];i++);
> > if(!sub[i])
> > return str;
> > str++;
> > }
> > return 0;
> > }
>
> char* mystrstrr(char *str, char *sub)
> {size_t i;
>
> if(str==0||sub==0)
> return 0;
> while(*str)
> {for(i=0; str[i]==sub[i] && str[i]!=0; ++i);
> if(sub[i]==0)
> return str;
> str++;
> }
> return 0;
>
> }
>
> char* mystrstrr(char *str, char *sub)
> { char *p, *r;
>
> if(str==0||sub==0||*sub==0)
> return 0;
> a: p=str; r=sub; goto c;
> b: ++p, ++r;
> c: if(*r==0) return str;
> if(*p==*r) goto b;
> ++str;
> if(*str) goto a;
> return 0;}
>
> the only bug is when str==""
> but this below seems pass all tests
>
> #include <stdio.h>
> #define R return
> #define G goto
> #define uns unsigned
>
> #define TRUTH -1
> #define FALSITY 0
> #define NULLITY 0
>
> { char *p, *r, *v;
>
> v=str;
> if(sub==0||*sub==0||v==0||*v==0)
> R 0;
> a: p=v; r=sub;G c;
> b: ++p, ++r;
> c: if(*r== 0) R v;
> if(*p==*r) G b;
> ++v;
> d: if(*v) G a;
> R 0;
>
> }
>
> char* strstrrWithIndex(char* a, char* b, uns* i)
> {char *r;
> if(i==0) R 0;
> r=strstrr(a,b);
> if(r==0) {*i=-1; R 0;}
> else {*i=r-a; R r;}
>
> }
>
> int main(void)
> {
> char *ptrIndex1 = NULLITY;
> uns intIndex1 = 0;
> printf("strstr Simplified\n\n");
> printf("Expect 0: %d\n", strstrr("", ""));
> printf("Expect 0: %d\n", strstrr("0123456789", ""));
> printf("Expect 0: %d\n", strstrr("", "0"));
> printf("Expect 0: %d\n", strstrr("Here", "There"));
> ptrIndex1 = strstrrWithIndex("There", "here", &intIndex1);
> printf("Expect 1: %d\n", intIndex1);
> ptrIndex1 = strstrrWithIndex("They seek him here",
> "here",
> &intIndex1);
> printf("Expect 14: %d\n", intIndex1);
> ptrIndex1 = strstrrWithIndex("They seek him there",
> "here",
> &intIndex1);
> printf("Expect 15: %d\n", intIndex1);
> ptrIndex1 = strstrrWithIndex
> ("The clc regs seek him everywhere",
> "here",
> &intIndex1);
> printf("Expect 28: %d\n", intIndex1);
> printf("Expect 'h': %c\n", *ptrIndex1);
> ptrIndex1 = strstrrWithIndex
> ("Is he in Heaven? Or in Hell?",
> "?",
> &intIndex1);
> printf("Expect 15: %d\n", intIndex1);
> printf("Expect '?': %c\n", *ptrIndex1);
> ptrIndex1 = strstrrWithIndex
> ("That damn'd elusive Spinoza won't tell!",
> "Spinoza",
> &intIndex1);
> printf("Expect 20: %d\n", intIndex1);
> printf("Expect 'p': %c\n", *(ptrIndex1+1));
> printf("Expect '0': %c\n", *strstrr("0123456789", "0"));
> printf("Expect '1': %c\n", *strstrr("0123456789", "1"));
> printf("Expect '0': %c\n", *strstrr("0123456789", "0"));
> printf("Expect '9': %c\n", *strstrr("0123456789", "9"));
> printf("Expect '5': %c\n", *strstrr("0123456789", "345") + 2);
> printf("Expect '8': %c\n", *strstrr("0123456789", "89"));
> ptrIndex1 = strstrrWithIndex("0123456789A89AB",
> "89AB",
> &intIndex1);
> printf("Expect 11: %d\n", intIndex1);
> return 0;
>
>
>
> }
> > However it's a bit cryptic, particularly the for loop.
> > Whilst there's always the argument that as long as the interfaces are
> > nice, the code doesn't matter, I'd like to see a rather better job.
> > Then it will return a match to the first character if sub is the
> > empty string. I don't know offhand whether this is allowed. I'd have
> > to check the standard for a real implementation intended to be shipped
> > to someone else.
> > Two hours isn't unreasonable for a production-quality strstr.
Do me the courtesy of a comment acknowledging your reuse of my test
suite if you found it useful.
spinoza1111
> On Sun, 21 Mar 2010 01:35:15 +0000, Seebs wrote:
> >> That, and I don't know of any news readers with built-in C syntax
> >> checkers. And it's not as if anybody writes valid C perfectly first
> >> time all the time.
>
> > I'm particularly prone to trivial and obvious mistakes, while I tend to
> > get other stuff right more easily. This is apparently stereotypical for
> > severe ADHD. As a result, I'm quite likely to, say, have fencepost
> > errors in string processing, or try to compile something only to
>
> I think most of us do, actually.
> First, you get the basics right (the "skeleton" of the algorithm/program)
> , then you polish the corner cases and tackle the fencepost errors.
> See for example Knuth's "never getting binary search right the first time"
> musing.
The problem is that Seebach and Heathfield only apply this to
themselves and never to others, especially to people that anger them
by diverging from their pet prejudices or simply, in my case, being so
obviously more qualified and less corrupted by family and corporate
mollycoddling.
>
> > discover that I changed the name for a variable halfway through an
> > implementation. On the other hand, I added thread safety to pseudo,
> > using a part of the POSIX thread API I'd probably seen maybe once
> > before, and (once I got past the obvious and trivial errors) the actual
> > thread safety design worked flawlessly on the first try.
>
> > The hard part is easy; the easy part is hard. This pattern has been
> > with me all my life.
>
> Focussing on the hard part at first and leaving the trivialities
> for the future is a good strategy, IMHO. Trivial things will show up.
> For a two-loop problem (like strstr()) there are four possible corner-cases.
> You could even enumerate them!
This discussion is absurd. In his pseudo chroot, Peter worked on the
code for two months, yet it has case labels with no breaks and out of
order logical Ands. I believe he's here to get fixes to his
incompetent code for free so as to claim he's written something.
>
> AvK
io_x
>"Dr Malcolm McLean" <malcolm...@btinternet.com> ha scritto nel messaggio
>news:b0d9199c-f2f3->4322-b7fd-4...@q21g2000yqm.googlegroups.com...
but the search string is pointed from "sub"
so it point to "" [in the above case]
if *sub==0 than it mean search in the string pointed from "str" nothing
so one error
what about:
section _DATA use32 public class=DATA
global strstrr
section _TEXT use32 public class=CODE
; i8* __stdcall strstrr(i8 *str, i8 *what)
; 0i,4b,8ra, 12P_str, 16P_what
strstrr:
push ebx
push esi
mov esi, dword[esp+ 12]
mov edx, dword[esp+ 16]
xor ebx, ebx
xor eax, eax
cmp esi, 0
je .e
cmp edx, 0
je .e
mov bl, [edx]
cmp ebx, 0
jne .1
.e: stc
jmp short .z
.0: inc esi
.1: mov al, byte[esi]
cmp eax, 0
je .e
cmp eax, ebx
jne .0
mov ecx, esi
.2: inc edx
inc ecx
mov al, [edx]
cmp eax, 0
je .9
cmp al, [ecx]
je .2
mov edx, dword[esp+ 16]
jmp short .0
.9: mov eax, esi
clc
.z:
pop esi
pop ebx
ret 8
Richard Bos
> spinoza1111 <spino...@yahoo.com> writes:
> I don't expect you to change your style -- you've evolved it to
> provoke a response here
And once again, he's succeeded. Well done for falling for it, jerk.
Richard
spinoza1111
> ("A hunk of not-very-portable code I've written"). This post
In this particular case, it is possible that Seebach never got around
to deciding and coding what ack and nak should do. A nak sounds like
an error in which you should wait until a maximum. But I do not
understand how an ack could be an error. "hey, I'm here! Fuck you,
you're an error! Mom!"
I am waiting for him to lie about this situation.
Furthermore, there is a command processor switch statement directly
above the code I'm discussing: it seems to want to process pseudo root
commands. Many commands seem "stubbed", yet strangely, not with a
break to get out of the switch statement. As a result, a mkdir will do
a mknod.
[Parenthetically, one wonders what a pseudo root is for. OK, you want
to make directories and stuff without bothering Linux or being in
protected mode? Or maybe you are a programmer only in virtual reality
and you like simulating what the big boys do? Hell, I love writing
simulators myself. But isn't Linux really, really good at making
directories in reality? Are we reinventing the wheel? Don't get me
wrong, I might be The Greatest Programmer in the World but I know dick
about Linux.]
The code, which is too large to include, starts at line 456 at
http://github.com/wrpseudo/pseudo/blob/master/pseudo.c.
I do not understand why the operations he has supported at this time
have a break but the unsupported operations do not. The apparent error
is consistent, and Peter has told us that he gets trivial matters
wrong.
However, programming isn't high level conceptual handwaving. When I
wrote the compiler for "Build Your Own .Net Language and Compiler" I
wrote all 26K lines by myself. Real programmers don't like
collaboration save for pair programming.
I believe that if I'd submitted this code, Peter would have been on me
like a fly on shit, claiming that I am both incompetent and insane,
once others noticed the error. I believe he's no better than somebody
coming here for homework completion, and possibly worse.
Here's another troubling error, in the function containing the
troubling case statements. A "pseudo_msg_t" named db_header is
declared with no initialization, and then assigned using this code:
if (found_ino && (prefer_ino || !found_path)) {
db_header = by_ino;
} else if (found_path) {
db_header = by_path;
}
Hmm...if you have found an ino and you prefer it, or if no path was
found, then you set db_header to by_ino. Otherwise if you have a path
you use that.
[Oh shit, I hope I know how else and if and stuff work. Yup I think
that the above if has sprung a leak.]
OK, perhaps this is an error which "can't happen". However, competent
programmers handle many (but not all) things which can't happen. I
worry in strstr about a null target. I don't worry AT THIS TIME (after
two hours work) about a target or a master that is NULL.
But...Peter says this code has been worked on by him for two months.
It is to me unwise to not put in error checking early so as to "eat
your own dog food" when errors occur.
Nope, I think the code is globally incompetent and was brought here to
be beat into shape by slaves for whom Peter, and Wind River Systems,
have naught but contempt, as indicated by his treatment of dissident,
uppity slaves like me.
Is this what Open Source has come to?
I would have given db_header an initial null value. OK, is this
attention disorder in action, which conceals A Heartbreaking Work of
Staggering Genius? Is this the first pseudo root thingie ever written
for linux, and did many a man try and fail to solve this problem?
Oh, here is a switch statement at line 88. It uses GNU getopt with a
smartass remark to the effect that GNU did it wrong; Peter, at an
early age, seems to have regarded himself as a Superior and Gifted
person who Just Knew that you study calculus before trig, and that you
don't have to take computer science to be a Genius Programmer. Perhaps
big hairy guys that rode motorcycles and looked like Schildt made fun
of him and give him noogies and swirlies.
OK, all cases have a break and all do something. Cool.
Oh crumbs, no default handler, with an error message, perhaps snarkily
blaming the error on GNU.
Two months work? Wow.
spinoza1111
> Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > I don't expect you to change your style -- you've evolved it to
> > provoke a response here
>
> And once again, he's succeeded. Well done for falling for it, jerk.
Excuse me. I am not here to provoke anyone. Nor am I here, as I
suspect Peter Seebach is, to get really bad code (Peter's pseudo root
simulator) fixed by unwitting slaves.
I just thought it would be fun to plan, pre-document and write strstr
without using string.h. I did so, composing a test suite which at this
writing is being used by others who don't care that they are stealing
intellectual production while not supporting a fellow human being
subject to absurd and unconscionable treatment. I again sparked an
interesting, on topic and useful thread in the best tradition of clc.
But unlike a corporate dweeb who sucks up to the money and shits on
people when he thinks he can get away with it, I am not afraid of a
fight. So don't fuck with me.
>
> Richard
Richard Harter
<ro...@invalid.address.org> wrote:
>On Sun, 21 Mar 2010 01:35:15 +0000, Seebs wrote:
>
>> On 2010-03-21, Rob Kendrick <nn...@rjek.com> wrote:
>>> That, and I don't know of any news readers with built-in C syntax
>>> checkers. And it's not as if anybody writes valid C perfectly first
>>> time all the time.
>>
>> I'm particularly prone to trivial and obvious mistakes, while I tend to
>> get other stuff right more easily. This is apparently stereotypical for
>> severe ADHD. As a result, I'm quite likely to, say, have fencepost
>> errors in string processing, or try to compile something only to
>
>I think most of us do, actually.
>First, you get the basics right (the "skeleton" of the algorithm/program)
>, then you polish the corner cases and tackle the fencepost errors.
>See for example Knuth's "never getting binary search right the first time"
>musing.
If I may disagree a bit, in my experience it is often better to
get the invariants, the pre-conditions, and the post-conditions
worked out before proceeding to the actual code. Yes, you want
to get the idea of an algorithm first, but don't code immediately
from the idea. I admit that this is a counsel of perfection, and
that all too often I violate my own strictures. However when I
do I sometimes pay the price.
The problem with dealing with corner cases et al as afterthoughts
is that it is all too easy to overlook special cases. When
testing doesn't catch these glitches the result can be long term
latent bugs.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
Richard Heathfield
Ben is a knowledgeable contributor to this newsgroup, and most polite
with it. You would do well to try to emulate him rather than insult him.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
io_x
"io_x" <a...@b.c.invalid> ha scritto nel messaggio
news:4ba5edaf$0$1133$4faf...@reader1.news.tin.it...
i forgot to say that the strstrrWithIndex()
and main() functions are by E. Nilges
post here in this thread
news:0827d2cd-b832-4112...@k6g2000prg.googlegroups.com...
thank to him
thanks to all you, for all
> #include <stdio.h>
...
> #define TRUTH -1
> #define FALSITY 0
> #define NULLITY 0
...
spinoza1111
> Richard Bos wrote:
>
> >> spinoza1111 <spinoza1...@yahoo.com> writes:
>
> >> I don't expect you to change your style -- you've evolved it to
> >> provoke a response here
>
> > And once again, he's succeeded. Well done for falling for it, jerk.
>
> Ben is a knowledgeable contributor to this newsgroup, and most polite
> with it. You would do well to try to emulate him rather than insult him.
I agree with Richard Heathfield. Ben is one of the best and most
analytical minds here and he has helped me spot errors in my code.
spinoza1111
Ben Bacarisse tested this code for finding aax in aaax and it failed.
I spent about ten minutes to discover that at the point where I need
to note the "character handle" address in the "master" string, I noted
it in the TARGET string. Oh gee, I am adhd mommie! But I'm rilly
great!
Seriously, that's why the code was submitted, to find and fix errors.
Please note that Seebach does not respond to error reports quickly or
at all, whereas a real programmer treats them as a challenge to fix
the error ... FAST. And, we're talking two months to mess up two case
statements. I still maintain that he's here for fixes and not to
participate in collective debugging, and I say this to avoid tu quoque
arguments.
I do not claim that this strstr is bug free. That awaits my finding
time to compose a correctness proof in natural language, based on
recursion on the length of the string in all probability.
Thanks again to Ben
Who finds so many errors
When I get mail from him
I am filled with nameless terrors
For he finds so much stuff
Which shows my code is a draft that is rough.
#include <stdio.h>
// ***************************************************************
// * *
// * strstr *
// * *
// * This function (strstr) finds a string, probably as fast as *
// * possible without extra memory usage over and above brute *
// * force. *
// * *
// * In searching a Nul terminated string for a substring, there *
// * are logically three possibilities in a left to right *
// * traversal of the master string that (1) looks for the *
// * first character of the target and then (2) matches all the *
// * remaining characters: *
// * *
// * * (Erroneous): on the failure of a partial match, *
// * restart at the first nonmatching character. This is *
// * fast but wrong, since the matching string may *
// * overlap the partial match. *
// * *
// * * (Too slow): on the failure of a partial match, start*
// * one past the first character (of the partial match) *
// * *
// * * (Just right): while matching characters, note the *
// * leftmost character in the searched string, to the *
// * right of the first matched character, that matches *
// * both that character and, of course, the first *
// * character of the target. *
// * *
// * C H A N G E R E C O R D --------------------------------- *
// * DATE PROGRAMMER DESCRIPTION OF CHANGE *
// * -------- ---------- --------------------------------- *
// * 03 18 10 Nilges Version 1.0 *
// * *
// * 03 19 10 Nilges Version 1.1 *
// * *
// * 1. Incorporates Pete's suggestion*
// * that a null target string is *
// * always found at the start of *
// * the master string. *
// * *
// * 2. Results display enhanced *
// * *
// * 03 19 10 Nilges Version 1.11: bug: ptrMaster was *
// * incorrectly set one past the *
// * ptrHandle *
// * *
// * 03 20 10 Nilges Version 1.12 *
// * *
// * 1. Bug (reported by BB): *
// * assignment used in place of *
// * equality test *
// * *
// * 2. Bug: incorrect test for noting *
// * char handle goes all the way *
// * back to start of string *
// * *
// * 03 21 10 Nilges Version 1.13 *
// * *
// * 1. Boolean statement simplified *
// * per Morris Keesan. *
// * *
// * 2. Bug found by Ben Bacarisse: *
// * statement that records char *\
// * handle set it to target and not*
// * master. *
// * *
// * ----------------------------------------------------------- *
// * *
// * To find a string, oh Muse! I sing, inside another String! *
// * Alternatives to me come in Three, ah, that's the thing: *
// * For the one thing for which the Wise must watch is mayhap, *
// * Partial occurences that most melancholy, overlap. *
// * The first is base, mechanical, low, and tragicomical: *
// * It's to restart from the previous beginning plus but One *
// * Oh what Mayhem to true Programming is thereby, done! *
// * But the job it will do, as did Hercules, *
// * His Labors for the Goddess cruel in Seneca's tragedies: *
// * Arduously and ignobly like unto the meanest Hind *
// * That knoweth not his Elbow from his Behind. *
// * The second is worse, a boner, a solecism, and a Seebach: *
// * The second restarts at the character that doth match! *
// * Oh muse! Such hellish Sights before me yawn: *
// * But be assur'd, 'tis darkest just before the Dawn. *
// * Shout for Victory, oh Thrace, and smite the Harp, and Grin: *
// * For lo, we start at the leftmost "handle" of the string *
// * When it occureth in *
// * The tragic partial match that hath failed us. *
// * If no such handle exists, then we can restart *
// * At the point of match failure: no, 'tis not a brain fart. *
// * Now we spy our magic bus: *
// * For this is the best Al Gore ithm *
// * That we can hope for in C, a language without Rhyme, or *
// * for that matter, Oh Muse! rhythm. *
// * *
// ***************************************************************
#define TRUTH -1
#define FALSITY 0
#define NULLITY 0
char * strstrWithIndex(char *strMaster,
char *strTarget,
int *ptrIndex)
{
char *ptrMaster = NULLITY;
char *ptrTarget = NULLITY;
char *ptrHandle = NULLITY;
char *ptrMasterStart = NULLITY;
int booFound = FALSITY;
*ptrIndex = 0; // Rel. 1.1
if (!*strTarget) return strMaster; // Rel. 1.1
if (!*strMaster) return 0; // Rel. 1.1
for (ptrMaster = strMaster; *ptrMaster;)
{
for (;
*ptrMaster && *ptrMaster != *strTarget;
ptrMaster++);
ptrTarget = strTarget;
*ptrIndex = ptrMaster - strMaster;
ptrHandle = 0;
ptrMasterStart = ptrMaster;
for (;
*ptrTarget
?
(*ptrMaster
?
*ptrMaster==*ptrTarget
:
FALSITY)
:
(booFound = TRUTH, FALSITY);
ptrMaster++, ptrTarget++)
{
if (ptrHandle == 0 // Rel 1.12
&&
ptrMaster > ptrMasterStart
&&
*ptrMaster == *strTarget)
ptrHandle = ptrMaster; // Rel. 1.13
}
if (booFound) return strMaster + *ptrIndex;
if (ptrHandle) ptrMaster = ptrHandle; // Rel. 1.11 bug fix
}
*ptrIndex = 0;
return 0;
}
char * strstr(char *strMaster, char *strTarget)
{
int ptrIndex = 0;
return strstrWithIndex(strMaster, strTarget, &ptrIndex);
}
int main(void)
{
char *ptrIndex1 = NULLITY;
int intIndex1 = 0;
printf("strstr Version 1.13\n\n");
printf("Expect 'aax': %s\n",
strstrWithIndex("aaax", "aax", &intIndex1));
printf("Expect 1: %d\n", intIndex1);
printf("Expect 0: %x\n", *strstr("", ""));
printf("Expect '0': '%c'\n", *strstr("0123456789", ""));
printf("Expect 0: %d\n", strstr("", "0"));
printf("Expect 0: %d\n", strstr("Here", "There"));
ptrIndex1 = strstrWithIndex("There", "here", &intIndex1);
printf("Expect 1: %d\n", intIndex1);
ptrIndex1 = strstrWithIndex("They seek him here",
"here",
&intIndex1);
printf("Expect 14: %d\n", intIndex1);
ptrIndex1 = strstrWithIndex("They seek him there",
"here",
&intIndex1);
printf("Expect 15: %d\n", intIndex1);
ptrIndex1 = strstrWithIndex
("The clc regs seek him everywhere",
"here",
&intIndex1);
printf("Expect 28: %d\n", intIndex1);
printf("Expect 'h': '%c'\n", *ptrIndex1);
ptrIndex1 = strstrWithIndex
("Is he in Heaven? Or in Hell?",
"?",
&intIndex1);
printf("Expect 15: %d\n", intIndex1);
printf("Expect '?': '%c'\n", *ptrIndex1);
ptrIndex1 = strstrWithIndex
("That damn'd elusive Spinoza won't tell!",
"Spinoza",
&intIndex1);
printf("Expect 20: %d\n", intIndex1);
printf("Expect 'p': '%c'\n", *(ptrIndex1+1));
printf("Expect '0': '%c'\n", *strstr("0123456789", "0"));
printf("Expect '1': '%c'\n", *strstr("0123456789", "1"));
printf("Expect '0': '%c'\n", *strstr("0123456789", "0"));
printf("Expect '9': '%c'\n", *strstr("0123456789", "9"));
printf("Expect '5': '%c'\n",
*strstr("0123456789", "345") + 2);
printf("Expect '8': '%c'\n", *strstr("0123456789", "89"));
ptrIndex1 = strstrWithIndex("0123456789A89AB",
Ben Bacarisse
> // * 1. Bug (reported by BB): *
> // * 2. Bug found by Ben Bacarisse: *
The previous request that my name not be associated with your work
still stands. Not much you can do about it now, but if there is
another version or the code is posted anywhere else, please remove
these remarks. Thank you.
--
Ben.
spinoza1111
It's this lack of basic courtesy that's the problem here. Why the fuck
do you embarass me in public when you could have sent email about this
matter? Furthermore, there are people here who think it's cute to
splatter my name all over the Internet, associated with the foulest
lies. I was trying to CREDIT you, asshole, in a public newsgroup where
credit and discredit is seen by current and potential employers and
clients.
The main trouble with many of you is that you literally think that
hardware and stupid ideas from the past are more important than
decency, self-respect and personal reputation.
I'd forgot the promise to not name you because it was offensive of you
to ask it, as if I'm some sort of person you "really" care not to
associate with...although for the same reason that internet posting is
publication, your dialog with me is a dialog, in which basic
"discourse ethics" (a fancy word for basic decency) demands a
mutuality of recognition and respect.
I will endeavor in future to steal your ideas and contributions and
not credit you as you request. That's the normalized deviance here,
isn't it.
>
> --
> Ben.
spinoza1111
After my reply above to Ben, I opened email to discover that he had
erroneously posted.
I apologize for the note to Ben but not globally for foul language and
strong words in other posts. This is because after years of relative
self-restraint, I'm appalled by the REAL foul language here, which is
the language of personal destruction. I thought Ben was intentionally
trying to embarass me. He was not. He is a great technician and
overall somewhat more collegial than others here, and you know who you
are. I agree with Heathfield of all people that Ben never misuses the
ng and never feeds the so-called "trolls".
I am very impressed by his powerful insight into code.
Richard Heathfield
> On Mar 22, 11:38 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>>> // * 1. Bug (reported by BB): *
>>> // * 2. Bug found by Ben Bacarisse: *
>> The previous request that my name not be associated with your work
>> still stands. Not much you can do about it now, but if there is
>> another version or the code is posted anywhere else, please remove
>> these remarks. Thank you.
>
> It's this lack of basic courtesy that's the problem here. Why the fuck
> do you embarass me in public when you could have sent email about this
> matter?
Ben is a knowledgeable contributor to this newsgroup, and most polite
with it. You, like Richard Bos, would do well to try to emulate him
rather than insult him.
I refer you to
<2847e6b3-9ada-44de...@v34g2000prm.googlegroups.com>
<nonsense snipped>
Phil Carmody
> spinoza1111 <spino...@yahoo.com> writes:
> I don't expect you to change your style -- you've evolved it to
> provoke a response here
== TROLL
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
spinoza1111
> spinoza1111wrote:
> > On Mar 22, 11:38 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >>> // * 1. Bug (reported by BB): *
> >>> // * 2. Bug found by Ben Bacarisse: *
> >> The previous request that my name not be associated with your work
> >> still stands. Not much you can do about it now, but if there is
> >> another version or the code is posted anywhere else, please remove
> >> these remarks. Thank you.
>
> > It's this lack of basic courtesy that's the problem here. Why the fuck
> > do you embarass me in public when you could have sent email about this
> > matter?
>
> Ben is a knowledgeable contributor to this newsgroup, and most polite
> with it. You, like Richard Bos, would do well to try to emulate him
> rather than insult him.
I'm not "insulting" him. Merely using strong language in response to
what appeared at the time to be offensive is not "insulting" a person.
No, "insulting" a person is a matter of grammar...not word choice. You
insult people all the time, in the dulcet-corporate register, by
questioning their bonafides based on the most trivial of errors, that
are artifacts of production processes over which programmers and
software have little or no control.
You have posted letters you claim that I have written and you have
lied about my publication in comp.risks. That's an insult. I'd rather
you were man enough to call me a fucking asshole. To my face. But
you're not.
Richard Heathfield
> On Mar 22, 2:47 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Ben is a knowledgeable contributor to this newsgroup, and most polite
>> with it. You, like Richard Bos, would do well to try to emulate him
>> rather than insult him.
>
> I'm not "insulting" him.
No, you only called him an asshole. That's not an insult, is it? Of
course not.
<some nonsense snipped>
> You have posted letters you claim that I have written
No, I haven't. If you disagree, you can easily prove your point by
posting the message ID in which I did this. Since I didn't, however, you
can't prove your point. You will therefore have to resort to weasel
words, pop psychiatry, downright lies, or non sequiturs, as usual.
> and you have
> lied about my publication in comp.risks.
Wrong again.
> That's an insult. I'd rather
> you were man enough to call me a fucking asshole. To my face. But
> you're not.
There's nothing manly about trumpeting one's limited adjectival
vocabulary in public.
spinoza1111
> spinoza1111wrote:
> > On Mar 22, 2:47 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> <snip>
> >> Ben is a knowledgeable contributor to this newsgroup, and most polite
> >> with it. You, like Richard Bos, would do well to try to emulate him
> >> rather than insult him.
>
> > I'm not "insulting" him.
>
> No, you only called him an asshole. That's not an insult, is it? Of
> course not.
No, in fact it is nothing like your incorrect inferences about Herb
Schildt or Jacques Navia, inferences which are popular in nasty and
anti-intellectual little business offices in which men moronized by
toil are taught to believe that their moronization is intelligence.
"Asshole" is precise, and it refers to specific, in the Now, behavior.
Whereas when you make your silly inferences they simultaneously expose
deep ignorance (for example, of the fact that a linked list is
normally a list of pointers and not data) and call into question the
possibility of computer science, in a manner which makes it possible
for insurance companies and banks to defraud.
>
> <some nonsense snipped>
>
> > You have posted letters you claim that I have written
>
> No, I haven't. If you disagree, you can easily prove your point by
> posting the message ID in which I did this. Since I didn't, however, you
> can't prove your point. You will therefore have to resort to weasel
> words, pop psychiatry, downright lies, or non sequiturs, as usual.
When your type is cornered you bleat for evidence. Richard, you posted
a forgery. It's legally actionable now. I don't have time to look it
up and waste on you, but if necessary it will appear as evidence in a
court of law.
>
> > and you have
> > lied about my publication in comp.risks.
>
> Wrong again.
Yes, you did. You claimed that you'd scanned headers of comp.risks.
This was a malicious lie, because you knew that the headers don't
contain author names and you hoped that sufficient people would be
even more ignorant than you are.
>
> > That's an insult. I'd rather
> > you were man enough to call me a fucking asshole. To my face. But
> > you're not.
>
> There's nothing manly about trumpeting one's limited adjectival
> vocabulary in public.
Actually, the reason for your hatred and that of Seebach is that
you're both programmers with verbal abilities in writing slightly
above a mean that is low, and getting lower, in both the US and UK,
who fancy yourselves digerati. It has bothered you since 1999 that I
have a much higher and deeper literacy and culture as well as
considerable programming experience, because I exposed you as an
uneducated hack when I created my popular thread in 1999 on
programming professionalism, on the basis of which I was invited by
Princeton University Press to join an online panel with Mike Godwin
and Cass Sunstein on internet liberty.
Therefore, my referring to you as a loudmouth thug and fucking asshole
only shows that words fail, at times, in your case. At other times, I
have offended you, deliberately, in Alexandrine verse, so I am not
exposing any illiteracy of my own when I refer to you as a cocksucker.
Only writing at your reading level.
Words fail in the case of certain reprobate Clowns
Who post from some hovel on the United Kingdom's downs
Pompous piffle, malicious malarkey, and sublunary nonsense
Possibly in the pay of SAMS, for a few pathetic pence.
Words fail the Poet, words fail the philosopher
To describe the ways of some programmer gofer
Who like the Fly would dream of being a Man
Who wakes to cry to dream again when he sees he's got a wingspan.
Words fail this homunculus, this trogdolyte, this clueless Cunt
Even though this took 30 seconds, and in a thesaurus I did not Hunt.
Richard Heathfield
> On Mar 22, 5:24 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> spinoza1111wrote:
>>> On Mar 22, 2:47 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> <snip>
>>>> Ben is a knowledgeable contributor to this newsgroup, and most polite
>>>> with it. You, like Richard Bos, would do well to try to emulate him
>>>> rather than insult him.
>>> I'm not "insulting" him.
>> No, you only called him an asshole. That's not an insult, is it? Of
>> course not.
>
> No
Wrong.
<nonsense snipped>
>> <some nonsense snipped>
>>
>>> You have posted letters you claim that I have written
>> No, I haven't. If you disagree, you can easily prove your point by
>> posting the message ID in which I did this. Since I didn't, however, you
>> can't prove your point. You will therefore have to resort to weasel
>> words, pop psychiatry, downright lies, or non sequiturs, as usual.
>
> When your type is cornered you bleat for evidence.
Yup, them's weasel words all right.
> Richard, you posted
> a forgery. It's legally actionable now.
No, I didn't, and no, it isn't, and no, you won't, because you know
you'll end up paying my costs if you do.
<snip>
>>> and you have
>>> lied about my publication in comp.risks.
>> Wrong again.
>
> Yes, you did.
You need to look up the meaning of "lie". You have completely
misunderstood what it means.
<nonsense snipped>
Kenny McCormack
Phil Carmody <thefatphi...@yahoo.co.uk> replied to Ben, thusly:
>Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> spinoza1111 <spino...@yahoo.com> writes:
>> I don't expect you to change your style -- you've evolved it to
>> provoke a response here
>
>== TROLL
Ben is a troll now?
Wow - I guess you really have to watch your back in this NG...
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
spinoza1111
wrote:
> In article <87wrx4x19s....@kilospaz.fatphil.org>,
> Phil Carmody <thefatphil_demun...@yahoo.co.uk> replied to Ben, thusly:
>
> >Ben Bacarisse <ben.use...@bsb.me.uk> writes:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> I don't expect you to change your style -- you've evolved it to
> >> provoke a response here
>
> >== TROLL
>
> Ben is a troll now?
>
> Wow - I guess you really have to watch your back in this NG...
>
> --
> (This discussion group is about C, ...)
>
> Wrong. It is only OCCASIONALLY a discussion group
> about C; mostly, like most "discussion" groups, it is
> off-topic Rorsharch revelations of the childhood
> traumas of the participants...
Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
photographed on a motorcycle in his first book) used to give guys like
Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
have been nursing the hurt ever since. And confronting their bullying
is NOT itself bullying.
spinoza1111
The British lower middle class have a touching faith in dictionaries
that started with prize giveaways of Johnson's Dictionary, but Becky
Sharp threw it out her carriage window in Thackeray's Vanity Fair.
Some of us learn words by reading, not by memorizing the dictionary,
and you tell lies, Richard.
Colonel Harlan Sanders
<spino...@yahoo.com> wrote:
>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
>photographed on a motorcycle in his first book) used to give guys like
>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
>have been nursing the hurt ever since. And confronting their bullying
>is NOT itself bullying.
So, now you're characterizing your hero Schildt as a bully, as part
of your increasingly ridiculous campaign to ... ah, yes, preserve
Schildt's good name.
You've disappeared up your own anus completely now. Good riddance.
spinoza1111
> On Mon, 22 Mar 2010 08:27:35 -0700 (PDT),spinoza1111
>
Learn to read. I didn't say that Schildt bullied Dweebach. I said,
Rufus, that perhaps guys who looked like Schildt (a big hairy guy)
bullied Dweebach when he was widdle and he's been nursing the hurt at
heart.
Colonel Harlan Sanders
Ist ein anders
He can't read
A clue doth he need.
And at this point, having shown patience and collegiality with
Dweebach, I will indeed make a joke out of his patronym. I attempted
to contact him politely last January; he said he deleted the mail
unread. He has called me a moron and insane, which causes thugs and
genuinely insane people like you and Bill Reid to post. OK, gloves
off.
Seebs
> On Mon, 22 Mar 2010 08:27:35 -0700 (PDT), spinoza1111
><spino...@yahoo.com> wrote:
>>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
>>photographed on a motorcycle in his first book) used to give guys like
>>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
>>have been nursing the hurt ever since. And confronting their bullying
>>is NOT itself bullying.
> So, now you're characterizing your hero Schildt as a bully, as part
> of your increasingly ridiculous campaign to ... ah, yes, preserve
> Schildt's good name.
This is getting surreal.
The beautiful thing is that Nilges doesn't seem to realize that if,
in fact, Schildt was a bully, and people were confronting the bully by
accurately pointing out flaws in his work this would, by Nilges' own
statements, NOT be a kind of bullying.
It's weird. You sometimes almost get the impression he believes that the
stuff he makes up has some kind of external referent. I think that, as
he imagines things that make him feel victorious, he just sort of assumes
them to be true, rather than imagined. Very weird.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
spinoza1111
> On 2010-03-22, Colonel Harlan Sanders <Har...@kfc.com> wrote:
>
> > On Mon, 22 Mar 2010 08:27:35 -0700 (PDT),spinoza1111
> ><spinoza1...@yahoo.com> wrote:
> >>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
> >>photographed on a motorcycle in his first book) used to give guys like
> >>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
> >>have been nursing the hurt ever since. And confronting their bullying
> >>is NOT itself bullying.
> > So, now you're characterizing your hero Schildt as a bully, as part
> > of your increasingly ridiculous campaign to ... ah, yes, preserve
> > Schildt's good name.
>
> This is getting surreal.
>
> The beautiful thing is that Nilges doesn't seem to realize that if,
> in fact, Schildt was a bully, and people were confronting the bully by
I'm not saying he was. I am saying that in his publicity for his first
book (Born to Code in C), he was portrayed as a studly guy on a
motorcycle, and I am speculating that this bothered you because of
conflicts you haven't resolved...conflicts that I resolved, in part,
by taking challenging classes at university (such a calculus and
computer science) that I didn't have to since I was a philosophy
major.
Whereas you seem to have avoided challenges all your life and now, at
the age of forty, you are, as a putative C expert, submitting code to
this ng with random fall through in case statements after two months
work, making a fool out of yourself.
> accurately pointing out flaws in his work this would, by Nilges' own
> statements, NOT be a kind of bullying.
No, not the original document. The bullying was constituted in the
fact that since then, you've not apologized for the document creating
a global bad impression about Schildt who is not a C specialist but
was asked, because he can write, to write a book about C. The bullying
here is your calling me a "moron" and insane because of trivial errors
which I fix, whilst in pseudo.c and elsewhere you consistently make,
and fail to fix errors, repeatedly telling us that you're "rilly" a
genius who gets unimportant matters wrong but does great things.
>
> It's weird. You sometimes almost get the impression he believes that the
> stuff he makes up has some kind of external referent. I think that, as
> he imagines things that make him feel victorious, he just sort of assumes
> them to be true, rather than imagined. Very weird.
>
> -s
> --
spinoza1111
>
> > On Mon, 22 Mar 2010 08:27:35 -0700 (PDT),spinoza1111
> ><spinoza1...@yahoo.com> wrote:
> >>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
> >>photographed on a motorcycle in his first book) used to give guys like
> >>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
> >>have been nursing the hurt ever since. And confronting their bullying
> >>is NOT itself bullying.
> > So, now you're characterizing your hero Schildt as a bully, as part
> > of your increasingly ridiculous campaign to ... ah, yes, preserve
> > Schildt's good name.
>
> This is getting surreal.
>
> The beautiful thing is that Nilges doesn't seem to realize that if,
> in fact, Schildt was a bully, and people were confronting the bully by
> accurately pointing out flaws in his work this would, by Nilges' own
> statements, NOT be a kind of bullying.
>
> It's weird. You sometimes almost get the impression he believes that the
> stuff he makes up has some kind of external referent. I think that, as
> he imagines things that make him feel victorious, he just sort of assumes
> them to be true, rather than imagined. Very weird.
>
> -s
> --
You also find youself allied, not with good programmers, but with
people like "Colonel" and Bill Reid who come here themselves for one
purpose, and one purpose alone, to find people to abuse.
spinoza1111
>
> > On Mon, 22 Mar 2010 08:27:35 -0700 (PDT),spinoza1111
> ><spinoza1...@yahoo.com> wrote:
> >>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
> >>photographed on a motorcycle in his first book) used to give guys like
> >>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
> >>have been nursing the hurt ever since. And confronting their bullying
> >>is NOT itself bullying.
> > So, now you're characterizing your hero Schildt as a bully, as part
> > of your increasingly ridiculous campaign to ... ah, yes, preserve
> > Schildt's good name.
>
> This is getting surreal.
>
> The beautiful thing is that Nilges doesn't seem to realize that if,
> in fact, Schildt was a bully, and people were confronting the bully by
> accurately pointing out flaws in his work this would, by Nilges' own
> statements, NOT be a kind of bullying.
Yes, that is correct, Peter.
However, in normal academic work, which programming needs to use as a
model for truth, you needed to fulfill three requirements in "C: the
Complete Nonsense":
* You needed to be correct about there being "hundreds" of errors in
Schildt's work which you claimed in the document. However, you only
posted twenty, and this simply didn't prove that there were "hundreds"
unless there's a recursive proof that I missed in ctcn.
* You needed to have standing owing to the seriousness of your
charges, which had the effect of damaging Schildt's good name and
McGraw Hill's business. But in two ways you did not.
At the time and today, you by your own admission have not taken any
computer science course work, and this resulted in real errors of your
own, including your belief that it wasn't proper to use the stack in
explaining how runtime works because the word isn't in a standard
published seven years after Schildt's first edition and four years
after ctcn, as well as your belief that heaps only are used in DOS.
Furthermore, we have new evidence in this newsgroup that you're
incompetent as a programmer. You have consistently posted code
snippets that are wrong, not in the typo sense but of the sort a
competent programmer would not dare post here. For example, you posted
strlen with an off by one error and most recently reversed a sign.
When you make these errors, instead of fixing them, you ask for
charity as one who suffers from ADHD, which we'd be happy to extend
but for your lack of charity towards Schildt or myself.
Most egregiously, you have posted a link to a root file op simulator
of some sort for Linux, which is contradictorily marked as copyright
by Wind River Systems and under GNU public license which contains
newbie errors including uninitialized variables and switch cases which
apparently incorrectly fallthrough without break statements. This, you
say, is the product of two months work.
* You needed to be civil and cautious, and prereview your concerns
with McGraw Hill and Herb, and you by your own admission failed to do
so, because you were not able to extort a large sum of money from
McGraw Hill. This is in my experience at Princeton the norm for
academic discourse which the best programmers take as their model to
avoid savage scenes such as the norm here.
>
> It's weird. You sometimes almost get the impression he believes that the
> stuff he makes up has some kind of external referent. I think that, as
> he imagines things that make him feel victorious, he just sort of assumes
> them to be true, rather than imagined. Very weird.
>
> -s
> --
Tim Rentsch
> Dr Malcolm McLean <malcolm...@btinternet.com> writes:
>
>> On 20 Mar, 22:16, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>>>
>>> What's the point of defining TRUTH as -1, instead of accepting the
>>> language-defined truth value of 1,
>>>
>> ~TRUTH == FALSITY;
>
> !FALSITY != TRUTH and !!TRUTH != TRUTH. There is no reason to favour
> the action of ~ over that of !. In fact there are good reasons *not*
> to favour it. For example, your claim (~TRUTH == FALSITY) is not the
> case in two out of the three valid number representations that C
> permits.
>
>> also, if booleans are one bit, a set bit is -1 in two's complement
>> notation.
>
> There is no reason to assume that one bit Booleans are signed rather than
> unsigned. [snip]
Indeed, C99 explicitly makes its boolean type, _Bool, an unsigned type.
Dr Malcolm McLean
wrote:
> Ben Bacarisse <ben.use...@bsb.me.uk> writes:
>
Which introduces an inconsistency in the language.
signed bool -> 0 or -1
unsigned bool -> 0 or 1
bool -> signed bool
would be rules consistent with the other types.
Ben Bacarisse
> On 25 Mar, 13:01, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu>
> wrote:
>> Ben Bacarisse <ben.use...@bsb.me.uk> writes:
>> > Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>>
>> >> On 20 Mar, 22:16, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>>
>> >>> What's the point of defining TRUTH as -1, instead of accepting the
>> >>> language-defined truth value of 1,
>>
>> >> ~TRUTH == FALSITY;
>>
>> > !FALSITY != TRUTH and !!TRUTH != TRUTH. There is no reason to favour
>> > the action of ~ over that of !. In fact there are good reasons *not*
>> > to favour it. For example, your claim (~TRUTH == FALSITY) is not the
>> > case in two out of the three valid number representations that C
>> > permits.
>>
>> >> also, if booleans are one bit, a set bit is -1 in two's complement
>> >> notation.
>>
>> > There is no reason to assume that one bit Booleans are signed rather than
>> > unsigned. [snip]
>>
>> Indeed, C99 explicitly makes its boolean type, _Bool, an unsigned
>> type.
>>
> Which introduces an inconsistency in the language.
>
> signed bool -> 0 or -1
or 0 and -0 for sign-and-magnitude numbers and 0 and 0 for one's
complement (if you take C's definitions literally). In C, a signed
single bit is a very bad idea.
> unsigned bool -> 0 or 1
> bool -> signed bool
>
> would be rules consistent with the other types.
That would be inconsistent with char.
--
Ben.
Keith Thompson
> wrote:
>> Ben Bacarisse <ben.use...@bsb.me.uk> writes:
>> > Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>>
>> >> On 20 Mar, 22:16, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>>
>> >>> What's the point of defining TRUTH as -1, instead of accepting the
>> >>> language-defined truth value of 1,
>>
>> >> ~TRUTH == FALSITY;
>>
>> > !FALSITY != TRUTH and !!TRUTH != TRUTH. There is no reason to favour
>> > the action of ~ over that of !. In fact there are good reasons *not*
>> > to favour it. For example, your claim (~TRUTH == FALSITY) is not the
>> > case in two out of the three valid number representations that C
>> > permits.
>>
>> >> also, if booleans are one bit, a set bit is -1 in two's complement
>> >> notation.
>>
>> > There is no reason to assume that one bit Booleans are signed rather than
>> > unsigned. [snip]
>>
>> Indeed, C99 explicitly makes its boolean type, _Bool, an unsigned type.
>>
>
> signed bool -> 0 or -1
> unsigned bool -> 0 or 1
> bool -> signed bool
>
> would be rules consistent with the other types.
char is already inconsistent with the other integer types, in that
plain char may be either signed or unsigned and is distinct from
both signed char and unsigned char.
But even if it's an inconsistency, so what? _Bool is intended only
to hold the values 0 and 1. The conversion rules make it difficult
to store any other value in a _Bool object. How is the inconsistency
a problem, and how would the ability to declare "signed bool" or
"unsigned bool" be helpful?
"A foolish consistency is the hobgoblin of little minds" -- Emerson
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Tim Rentsch
These comments make sense only if the behavior of _Bool were like that
of the other integer types, but it isn't. Storing into a _Bool will
always store either a 0 or a 1; it simply isn't possible to store any
other value because of how conversion to _Bool is defined. There's no
reason to have a signed version of _Bool.
You might want another "boolean" type, let's call it '_Boolean_int',
that behaves the way you suggest. An implementation could define such
a type. But it doesn't make sense to do that for _Bool (and
personally I don't see much value in having a type like _Boolean_int).
Ben Bacarisse
<snip>
> These comments make sense only if the behavior of _Bool were like that
> of the other integer types, but it isn't.
I agree with this but I've snipped the discussion because I wanted to
comment on something else.
> Storing into a _Bool will
> always store either a 0 or a 1; it simply isn't possible to store any
> other value because of how conversion to _Bool is defined.
When compiled with gcc, this program:
#include <stdio.h>
#include <string.h>
int main(void)
{
_Bool b;
memcpy(&b, (unsigned char []){2}, sizeof b);
printf("b=%d\n", b);
return 0;
}
prints b=2 and I can't see any reason to think that gcc is wrong to do
that. I don't think the program /has/ to print b=2 but I think it is
permitted.
You can argue that this program does not "store a value" in b (it
copies a representation) but it is does end up with a value other than
0 or 1 stored in b.
<snip>
--
Ben.
Tim Rentsch
> Tim Rentsch <t...@x-alumni2.alumni.caltech.edu> writes:
> <snip>
>> These comments make sense only if the behavior of _Bool were like that
>> of the other integer types, but it isn't.
>
> I agree with this but I've snipped the discussion because I wanted to
> comment on something else.
>
>> Storing into a _Bool will
>> always store either a 0 or a 1; it simply isn't possible to store any
>> other value because of how conversion to _Bool is defined.
>
> When compiled with gcc, this program:
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> _Bool b;
> memcpy(&b, (unsigned char []){2}, sizeof b);
> printf("b=%d\n", b);
> return 0;
> }
>
> prints b=2 and I can't see any reason to think that gcc is wrong to do
> that. I don't think the program /has/ to print b=2 but I think it is
> permitted.
Yes, I would agree with that; it is permitted because undefined
behavior has occurred.
> You can argue that this program does not "store a value" in b (it
> copies a representation) but it is does end up with a value other than
> 0 or 1 stored in b.
The program doesn't store a value into a _Bool. It does store a
value into b, and the declared type of b is _Bool, but it doesn't
(at least not in the sense that I meant the phrase) store a value
into a _Bool. I meant for my statement to apply only to
assignment-like contexts (assignment, initialization, function
argument, return statement) with the target type being _Bool.
It is of course possible for a _Bool variable to hold a value
other than 0 or 1, through undefined behavior (or to be more
precise I should say that implementations are allowed to act as
though a _Bool variable holds a value other than 0 or 1, although
they don't have to). But storing into a _Bool, eg, using _Bool
as the left-hand-side type in an assignment, only ever stores
a 0 or 1 (or of course may do anything at all if previous
undefined behavior has occurred).
(I'm sure none of the technical points here are news to you;
I'm responding just to clarify my meaning.)
Dr Malcolm McLean
Each bool pointer can have an offset (these can be stored in the upper
bits in many systems, to avoid inflating pointer size).
This has has the advantage that when we declare an array of bools
bool occupiedflags[8];
The processor can allocate only a single octamer. This represents a
87.5% saving in memory.
There's only one snag, which is with the infamous size_t.
memcpy(&flag1, £flag2, sizeof(bool));
should copy a single bool.
So the answer is to make size_t a double. This system has huge
advantages. For instance fwrite(), which takes a size_t, can now write
bitstreams to files, somethign which was difficult to achieve with the
old defintion of size_t.