twitter: comp.lang.c - 25 new messages in 7 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Killfile troll "Phil Carmody". - 7 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* Is it good to use char instead of int to save memory? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/40bfc7048b74630b?hl=en
* Container library (continued) - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
* Implementing strstr - 8 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
* Idiotic programming style edicts - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* Heavy malloc()/free() load and threads - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/c17799a1c1abfa27?hl=en
* Cryptic Syntax - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/3c0bd77fdf5ec98c?hl=en

==============================================================================
TOPIC: Killfile troll "Phil Carmody".
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================

== 1 of 7 ==
Date: Fri, Mar 19 2010 10:45 pm
From: "Default User"

Branimir Maksimovic wrote:

> On Fri, 19 Mar 2010 23:13:51 +0100
> jacob navia <jacob@nospam.org> wrote:

> > I just don't read what carmody writes, and that is much easier. Why
> > bother?
>
> Exactly! you don;t have to read.

If you never plan to read the posts of a certain person, why not
killfile them?

Brian

== 2 of 7 ==
Date: Sat, Mar 20 2010 12:23 am
From: Branimir Maksimovic

On 20 Mar 2010 05:45:18 GMT
"Default User" <defaultuserbr@yahoo.com> wrote:

> Branimir Maksimovic wrote:
>
> > On Fri, 19 Mar 2010 23:13:51 +0100
> > jacob navia <jacob@nospam.org> wrote:
>
> > > I just don't read what carmody writes, and that is much easier.
> > > Why bother?
> >
> > Exactly! you don;t have to read.
>
> If you never plan to read the posts of a certain person, why not
> killfile them?

I don;t see reason in filterng messages, except that
messages are pure spam and there is no purpose replaying
to them since spamers don;t read other posts anyway
and are not interested in conversation.
So normal posts I read alright ;)

Greets

>
>
>
> Brian

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 3 of 7 ==
Date: Sat, Mar 20 2010 2:27 am
From: Seebs

On 2010-03-20, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> On 20 Mar 2010 05:45:18 GMT
> "Default User" <defaultuserbr@yahoo.com> wrote:
>> If you never plan to read the posts of a certain person, why not
>> killfile them?

> I don;t see reason in filterng messages, except that
> messages are pure spam and there is no purpose replaying

How about "they annoy me and waste my time"? That's why I usually
killfile people.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 4 of 7 ==
Date: Sat, Mar 20 2010 3:35 am
From: Lorenzo Villari

On 20 Mar 2010 09:27:06 GMT
Seebs <usenet-nospam@seebs.net> wrote:

> On 2010-03-20, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> > On 20 Mar 2010 05:45:18 GMT
> > "Default User" <defaultuserbr@yahoo.com> wrote:
> >> If you never plan to read the posts of a certain person, why not
> >> killfile them?
>
> > I don;t see reason in filterng messages, except that
> > messages are pure spam and there is no purpose replaying
>
> How about "they annoy me and waste my time"? That's why I usually
> killfile people.
>

In rare occasions even some annoying people post interesting things
(to a certain degree), that's why I never killfile people...

== 5 of 7 ==
Date: Sat, Mar 20 2010 3:43 am
From: Dr Malcolm McLean

On 19 Mar, 22:09, Ian Collins <ian-n...@hotmail.com> wrote:
>
> Good, use the best tool for the job.
>
No. Introduce another language only if the case for it is
overwhelming.

== 6 of 7 ==
Date: Sat, Mar 20 2010 3:51 am
From: Ian Collins

On 03/20/10 11:43 PM, Dr Malcolm McLean wrote:
> On 19 Mar, 22:09, Ian Collins<ian-n...@hotmail.com> wrote:
>>
>> Good, use the best tool for the job.
>>
> No. Introduce another language only if the case for it is
> overwhelming.

What do you mean by "Introduce another language"?

If I have to write a web application, I use PHP and JavaScript. Should
I use C?

If I have to automate a system administration task, I use bash or ksh.
Should I use C?

There's always an appropriate tool for a job.

--
Ian Collins

== 7 of 7 ==
Date: Sat, Mar 20 2010 4:09 am
From: Seebs

On 2010-03-20, Lorenzo Villari <vlllnz@tiscali.it> wrote:
> On 20 Mar 2010 09:27:06 GMT
> Seebs <usenet-nospam@seebs.net> wrote:
>> How about "they annoy me and waste my time"? That's why I usually
>> killfile people.

> In rare occasions even some annoying people post interesting things
> (to a certain degree), that's why I never killfile people...

If I read enough conspiracy-theorist web sites, I'll eventually encounter
a fact. This doesn't mean it's a good use of my time.

If I had infinite time, I would not use a killfile.

==============================================================================
TOPIC: Is it good to use char instead of int to save memory?
http://groups.google.com/group/comp.lang.c/t/40bfc7048b74630b?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 20 2010 12:21 am
From: Dr Malcolm McLean

On 19 Mar, 20:34, Flash Gordon <s...@spam.causeway.com> wrote:
>
> Then you have a new requirement which needs another 29 bytes and your
> shafted. This *does* happen, and I've been the one to tell the
> management that what they thought was a simple and profitable mod would
> actually mean major work. As far as I'm aware it meant the job had to be
> turned down, so it cost the company money. It was not my code!
>
> Also, on military projects it certainly used to be the case that there
> was a written requirement for 50% free capacity specifically to allow
> for later enhancements, because it is very common for things to be upgraded.
>
> So if you are working on a very limited resource project, you do *not*
> go wasting the resources!
>
Alternatively the new requirements could make some of those 8-bit ints
go over 255.
The rules of (micro) optimisation
a) Don't do it.
b) Don't do it yet.

== 2 of 2 ==
Date: Sat, Mar 20 2010 2:38 am
From: Nick <3-nospam@temporary-address.org.uk>

Lew Pitcher <lpitcher@teksavvy.com> writes:

> I think that Prof Craver is suggesting something like
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char *argv[])
> {
> if (argc > 2)
> printf(argv[1]); /* maybe Bang! you're dead! */
>
> return EXIT_SUCCESS;
> }
>
> where the program code uses an unedited string as the format string for a
> printf() call. This will work successfully (the printf() will generate
> proper printable results, and will return a valid returnvalue) most of the
> time, *but* will fail (won't generate proper printable results, may cause a
> program abend or other unrecoverable error, may cause printf() not to
> return a valid returnvalue) if the string contains a valid print specifier
> escape sequence.

I saw just the opposite yesterday - a Windows pop-up box which contained
a literal "%s" in it where you'd expect some more useful information.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 20 2010 12:37 am
From: jacob navia

ng2010 a écrit :
> "jacob navia" <jacob@spamsink.net> wrote in message
> news:hnr08l$1ev$1@speranza.aioe.org...
>> Seebs a écrit :
>>> On 2010-03-17, jacob navia <jacob@nospam.org> wrote:
>>>> You misunderstand. I am not trying to invent a new way of doing
>>>> those things. I am trying to invent a generalized standard way
>>>> of doing that in C. This has never been done before for C.
>>> It's been done repeatedly, except for the "standard" part.
>>>
>>> I honestly don't think that generalizing to "container" is going to be
>>> useful in C. In a language that doesn't have meaningful inheritance,
>>> it's very unusual for this kind of approach to get widespread
>>> adoption.
>>
>> I do not know of any other attempt in C.
>>
>> Inheritance is not necessary at all. The code works without it.
>
> Jacob: Do you even know C++? Because it sounds like you are burying your
> head in the sand and doing wishful thinking and hoping that others would
> believe and follow you, but the fact of the matter is that you are the
> only one who wants to put lipstick on a pig!

Why?

You are misunderstanding me. I do not want to use C++!

> Eventually, all the old iron
> of detroit will be gone, rusted away. So will C rust away.

The usage of C is not decreasing but increasing. Big and important
projects like the linux kernel, Apache, and many others are written
in C. The folks in C++ have been yelling this for ages now and
the usage of C doesn't disminish at all.

They believe that throwing ad hoc complexity at problems is the solution
to everything. No, it is not. C++ has become such a monster of
complexity that not even the creator of the language is able to add
a new feature, after years of trying. ("concepts" anyone?)

> "A few" still
> drive around the old cars, but they are still deathtraps and old,
> obsolete technology.

Because you believe that more complexity is better. Go on. I believe that
the future belongs to SIMPLER languages.

What I want to do is participate to the evolution of C. This group is about
that. Note that you have comp.lang.c++ to discuss your stuff. Coming here
trolling about how C is a piece of crap is simply acknowledging that it
scares you if C would continue its own development. You, and all those
C++ zealots try to destroy C because deep in their minds they are afraid
that people realize that what is important in a language is simplicity
and power, not complexity.

== 2 of 2 ==
Date: Sat, Mar 20 2010 3:44 am
From: Lorenzo Villari

On Fri, 19 Mar 2010 21:56:54 -0500
"ng2010" <ng2010@att.invalid> wrote:

>
> "Andrew Poelstra" <apoelstra@localhost.localdomain> wrote in message
> news:slrnhq24u8.ls9.apoelstra@localhost.localdomain...
>
> > You can do OO in C. I think most people don't because they have
> > it drilled into their heads that "C is not an object-oriented"
> > language. Which to be fair, it isn't, but that doesn't mean that
> > there are reasonably-elegant[1] ways to do OO.
>
> Your opinion of "reasonably elegant" is just that: an opinion.
> Apparently Navia is willing to make the concessions necessary also.
> It is simply not necessary to keep hitting one's self in the head
> with a hammer. OO and C can never be "elegant". I think maybe Navia's
> problem is (as is my own) that the compiler black box is just that: a
> black box! If you start with a C compiler, then you end up trying to
> escape C by extending it and the complex compiler you started with.
> It is an error of entry. The way to go is to start with a clean
> slate. No baggage, no pain (from that hammer hitting you on the
> head). It's sad to see him spinning his wheels and not getting
> anywhere because he is stuck in the mud of C.
>

Redefine the term "elegant" and maybe, we could agree. Different people
have different meanings for that I think. I believe some, not so
horrible, OO in C could be done...

==============================================================================
TOPIC: Implementing strstr
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
==============================================================================

== 1 of 8 ==
Date: Sat, Mar 20 2010 12:39 am
From: Dr Malcolm McLean

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;
}

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.

== 2 of 8 ==
Date: Sat, Mar 20 2010 1:30 am
From: spinoza1111

On Mar 20, 3:39 pm, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> 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;
>
> }
>
> 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.

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.

== 3 of 8 ==
Date: Sat, Mar 20 2010 1:53 am
From: 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>

// ***************************************************************
// * *
// * 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 *
// * *
// * *
// * ----------------------------------------------------------- *
// * *
// * 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; // 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", ""));
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;
}

== 4 of 8 ==
Date: Sat, Mar 20 2010 2:25 am
From: Seebs

On 2010-03-20, Dr Malcolm McLean <malcolm.mclean5@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
have concluded that it's simply not worth trying to explain his bugs
to him.

== 5 of 8 ==
Date: Sat, Mar 20 2010 2:50 am
From: spinoza1111

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).
>
> /*
> 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.

== 6 of 8 ==
Date: Sat, Mar 20 2010 3:27 am
From: Nick <3-nospam@temporary-address.org.uk>

Dr Malcolm McLean <malcolm.mclean5@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.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 7 of 8 ==
Date: Sat, Mar 20 2010 3:40 am
From: Dr Malcolm McLean

On 20 Mar, 10:27, Nick <3-nos...@temporary-address.org.uk> wrote:
> 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.
>
This one won't work, strcmp("Fred is dead", "Fred") returns non-zero.
You need strncmp, which entails a call to strlen() to get the length
of the pattern.

== 8 of 8 ==
Date: Sat, Mar 20 2010 4:40 am
From: Nick <3-nospam@temporary-address.org.uk>

Dr Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On 20 Mar, 10:27, Nick <3-nos...@temporary-address.org.uk> wrote:
>> 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.
>>
> This one won't work, strcmp("Fred is dead", "Fred") returns non-zero.
> You need strncmp, which entails a call to strlen() to get the length
> of the pattern.

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.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Mar 20 2010 12:52 am
From: Ian Bush

On 19 Mar, 23:40, "bartc" <ba...@freeuk.com> wrote:
>
> There must, surely, be a simpler, more elegant way of declaring an int or
> float of a particular width.
>
> (Fortran used to allow:
>
> integer*4
>

Errrr, no. Very common extension but never standard.

Fortran now, i.e. for the last 20 years, has parameterized types which
allows
you to ask for a minimum range and, for floating point types,
precision, but
no way of asking for a particular width,

Ian

== 2 of 3 ==
Date: Sat, Mar 20 2010 1:02 am
From: Jonathan de Boyne Pollard

>
>
> Buried deep in a project, I wrote the following code:
> len = strlen(foo);
> free(foo);
> memcpy(bar, foo, len);
>
> Now, just about anyone can tell you that this, while technically
> wrong, is virtually guaranteed to be harmless in practice — there's
> simply nothing there to reuse the space after the free.
>
I wouldn't be one of the people giving such a guarantee. In several of
the implementations that I'm familiar with, there exists the
possibility, if the string is longer than a page, that deallocating the
storage will cause one or more pages that formed part (or all) of the
string to be decommitted by the C library's heap management, resulting
in an access to decommitted page fault at the point of memcpy(). Even
for strings shorter than a page, there exists the possibility that free
block consolidation would result in the whole page containing the string
becoming free, and hence being decommitted.

== 3 of 3 ==
Date: Sat, Mar 20 2010 2:21 am
From: Seebs

On 2010-03-20, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote:
>> len = strlen(foo);
>> free(foo);
>> memcpy(bar, foo, len);

>> Now, just about anyone can tell you that this, while technically
>> wrong, is virtually guaranteed to be harmless in practice � there's
>> simply nothing there to reuse the space after the free.

> I wouldn't be one of the people giving such a guarantee. In several of
> the implementations that I'm familiar with, there exists the
> possibility, if the string is longer than a page, that deallocating the
> storage will cause one or more pages that formed part (or all) of the
> string to be decommitted by the C library's heap management, resulting
> in an access to decommitted page fault at the point of memcpy(). Even
> for strings shorter than a page, there exists the possibility that free
> block consolidation would result in the whole page containing the string
> becoming free, and hence being decommitted.

Yes. If it had segfaulted, I would not have been at all surprised.

Getting a perfectly valid string, which happened to be a different
but reasonably recently used and relevant, surprised me a lot.

==============================================================================
TOPIC: Heavy malloc()/free() load and threads
http://groups.google.com/group/comp.lang.c/t/c17799a1c1abfa27?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 20 2010 12:59 am
From: Jonathan de Boyne Pollard

However, I wouldn't want all the dozens of apps on my
desktop to all refuse to return memory back to the system just because
they might want it again at some point in the future (thus
unnecessarily forcing swapping to disk or a memory upgrade). Unless
there is a very specific reason to think that performance is critical,
my personal view is that it's polite for a userspace app to return
memory back to the underlying system whenever it is reasonably possible.

malloc may or may not return memory to the
system. Usually, it won't, except in fringe cases (eg 'large
allocations' done via mmap). Memory allocations which
originally happened by calling brk/sbrk
cannot easily be returned to the system, anyway, only if freeing them
happens to release a chunk of memory just below the current break.

On the contrary, usually it will. I'm revising my estimate of the
quality of your "50 — 300 lines of code" implementation downwards
as a result of this statement, because you are erroneously conflating
allocating address space with committing pages. Most implementations
that I am familiar with were written by people that didn't make this
mistake.

My implementation (more correctly, one of my implementations (-:)
calls the OS/2 DosSetMem() function to commit partially
used pages and de-commit wholly unused pages within the heap arena as
necessary. Several Win32 implementations that I'm aware of call VirtualAlloc()
to commit and de-commit pages within arenas. (For a good explanation
of this process, see Matt Pietrek's dissection of the DOS-Windows 9x HeapAlloc()
function in his _Windows 95 System Programming Secrets_ book.)
The GNU C library version 2.11.1 calls madvise() with the
MADV_DONTNEED flag for wholly unused pages.

The OS/2 and Win32 implementations are returning unused heap memory
to the operating system as a matter of course. The GNU C library is
intending to do the same, and is doing the best that it can with the
more limited system API that it has to work with, and the operating
system bugs that it has to cope with. (See, for example, Linux kernel
bug #6282 <http://bugzilla.kernel.org./show_bug.cgi?id=6282>, reported by Samuel Thibault in 2007.)

== 2 of 2 ==
Date: Sat, Mar 20 2010 1:27 am
From: Ian Collins

On 03/20/10 08:59 PM, Jonathan de Boyne Pollard wrote:

Please stop cross-posting to so many groups and worse still, snipping
attributions.

--
Ian Collins

==============================================================================
TOPIC: Cryptic Syntax
http://groups.google.com/group/comp.lang.c/t/3c0bd77fdf5ec98c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 1:10 am
From: Dr Malcolm McLean

On 20 Mar, 03:01, WD <liamym...@yahoo.com> wrote:
>
> z is declared as an int, not a pointer, and it really works as I
> described. After creating a program in memory (like a compiler, only
> no executable is written to disk) it appears that the return statement
> somehow invokes the compiled (in memory) program. The full program
> compiles with gcc and runs in the Linux environment, if that somehow
> makes a difference.
>
The program will assemble the machine code at an absolute address
which it holds in the integer z. It then has to fool the C compiler
into thinking that this is a C-language function, and make it call it.
Hence the funny syntax. There might be sme other trickery going on at
address z to make the whole thing work.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Saturday, March 20, 2010

comp.lang.c - 25 new messages in 7 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts