Implementing strstr

S

spinoza1111

Just for the record, I think I'm going to more or less bow out
of that role; it really does feel uncomfortably like "let's you
and him fight."  As a parting shot, maybe, I'll mention message IDs
of two posts you *might* want to look at [*].  
<24d9395d-4684-49cf-b9fb-3ccab608c...@n34g2000yqb.googlegroups.com>
is a reply to one of your posts about your build tool thing, the one
that uses (used?) the quick-and-dirty %s-replacing code.

Used, past-tense; we changed the way we generated the strings in which
to perform substitutions, so I switched to the version which took
ten minutes to write instead of five minutes to write, which was posted
here quite a while back.

And I think I'll pass.  The term "reply" normally carries connotations
of some kind of relevance or lucidity, which I am not sure are applicable..
<262e34a1-0e34-47b2-9fbc-459a25f09...@q16g2000yqq.googlegroups.com>
is a follow-up to your comment about your parents being math teachers,
and has a specific list of questions.

If he'd answered my specific, technically relevant, questions back when I
first tried to engage him, I *might* care.  As is, I have pretty much no
interest.  I'll consider questions addressed to me by people that I believe
to be sane.

You're lying: you posted none. I was the one with the questions about
"C: the Complete Reference". I pointed out its contradictions:

"The following is a partial list [1] of the errors I am aware of [2],
sorted by page number. I am not including everything [3]; just many
[4] of them."

"I am missing several hundred errors [5]. Please write me if you think
you know of any I'm missing. [6] Please also write if you believe one
of these corrections is inadequate or wrong; I'd love to see it."

"Currently known: [5]"

[1] Contradicts "currently known". Like your solecism in the use of
"clear", which means understandable and providing a clear view of the
truth, your sloppy English allows you to lie to yourself and others.
"Currently known" means in the absence of further qualification,
"these are all the known errors".

[2] Implies that there are n errors and the list lists m<n. But what
are they? We have no idea.

[3] Why not?

[4] When you say "I am missing several hundred errors", this could
mean that you want people to join in a deliberate campaign to destroy
Herbert Schildt's reputation (which is civilly and possibly criminally
liable) or that you somehow have determined that there are M~~1000
errors, but you present N=20. But in this context, N is not "many".\

[5] This is a very disturbing statement, as above. Did you lose them?
Did you forget them? Were you off medication? Were you on medication?
Or did you seek to form a cybernetic mob and gang up on Herb Schildt?

[6] Very disturbing.

[5] Followed by 20 errors

1. Negative numbers not ALWAYS represented in twos complement
notation: but this is what the head of department said in my graduate
level class on computer architecture, that IN GENERAL twos complement
is used.

2. Static global variables: the important distinction in computer
science is between variables which are static and have global scope,
and variables which are allocated either at procedure startup or in
blocks depending on the language, and have local scope. It is more
important to learn this in general for all programming languages so
that one can learn new languages.

3. Printing sizeof values as floats or doubles: although I do not
know why Herb did this, he did know, as you seem not to, that all ints
are floats and all floats are doubles in well-structured languages.
Because at the time C was almost as diverse of the languages of China,
Herb used the educated programmer's maxim, which is to first code as
if the compiler writers and language designers knew what he knows, and
fix problems later.

4. The put_rec code was errata. McGraw Hill offered you the chance to
work collegially with Herb to fix errata. Because his books were
successful, he's gone to several editions, and has fixed most of the
errata.

5. In college lectures which YOU DID NOT ATTEND, "binary operators"
often is verbal shorthand for "the commonly known binary arithmetic
operators, with logic operators being treated separately".

6. Wow, a reference to undefined behavior, of the same sort you make
in queue.c after two months work, and again, errata.

7. You really lay an egg. Like a disruptive student, you forbid the
teacher to talk about stacks as if it's even possible to implement C,
or any language, without stacks. You then surpass this, and say "the
'heap' is a DOS term".

8. Free as in speech, not beer. The storage was free. A minor
solecism at worst.

9. Mr. Snoid is lost in the void. Herb knows very well that to return
"void" is to return nothing and not return anything. You're disrupting
the class to show off. But worse, you're actually trying to destroy
someone so that you can get recognition you don't deserve.

10. C was not standardized at the time this book was written.

11. Shibboleth. And here, you're critiquing writing as a technical
editor when you gave evidence in the prologue that YOU CANNOT WRITE
with coherence or consistency.

12. Genuine errata, but don't break your arm patting yourself on the
back.

13. But, the operation fails if the file does not exist on the disk.
You're showing off. Sit down and shut the **** up. No wonder you
didn't take CS. Your presence would add nothing to the class.

14. Genuine errata. You know, you're not doing so good. Only 2/14 at
this point.

15. "But nor is it required"? A completely illiterate grammatical
solecism. How dare you pretend to be his tech editor? You were offered
a job finding errors. You found a few. Which means you're a
pretentious dweeb.

And furthermore, C should reject all-caps: it would do so if it were a
truly consistent language. But it as a real language in practice it
allows them because of Microsoft's market power. Get used to it.

16. Probably Herb's most serious error, but of the sort which creeps
into most computer books, including yours as you admit.

17. Errata.

18. Errata.

19. Herb is giving practical advice, and you're disrupting the class.

20. The order of evaluation is indeed specified in the variant
behavior of C compilers. The problem is that the standards committee
allowed incompetents like you to pay their way in to pad their resume,
along with thugs from vendors who'd fired their developers, and so,
the serious problems with the adolescent pre and post increment
operators were never fixed and remain to this day.


OK, you identified only 5 errata of the sort that exist in all books
unless the publisher allows the authors to use a system to avoid
errata. And yet you say:

"There are dozens of others, and I'm sure there's an effective
drinking game lurking in this book."

In other words, you Open Source here an Open Season on Schildt based
on your malice. This is civilly actionable libel.

[*] Or not.

Yeah, that.

-s
 
M

Moi

I guess I'm not quite understanding how you load something once and
reuse it -- I mean, where/how does it stick around? -- but the problem
may be that I'm thinking in terms of a typical shell environment, in
which once a process/program ends, its resources are freed, while you
(or whoever) are talking about -- something else.

Someone else -- spinoza1111 maybe -- mentioned TSR, which I guess is how
one would accomplish this in, um, DOS maybe? (an environment I know next
to nothing about), but -- is there a UNIX equivalent? I guess shared
libraries *might* sort of qualify, but isn't the operating system
allowed to remove shared-library code from memory when there are no
processes using it? Or is there a way to keep it around .... (Hm,
maybe explicitly managing "shared memory segments"?)

(Off-topic, but not as badly as some recent posts.)

Okay, off topic, but better than English Literature...

IMO, The main difference between TSR and unix's deamon-processes is
the (lack of) sharing address space.
In DOS, a TSR (or any other program/ "process") could access all memory,
write to video-memory, bulldozer other programs, etcetera.

A shared memory segment or (mapped) shared library comes close, but
the processes that attach to it might see it at different adrresses
in their own address space.
In UNIX, shared memory is also persistent: if no program has it attached,
the shared memory stays intact.
Also I cannot remember having ever seen a process *executing* from shared
memory. Makes no sense, anyway.

I don't know about Windows, but I assume the level of isolation
between processes is equivalent to Unix's.
[ Famous Henry Spencer quote here:
"Those who ignore Unix are doomed to reinvent it. Poorly."
]

AvK
 
B

blmblm

Seebs said:
spinoza1111 <[email protected]> wrote:

[ snip ]
Maybe I'm overlooking something obvious here, but I'm not imagining
how this is possible. I mean, either the code is interpreted,
or it's compiled at *some* point, either as part of startup cost
or -- what?
Well, a typical thing would be, say you want to run the same script hundreds
of times, you'd load the script once and then execute it hundreds of times.
(This is how any performance-oriented implementation of Ruby on Rails will
do it, for instance.)

I guess I'm not quite understanding how you load something once and
reuse it -- I mean, where/how does it stick around? -- but the problem
may be that I'm thinking in terms of a typical shell environment, in
which once a process/program ends, its resources are freed, while you
(or whoever) are talking about -- something else.

Anyone who knows anything about programming knows that a shell
processor can be called through an API.

I don't get the relevance of this comment to the discussion.
Seebach wanted to write a C
program because he thinks he's a programmer. We often see newbies do
this.

[ snip ]
 
B

blmblm

Okay, off topic, but better than English Literature...

IMO, The main difference between TSR and unix's deamon-processes is
the (lack of) sharing address space.
In DOS, a TSR (or any other program/ "process") could access all memory,
write to video-memory, bulldozer other programs, etcetera.

Indeed. I have a nice war story about that, from long ago ....

Perhaps if I say that I call this story "How I Learned the Difference
Between DOS and a Real Operating System", and mention that it involved
a user program that put the machine in a state in which recovery
required power cycling, most people here can more or less imagine
the details without my further cluttering up this newsgroup.
A shared memory segment or (mapped) shared library comes close, but
the processes that attach to it might see it at different adrresses
in their own address space.
In UNIX, shared memory is also persistent: if no program has it attached,
the shared memory stays intact.

Yes, that's what I was thinking.
Also I cannot remember having ever seen a process *executing* from shared
memory. Makes no sense, anyway.

Isn't that more or less how shared libraries work? with the caveat
that the code has to be position-independent?
I don't know about Windows, but I assume the level of isolation
between processes is equivalent to Unix's.
[ Famous Henry Spencer quote here:
"Those who ignore Unix are doomed to reinvent it. Poorly."

:)
 
M

Moi

power cycling, most people here can more or less imagine the details
without my further cluttering up this newsgroup.

Well, at least it is related to programming.

Isn't that more or less how shared libraries work? with the caveat that
the code has to be position-independent?

I am not an expert on loading (and all this is not strictly part of c.l.c),
but my impression is that the loader attaches (a copy of ) the shared lib
into the process's address space, via mmap() or an equivalent function.
I don't know if this takes place at load time, or via a page-fault on
the first reference to a not-present symbol.

The relocation / fix-up of the references has to be done anyway.

But the difference with shared memory (in the Unix sense) is that the
shared library segment will be (can be) wiped from core, once the
reference count drops to zero. (This is *not* the case with SHM)

BTW: not all shared-library "segments" are born equal. Some are actually
cloned upon open, some may be copy-on-write 'd in, etc. But once their
reference count drops to zero they are all kicked out.

HTH,
AvK
 
S

Seebs

Isn't that more or less how shared libraries work? with the caveat
that the code has to be position-independent?

There exists a counterexample. BSD/OS had a dynamic linker with
special hooks for fixed-position mapping of particular shared libraries.
This allowed the C library to be a shared library, but to have a fixed
location so that the usual dynamic linker fixups weren't needed, shaving
a few instructions and cache hits off every call into the C library.

.... But this is a pretty specialized case.

(I did see the post showing Nilges making up crazy theories about why the
wrapper wanted to be a C program, but I really don't see any point in trying
to respond further; so far as I can tell, everyone *else* either understands
what I said or doesn't much care about Unix-like environments.)

-s
 
S

spinoza1111

There exists a counterexample.  BSD/OS had a dynamic linker with
special hooks for fixed-position mapping of particular shared libraries.
This allowed the C library to be a shared library, but to have a fixed
location so that the usual dynamic linker fixups weren't needed, shaving
a few instructions and cache hits off every call into the C library.

... But this is a pretty specialized case.

(I did see the post showing Nilges making up crazy theories about why the
wrapper wanted to be a C program, but I really don't see any point in trying
to respond further; so far as I can tell, everyone *else* either understands
what I said or doesn't much care about Unix-like environments.)

But this proves nothing, here, since the cardinality of "everyone
else" is so small as to be statistically meaningless. Furthermore,
your behavior drives people away. You wind up with a small set of
losers who agree with your twisted beliefs.
 
J

Josh Holland

I really shouldn't reply, but I just have to.

On 2010-04-03 said:
15. "But nor is it required"? A completely illiterate grammatical
solecism. How dare you pretend to be his tech editor? You were offered
a job finding errors. You found a few. Which means you're a
pretentious dweeb.

And furthermore, C should reject all-caps: it would do so if it were a
truly consistent language. But it as a real language in practice it
allows them because of Microsoft's market power. Get used to it.

Firstly, saying "C should reject all-caps" is irrelevant, as there is no
reference implementation for C, as there is for C# or Python (say). For
that matter, the closest thing to a reference implementation on Un*x
platforms, gcc, does reject all caps.

$ cat caps.c
#include <STDIO.H>

int main(int argc, char *argv[])
{
printf("Hello world!\n");
return 0;
}
$ gcc -Wall -Wextra -ansi -pedantic caps.c
caps.c:1:19: error: STDIO.H: No such file or directory
cc1: warnings being treated as errors
caps.c: In function ‘main’:
caps.c:5: error: implicit declaration of function ‘printf’
caps.c:5: error: incompatible implicit declaration of built-in function
‘printf’
caps.c:3: error: unused parameter ‘argc’
caps.c:3: error: unused parameter ‘argv’
$
 
K

Keith Thompson

Josh Holland said:
Firstly, saying "C should reject all-caps" is irrelevant, as there is no
reference implementation for C, as there is for C# or Python (say). For
that matter, the closest thing to a reference implementation on Un*x
platforms, gcc, does reject all caps.

$ cat caps.c
#include <STDIO.H>
[...]

Of course gcc will accept it if there happens to be a file called
"STDIO.H" in the appropriate location. It will probably also accept
it if it happens to be running on a system with a case-insensitive
file system (I'll try that tomorrow if I remember).

The existence or nonexistence of a reference implementation is
irrelevant. The C standard easily *could* have required all C
compilers to reject "#include <STDIO.H>". If it had, then all
conforming C compilers would have to reject it.

I'm not entirely sure how such a requirement could be written, though.
The standard clearly permits "#include <foobar.h>" to refer to some
implementation-defined header identified by the name "foobar.h". For
compilers that support it, "#include <STDIO.H>" does exactly the same
thing. The implementation just happens to define that the name
<STDIO.H> refers to the same header that <stdio.h> refers to.

And presumably
#include "foobar.h"
and
#include "FOOBAR.H"
would refer to the same header file if and only if both names refer to
the same file in the filesystem. If double-quoted header names refer
to file names, imposing case-sensitivity would be, IMHO, absurd.

For compilers on systems with case-insensitive file systems, rejecting
"#include <STDIO.H>" would require a very small amount of extra work.
Defining the rule would require considerably more.

I suppose the simplest rule would be to require lower case for the
standard-defined headers, and leave things as they are for all other
headers. That would help to guard against the creation of
non-portable code that uses "#include <STDIO.H>", which works on some
implementations but fails on others. But I don't think it would
be worth the confusion.

I know you weren't proposing such a change to the standard. I just
wanted to point out that it would be non-trivial.
 
J

Josh Holland

On 2010-04-04 said:
I know you weren't proposing such a change to the standard. I just
wanted to point out that it would be non-trivial.

Sure, if the standard headers are real files on a case-insensitive
filesystems, <STDIO.H> will work. My point was that as soon as someone
who picked up the habit of using caps from C:TCR moves to a filesystem
that does care about case, chances are they'll come a-cropper. Also, I
understand that there is no requirement for the standard headers to be
real files, in which case allowing caps would be extra work.
 

Ask a Question

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

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

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top