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

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

comp.lang.c@googlegroups.com

Today's topics:

* calling a singly-linked list - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/163ef25eec8f0a79?hl=en
* A bit resistant to disruption - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
* Warning to newbies - 15 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
* Missing braces around {0} initializer?! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en
* SMTP Client - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fd5e81482c2e8dd1?hl=en
* Motivation of software professionals - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en

==============================================================================
TOPIC: calling a singly-linked list
http://groups.google.com/group/comp.lang.c/t/163ef25eec8f0a79?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 9 2010 12:06 am
From: Nick Keighley

On 9 Feb, 07:57, Richard Heathfield <r...@see.sig.invalid> wrote:
> Phred Phungus wrote:

> > I think the classification for what is a singly-linked list must be
> > fairly broad. In this, there aren't new nodes created dynamically.
>
> ['this' is an illustration of the linked-list concept that uses an array
> as the container]
>
> Right. The concept of "linked list" depends purely on each item having a
> link to some other item (or items) in the list so that a logical linear
> progression exists. There's nothing in the rules that says the links
> have to be pointers, or that the list has to be capable of arbitrary
> expansion, or anything else.

I learnt my data structures by "emulating" pointers with indexes into
large arrays. This was because the language used didn't have pointers.
In fact I wasn't even aware that this *was* a pointer emulation as I
didn't know about pointers either. I don't think it did me much harm
as far as learning about data structures and algorithms went.

> As far as the *concept* is concerned,
> that's fluff. Highly important and significant fluff from a practical
> point of view, but fluff nonetheless from the perspective of what
> actually constitutes a linked list.
>
> You have probably already noted that, in your source text, the author of
> your example points out that the array implementation is "naive", and
> shortly moves on to present pointer-based lists.

== 2 of 3 ==
Date: Tues, Feb 9 2010 12:17 am
From: Nick Keighley

On 9 Feb, 06:33, Phred Phungus <Ph...@example.invalid> wrote:
> Alan Curry wrote:
> > In article <7ta771Ffi...@mid.individual.net>,
> > Phred Phungus <Ph...@example.invalid> wrote:

> > |#include <stdio.h>
> > |#include <stdlib.h>
> > |
> > |struct list {
> > | struct list *next;
> > | int n;
> > |};
> > |
> > |static int *read_numbers(struct list *list)
>
> > This code, which I posted in another thread, should not be used.

Note well... "should not be used"

> > It was a
> > response to a "challenge" and should be considered mainly as a joke. It does
> > technically do everything the challenge requested, while being useless for
> > any practical purpose.

"useless for any practical purpose"

<snip>

> You mentioned passing a counter to a recursive function.
>
> I didn't see a better posting than yours, and now it's Feb. 9 east of
> Chicago.

better for what? What are you trying to do? It's Feb 9 east of London
as well.

<snip>

> I'm having trouble hooking up data structures with a platform and
> extensions that are somewhat new to me.

data structures are pretty independent of platform extensions (or
should be). Are you learning data structures or platform extensions?
I'd try to learn one at a time.

> So I look for simpler toy programs that do something similar.

simpler than what? similar to what?

> It's not hard to mistake differing forms of lists.

mistake for what? Differing in what way?

> I was hoping to do
> something with this from Unleashed:

what's something?

> //c11_022.c - naive single linked list, using an array.
> #include <stdio.h>
>
> typedef struct ITEM
> {
> char Title[30];
> char Author[30];
> int Next;
>
> } ITEM;
>
> int main(void)
> {
> ITEM List[] =
> {
> {"UNIX Unleashed", "Burk and Horvath", 2},
[...]
{"Expert C Programming", "van der Linden", -1},
> };
>
> int Current = 0;
>
> while(Current != -1)
> {
> printf("Read %s, by %s.\n",
> List[Current].Title,
> List[Current].Author);
> Current = List[Current].Next;
> }
>
> return 0;
>
> }
>
> // gcc -D_GNU_SOURCE -Wall -Wextra ll1.c -o out
>
> I think the classification for what is a singly-linked list must be
> fairly broad. In this, there aren't new nodes created dynamically.

not a necessisity of link lists. But in practice a major reason for
using linked lists is their easy extensibility.

I think you need a goal (or if you have one, you need to articulate
it!)

--
"XML is isomorphic to the subset of Lisp data
where the first item in a list is required to be atomic."
John McCarthy

== 3 of 3 ==
Date: Tues, Feb 9 2010 12:36 am
From: Keith Thompson

Phred Phungus <Phred@example.invalid> writes:
> In the following program:
>
> dan@dan-desktop:~/source/unleashed/ch11$ gcc -D_GNU_SOURCE -Wall
> -Wextra ac1.c -o out
[snip]

Elsewhere in this thread, frank <frank@example.invalid> writes:
[...]
> dan@dan-desktop:~/source/unleashed/ch11$ gcc -D_GNU_SOURCE -Wall
> -Wextra ac2.c -o out
[snip]

Either you're posting here under two different names, "Phred Phungus"
and "frank", or we have a remarkable coincidence.

In the interests of coherent communication, please post under just one
name. It doesn't have to be your real one, just consistent.

Thanks.

--
Keith Thompson (The_Other_Keith) kst-u@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"

==============================================================================
TOPIC: A bit resistant to disruption
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Feb 9 2010 12:11 am
From: Francois Grieu

Seebs wrote:
> On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
>> You are the first poster with a proposition that I won't contradict, and
>> are so far untouched by the "at least one public change of mind" curse!
>
> The tricky part, so far as I can tell, is that we can't tell what a
> partially-written bit might look like. On the other hand, in theory,
> only one write can be interrupted, as I understand it.

Only one write can be interrupted. But a series of disruptions can lead
to multiple partially-written cells. See below.

>
> Hmm.
>
> Okay, here's an approach. Imagine without loss of generality that our
> goal is to toggle the bit in cell 0, and that we have additional bits to
> toggle. The bit is "T".
>
> Let's see. Okay, when toggle() is called, we'll start by clearing a working
> area. So we have some unspecified number of bits which is our working area,
> call them W[0] ... W[N].
>
> The first thing we need to do is be sure that we can recover the previous
> value in the event of a disruption. So, necessarily, we need a bit to hold
> the known-previous-value. Let's call that W0. But how do we know whether
> W0 holds a bit we care about? We need a flag for whether W0 has been written.
> Let's call that W1. So, read() should do something like:
> if (W1)
> return W0
> else
> return T
>
> What about toggle()? If W1 is set, then it was interrupted during an
> operation. It should try to extract the value from W0 and push it back
> into T. Once it has done that, it can clear W1 (because it no longer
> needs to be able to remember the value in W0), then W0. That reduces us
> to the default state, which is that T holds the current bit and we wish
> to toggle it.
>
> Given that, we then:
> * Copy T into W0
> * Set W1
> * Erase T
> * if T was previously 0, program T
> * erase W1
> * erase W0
>
> The rationale of this ordering is that, at every time:
> * if W1 is set, W0 holds the correct value of T
> * if W1 is unset, T is known to be correct
>
> If we are interrupted while setting W1, we were interrupted before we modified
> T, so that's not a problem -- T is still at its correct old value. If we
> are interrupted while setting W0, we were interrupted before we set W1, so
> that's not a problem -- T is still at its correct old value. If we are
> interrupted during any of the erasing or programming of T, that's not a
> problem -- W0 and W1 are set, so we'll pick up the right value next time
> we come in. If we are interrupted during the erase of W1, that's fine. If
> it gets erased, it's clear and T has the right value. If it doesn't get
> erased, it's still set, and W0 still holds the correct "previous value",
> so we'll be in one of the trustworthy intermediate states.
>
> So I think that's it.
>
> So!
>
> // Read a designated EEPROM cell; always returns 0 or 1.
> extern int eRead(int j);
> // Erase a designated EEPROM cell.
> // After undisrupted eErase, eRead returns 0 until eProgram is invoked.
> extern void eErase(int j);
> // Program a designated *ERASED* EEPROM cell.
> // After undisrupted eProgram, eRead returns 1 until eErase is invoked.
> // Programming a cell that is not erased cause undefined behavior.
> extern void eProgram(int j);
>
> /* default state:
> * bit 0 holds the current Durable Bit
> * bit 1 is undefined
> * bit 2 is clear
> *
> * during a toggle:
> * bit 2 is set
> * bit 1 holds the current Durable Bit
> * bit 0 is undefined.
> *
> */
>
> int
> bRead(void) {
> if (eRead(2)) {
> return eRead(1);
> } else {
> return eRead(0);
> }
> }
>
> void
> bToggle(void) {
> int t;
> if (eRead(2)) {
> t = eRead(1);
> eErase(0);
> if (t)
> eProgram(0); // [B]
> eErase(2); // [A]
> }
> t = eRead(0);
> eErase(1);
> if (t)
> eProgram(1);
> eProgram(2);
> eErase(0);
> if (!t)
> eProgram(0);
> eErase(2);
> }
>
> I realized on consideration that I don't need to finish this with
> eErase(1), because bit 1 is undefined. Thus, if eErase(2) completes
> at the end of bToggle(), the toggle is complete and bit 0 holds the
> newly toggled bit. If it doesn't complete, 1 still holds the right
> value.
>
> Note that there exists at least one case (previous value was zero, and
> a disruption occurred) where 0 is erased twice without having been
> programmed.

This one is incorrect. Assume a disruption where I inserted [A]; now
cell 2 is uncertain. Assume cell 2 is read as 1 during the next bToggle,
and a disruption occurs at [B]; now cells 0 and 2 are uncertain, and
bRead can return 0 (if cells 2 and 0 are read as 0) or 1 (if cell 2 is
read as 0 and cell 0 is read as 1).

Hint: there's nothing to prevent bRead from invoking eErase or/and eProgram.

Francois Grieu

== 2 of 4 ==
Date: Tues, Feb 9 2010 12:16 am
From: Seebs

On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
>> void
>> bToggle(void) {
>> int t;
>> if (eRead(2)) {
>> t = eRead(1);
>> eErase(0);
>> if (t)
>> eProgram(0); // [B]
>> eErase(2); // [A]
>> }
>> t = eRead(0);
>> eErase(1);
>> if (t)
>> eProgram(1);
>> eProgram(2);
>> eErase(0);
>> if (!t)
>> eProgram(0);
>> eErase(2);
>> }

> This one is incorrect. Assume a disruption where I inserted [A]; now
> cell 2 is uncertain. Assume cell 2 is read as 1 during the next bToggle,
> and a disruption occurs at [B]; now cells 0 and 2 are uncertain, and
> bRead can return 0 (if cells 2 and 0 are read as 0) or 1 (if cell 2 is
> read as 0 and cell 0 is read as 1).

Okay, I misunderstood the spec. I thought that an erase necessarily
either worked or failed to work, and couldn't leave a cell indeterminate.
Re-reading the spec, I see that isn't correct. That does make this a
lot trickier.

> Hint: there's nothing to prevent bRead from invoking eErase or/and eProgram.

True. I'm not sure how it matters, though; a hypothetical user can just run
bToggle() over and over without ever hitting bRead(), so I can't usefully
rely on anything it does, I don't think. I'm assuming this has to work
in the general case, not just in the specific example case given.

I suspect this could be solved with another bit, but I'm too sleepy to figure
out how right now.

-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!

== 3 of 4 ==
Date: Tues, Feb 9 2010 1:10 am
From: Francois Grieu

Seebs wrote:
> On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
>>> void
>>> bToggle(void) {
>>> int t;
>>> if (eRead(2)) {
>>> t = eRead(1);
>>> eErase(0);
>>> if (t)
>>> eProgram(0); // [B]
>>> eErase(2); // [A]
>>> }
>>> t = eRead(0);
>>> eErase(1);
>>> if (t)
>>> eProgram(1);
>>> eProgram(2);
>>> eErase(0);
>>> if (!t)
>>> eProgram(0);
>>> eErase(2);
>>> }
>
>> This one is incorrect. Assume a disruption where I inserted [A]; now
>> cell 2 is uncertain. Assume cell 2 is read as 1 during the next bToggle,
>> and a disruption occurs at [B]; now cells 0 and 2 are uncertain, and
>> bRead can return 0 (if cells 2 and 0 are read as 0) or 1 (if cell 2 is
>> read as 0 and cell 0 is read as 1).
>
> Okay, I misunderstood the spec. I thought that an erase necessarily
> either worked or failed to work, and couldn't leave a cell indeterminate.
> Re-reading the spec, I see that isn't correct. That does make this a
> lot trickier.
>
>> Hint: there's nothing to prevent bRead from invoking eErase or/and eProgram.
>
> True. I'm not sure how it matters, though; a hypothetical user can just run
> bToggle() over and over without ever hitting bRead(), so I can't usefully
> rely on anything it does, I don't think.

Notice that after one (or several) disrupted bToggle(), the next
undisrupted bRead() can return anything. One attractive option is thus
that this undisrupted bRead() does cleanup so that the next undisrupted
bRead() will return the right value.

> I'm assuming this has to work
> in the general case, not just in the specific example case given.

Yes. But if you can make some bRead()/bToggle() that work in my use
case, it is easy to exhibit a fully correct bRead()/bToggle2(): just define

void bToggle2(void )
{
(void) bRead();
bToggle();
}

The proof is left as a relatively easy exercise to the reader.

> I suspect this could be solved with another bit, but I'm too sleepy to figure
> out how right now.

Good night..

Francois Grieu

== 4 of 4 ==
Date: Tues, Feb 9 2010 1:28 am
From: Seebs

On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
>> // Read a designated EEPROM cell; always returns 0 or 1.
>> extern int eRead(int j);
>> // Erase a designated EEPROM cell.
>> // After undisrupted eErase, eRead returns 0 until eProgram is invoked.
>> extern void eErase(int j);
>> // Program a designated *ERASED* EEPROM cell.
>> // After undisrupted eProgram, eRead returns 1 until eErase is invoked.
>> // Programming a cell that is not erased cause undefined behavior.
>> extern void eProgram(int j);

[re: my first attempt]
> This one is incorrect. Assume a disruption where I inserted [A]; now
> cell 2 is uncertain. Assume cell 2 is read as 1 during the next bToggle,
> and a disruption occurs at [B]; now cells 0 and 2 are uncertain, and
> bRead can return 0 (if cells 2 and 0 are read as 0) or 1 (if cell 2 is
> read as 0 and cell 0 is read as 1).
>
> Hint: there's nothing to prevent bRead from invoking eErase or/and eProgram.

I get it! The risk here is that if eRead() returns unreliable results,
future queries of the same bit may not yield the same results, resulting
in inconsistent flow through the program logic; in particular, attempts
might be made to modify things based on spurious data.

So.

int
bSureOf(int j) {
if (eRead(j)) {
eErase(j);
eProgram(j);
return 1;
} else {
eErase(j);
return 0;
}
}

int
bRead(void) {
if (bSureOf(2)) {
return eRead(1);
} else {
return eRead(0);
}
}

void
bToggle(void) {
int t;
if (bSureOf(2)) {
t = eRead(1);
eErase(0);
if (t)
eProgram(0);
eErase(2);
}
t = eRead(0);
eErase(1);
if (t)
eProgram(1);
eProgram(2);
eErase(0);
if (!t)
eProgram(0);
eErase(2);
}

We start with all bits clear. bSureOf(2) erases 2, just to be cautious,
but returns 0. We read a bit. We erase bit 1 (also clear at the moment,
but who cares), and don't program it. So far, nothing has been changed.
At this point, we start trying to write 2. If this is interrupted, two
possibilities exist:

1. The attempted read in the next hit of bSureOf() comes up 0; we
forcibly erase bit 2, and trust bit 0, which was correct.
2. The attempted read in the next hit of bSureOf() comes up 1; we
forcibly erase-and-write bit 2, and trust bit 1, which was correct.

Either way, if we get past any check on bit 2, we have a
correct and consistent state. Thus, eventually we come to the eErase(0),
which occurs only when bit 2 is definitely known to be set to 1. We now
try to set bit 0 to its new value. Once that happens, we try to clear
bit 2. If we succeed, all is well -- bit 2 is clear, bit 0 is the toggled
state. If we are interrupted, one of two things can happen on the next
read:

1. The attempted read in bSureOf(2) comes up 0; we forcibly erase
bit 2, and we continue to use the new, toggled, state of bit 0. Our
behavior is consistent.

2. The attempted read in bSureOf(2) comes up 1; we try to write bit
2, and if we succeed, we fall back on the not-yet-toggled state of bit
1. Since the toggle was interrupted, this behavior is acceptable.

3. The attempted read in bSureOf(2) comes up 1; we try to write bit
2, but are interrupted somewhere during it. It is still ambiguous whether
the toggle has succeeded, but no matter what happens, if bRead() returns,
we will have either toggled or failed to toggle the bit.

If bit 2 is set, then bit 1 has definitely been set to the most recently
returned value. (It is possible that we've since tried to store a toggled
value in bit 0, but if we were interrupted, we haven't returned it so we
don't need to show that new value yet.) If bit 2 is not set, then bit 0
definitely holds either the last returned value, or the most recently toggled
value. Either way, before we return, we commit to bit 2's perceived state.
If that is interrupted, that's okay -- eRead() doesn't return a value, because
it was disrupted, so we haven't returned a wrong value.

... I think.

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 15 ==
Date: Tues, Feb 9 2010 12:19 am
From: "io_x"

"spinoza1111" <spinoza1111@yahoo.com> ha scritto nel messaggio
news:5d3da187-7fb4-4325-9513-6e6ef2a2b23c@a16g2000pre.googlegroups.com...
On Feb 6, 11:34 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 5, 5:30 pm, Seebs <usenet-nos...@seebs.net> wrote:
One way would be to use a macro to handle this, but the need shows us
that your basic "two pass" method is just not right. Coding the
solution as a general replace() function causes us to ask why this
cannot be done in less than two passes...perhaps one and one half

#replace is not the answer for the original problem
#it can not handle every possible substitution
#instead
#using %s like place where has to be substitution
#and "%%" --> "%" is ok
#example
#in w="This is string sub %%s %s" with s="Sub"
#has answer g="This is string sub %s Sub"
#
#with replace it has answer
#"This is string sub %Sub Sub"
#and never like g string

#the not replace case is cover from
#w="This is string sub %%%s %s" with s="Sub"

passes, as in the linked list, or, if storage is cheap, one pass
followed by freeing the storage acquired in our worst case malloc.

However, the most storage-elegant solution would be to create a linked
list of all sequences that do not contain %s (in the specialized
version) or the string to be replaced (in a generalized replace).

== 2 of 15 ==
Date: Tues, Feb 9 2010 12:23 am
From: Nick Keighley

On 8 Feb, 10:57, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <be01b0e7-bfca-44fa-a9ce-ffc3e3582...@f17g2000prh.googlegroups.com>,
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 4, 9:22 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:

<snip>

> > > Where's the bragging or boasting here?
>
> > It's in the fact that he's unqualified,
>
> I don't agree with you that this is an established fact.

it's really not worth engaging spinoza on subjects he has a bee in his
bonnet about. You just chew your time up for no purpose (unless, of
course you find him entertaining).

<snip>

== 3 of 15 ==
Date: Tues, Feb 9 2010 12:24 am
From: Nick Keighley

On 8 Feb, 17:34, Seebs <usenet-nos...@seebs.net> wrote:

> (Usually,
> humor has to surprise, but as anyone who has ever watched a Charlie Chaplin
> routine can tell you, you can be just as funny with a completely predictable
> failure mode.)

I never thought he was funny.

== 4 of 15 ==
Date: Tues, Feb 9 2010 12:25 am
From: Seebs

On 2010-02-09, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On 8 Feb, 17:34, Seebs <usenet-nos...@seebs.net> wrote:
>> (Usually,
>> humor has to surprise, but as anyone who has ever watched a Charlie Chaplin
>> routine can tell you, you can be just as funny with a completely predictable
>> failure mode.)

> I never thought he was funny.

He's not funny-to-everyone, but he's certainly funny-to-many-people, despite
a great deal of predictability in the routines.

== 5 of 15 ==
Date: Tues, Feb 9 2010 12:30 am
From: Richard Heathfield

Seebs wrote:
> On 2010-02-09, Richard Heathfield <rjh@see.sig.invalid> wrote:
<snip>
>
>>> Santosh and Ike Naar found problems which I fixed in a few hours on
>>> Sunday.
>
>> And I found a problem that took you several hours to fix all by itself.
>> Deleting a single line can be terribly, terribly, difficult, can't it?
>
> More importantly, why on earth would it take "a few hours" to fix something
> this simple?

Think about it. It takes him several hours to delete a single line.

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

== 6 of 15 ==
Date: Tues, Feb 9 2010 12:30 am
From: Seebs

On 2010-02-09, Richard Heathfield <rjh@see.sig.invalid> wrote:
> Seebs wrote:
>> More importantly, why on earth would it take "a few hours" to fix something
>> this simple?

> Think about it. It takes him several hours to delete a single line.

That's not quite the same. He didn't understand the criticism, and while
that's sad, it is an explanation for why it would take a while -- he wasn't
actually *working* on it during that time, he just didn't understand the
problem description.

By contrast, with the other parts, he clearly had a pretty good idea of what
the problems were, but it nonetheless took him several hours to debug
something that I'd expect most people who had even a vague comprehension
of pointers could write from *scratch* and debug in that kind of time.

His design is crap, of course, but was it really THAT hard to debug? Was
that time just lost to the idiotic naming conventions, or to the baroque
design, or what?

== 7 of 15 ==
Date: Tues, Feb 9 2010 12:47 am
From: spinoza1111

On Feb 8, 6:59 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <b6e7fd1e-ebc3-4680-81ec-32e19d596...@s36g2000prh.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > <92466eb6-1b99-44eb-92b2-617118d42...@j31g2000yqa.googlegroups.com>,
> > On Feb 6, 7:11 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <92466eb6-1b99-44eb-92b2-617118d42...@j31g2000yqa.googlegroups.com>,
> > > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
> [ snip ]
>
> > > > > as may Dijsktra's memory; we badly need a solid
> > > > > scientific biography of Dijkstra for the general reader, since so few
> > > > > people outside the field know of his contributions.
>
> > > And the ones inside the field seem to mainly know him as the inventor
> > > of a particular graph algorithm. :-(
>
> > > Interesting guy, as best I can tell, and/but a bit eccentric.
>
> > God, I hate that word, "eccentric". Its use normalizes deviance.
>
> Propose a better one. (I'm mildly curious about what "normalizes
> deviance" means in context, but not optimistic that an attempt to
> clarify would help. <shrug>)

It is a term of art developed by the engineering anthropologist Diane
Vaughan to describe predominantly male technical groups that find ways
of "normalizing" deviations from standards and rules "in order to get
a job done".

She developed it in a groundbreaking study of the 1986 "let's kill a
teacher" Challenger mission, doing a detailed study of the physics of
the O-ring assembly that failed in that launch.

In reviewing the transcript of the meeting at the O-ring subcontractor
before the launch, she discovered that managers were "deviantly"
nagging engineers to approve the launch although the engineers KNEW
that the O-rings had not been tested in full under the unusually low
temperatures they'd endure in the January launch.

Her book "The Challenger Launch Decision: Risky Technology, Culture
and Deviance at NASA" (http://www.amazon.com/Challenger-Launch-
Decision-Technology-Deviance/dp/0226851761/ref=sr_1_1?
ie=UTF8&s=books&qid=1265704835&sr=8-1) identified what anthropologists
call a culture of dismissing engineers' concerns when management, over-
responsive to political pressure to demonstrate American macho
prowess. Unfortunately, although she served on the review panel, her
message wasn't heeded. The same sort of normalized deviance caused the
crash of the Columbia space shuttle in 2003. Here, known problems with
insulation padding were "normalized" in the same way Seebach
"normalized" his deviant failure to foresee that a character scan
would create a problem, with the same sort of pseudo-macho posturing,
and the same sort of bullying of dissidents.

Just as Seebach said "I've neglected the issue, but I'm cute and
normal, unlike Nilges", engineers who pointed out that foam padding
falling off at launch was not in the specifications were laughed at
and shown the door because "we have put this issue in a data base".

A lot of people have died owing to normalized deviance. It is the norm
in programming circles and causes most software problems, in my view.

>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 8 of 15 ==
Date: Tues, Feb 9 2010 12:48 am
From: Richard Heathfield

Seebs wrote:
> On 2010-02-09, Richard Heathfield <rjh@see.sig.invalid> wrote:
>> Seebs wrote:
>>> More importantly, why on earth would it take "a few hours" to fix something
>>> this simple?
>
>> Think about it. It takes him several hours to delete a single line.
>
> That's not quite the same. He didn't understand the criticism, and while
> that's sad, it is an explanation for why it would take a while -- he wasn't
> actually *working* on it during that time, he just didn't understand the
> problem description.

All true.

> By contrast, with the other parts, he clearly had a pretty good idea of what
> the problems were,

But here I must disagree with you.

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

== 9 of 15 ==
Date: Tues, Feb 9 2010 12:54 am
From: spinoza1111

On Feb 8, 6:57 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <be01b0e7-bfca-44fa-a9ce-ffc3e3582...@f17g2000prh.googlegroups.com>,
>
>
>
>
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 4, 9:22 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <fdc37ec6-5ac5-4b89-83ad-6aa43d44e...@k36g2000prb.googlegroups.com>,
>
> > >spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > On Feb 1, 10:06 pm, Colonel Harlan Sanders <Har...@kfc.com> wrote:
> > > > > On Mon, 1 Feb 2010 05:29:52 -0800 (PST),spinoza1111
>
> > > > > <spinoza1...@yahoo.com> wrote:
>
> > > [ snip ]
>
> > > > I have no respect it is true for Peter Seebach. Why? Because he's
> > > > bragged that he's never taken a computer science class in his life
>
> > > Why do you keep claiming that Seebs "bragged" or boasted about not
> > > having taken CS classes? as best I can tell, you made a guess about
> > > various people's backgrounds, in message ID
>
> > > <b591c6a0-33d0-4f9b-954d-275d39a24...@y10g2000prg.googlegroups.com>
>
> > > >>Sounds to me that you guys AP'd out of CS 101
>
> > > and he followed up to someone else's response, in message ID
>
> > > <slrnhe9bf2.75q.usenet-nos...@guild.seebs.net>
>
> > > as follows (slightly reformatted for readability):
>
> > > >>There is some irony, which is that for reasons not adequately
> > > >>explained (my brain is pretty weird), it *never occurred to me* to try
> > > >>to take any CS classes. Programming was just stuff I did for fun. So
> > > >>in fact, I've never taken ANY CS classes, of any level -- I just pick
> > > >>stuff up as I go, which explains why I have a much more practical
> > > >>"here's what works" attitude rather than an ivory-tower one... and
> > > >>also why I have to look up basic algorithms, or be hinted towards
> > > >>them.
>
> > > He later wrote, in message ID
>
> > > <slrnhebcsf.qtc.usenet-nos...@guild.seebs.net>
>
> > > >>On 2009-10-26, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > >>> In
> > > >>><488ea67e-ab95-41fd-8872-84145f55f...@v15g2000prn.googlegroups.com>,
> > > >>>spinoza1111wrote:
> > > >>>> "I have never taken any computer science classes" - Peter Seebach 26
> > > >>>> Oct 2003 (with pride)
>
> > > >>> Lots of programmers have picked up their knowledge as they go along,
> > > >>> and some of them are very bright bunnies indeed.
>
> > > >>It's entirely possible that, by sheer coincidence, I said this exact
> > > >>thing both earlier today (or yesterday, but in a different time zone)
> > > >>and also exactly six years ago, but it seems more likely to me by far
> > > >>that Spinny's guessed the year wrong.
>
> > > >>But there's a more significant error, which is the attribution "(with
> > > >>pride)". So far as I can tell, this is pretty much guaranteed to be
> > > >>in error, as my brain does not appear to generate the experiences
> > > >>usually referred to by the word "pride" (or by the word "shame"; at
> > > >>least I'm an equal-opportunity sort). I am neither proud of, nor
> > > >>ashamed of, the coincidence that I never happen to have taken a CS
> > > >>class. It has sometimes been a bit of a nuisance in terms of trying
> > > >>to get my job done, but then, the degree I *did* pick up (psych) turns
> > > >>out to have been, arguably, more useful to me. (I also did most of
> > > >>math and philosophy degrees, and have no regrets about either.) It
> > > >>probably would have been useful to pick up CS, and certainly I did
> > > >>pick a fair bit up by osmosis and exposure.
>
> > > Where's the bragging or boasting here?
>
> > It's in the fact that he's unqualified,
>
> I don't agree with you that this is an established fact.

So don't agree. However, he's established it:

"The heap is a DOS term".

"Here's my code. It doesn't rilly work, and to fix it you have to mung
two places to add a lookahead, and if I knew my ass from a hole in the
ground, which I don't, I'd know that the lookahead has to lookahead
for 's' in two places, meaning that if the character changes there are
too places to change, but I'm cute."
>
> > and to say that the absence of
> > this training is in any way a good thing is bragging and boasting and
> > false.
>
> I don't agree here either. Humans have a finite number of hours
> in which to accomplish whatever they want to accomplish with their
> lives, and choosing not to spend any of them on formal academic
> coursework in computer science allows spending more of them on other
> things, things that might ultimately be more useful or interesting.
> "YMMV", maybe.
>
> (As someone who teaches CS to undergraduates, I do think that formal
> coursework provides something of value, namely a conceptual framework
> on which to hang the technical knowledge one picks up in the course
> of a career in IT, but I would not want to claim that there is no
> other way to acquire such a framework.)

You're missing the main reason. It's to be able to think about code
without some thug manager breathing down your neck. It is a taste of
human freedom and the civility that results.
>
> > His humility is feigned. I detected this when he called me a "moron".
> > Rahm Emanuel has apologized for this type of language: Seebs has not.
> > He hurls invective which is not to be humble, and deletes email
> > offering to discuss differences UNREAD.
>
> Presumably as a result of discussions in this newsgroup. I'll say
> that I would probably have been curious enough to at least read the
> e-mail, even if I was fairly certain there would be no point in
> replying, but there are certainly many e-mail messages that I delete
> unread, based on the combination of sender and subject header.
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 10 of 15 ==
Date: Tues, Feb 9 2010 12:57 am
From: spinoza1111

On Feb 8, 7:15 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Seebs <usenet-nos...@seebs.net> writes:
> > On 2010-02-07,spinoza1111<spinoza1...@yahoo.com> wrote:
> >> char * replace(char * strMaster,
> >> char * strTarget,
> >> char * strReplacement)
> >> {
>
> > So far, this looks fine.
>
> Lack of consts makes it look amateurish.

...and Job One is looking good, I suppose, and shitting on people.

Pray why do we need constants? They are, almost by definition, one
more point of failure. I lack consts because I don't cover up
incompetence by using "buffers" (the use of which term is always a
sign of incompetence). I didn't need constants because I used a linked
list, for I learned long ago that hard-coded limits are trouble.
>
> Phil
> --
> Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

== 11 of 15 ==
Date: Tues, Feb 9 2010 1:01 am
From: spinoza1111

On Feb 8, 7:56 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Joe Wright <joewwri...@comcast.net> writes:
> > Ben Bacarisse wrote:
> >> Joe Wright <joewwri...@comcast.net> writes:
>
> >>> santosh wrote:
> >>>> Joe Wright wrote:
> >>>>>spinoza1111wrote:
> >>>>>> On Feb 7, 7:50 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
> >>>>> [ all snipped ]
> >>>>> I suggest you spend overlong on a relatively simple task. Regard..
>
> >>>>> /*
> >>>>> Program: stuff.c
> >>>>> Author: Joe Wright
> >>>>> Date: 05/24/1999
>
> >>>>> The dBASE stuff() function
> >>>>> */
>
> >>>>> #include <stdio.h>
> >>>>> #include <stdlib.h>
> >>>>> #include <string.h>
>
> >>>>> #define LEN 256
>
> >>>>> void usage(void) {
> >>>>> printf("Usage: stuff 'cString' nStart nDelete 'cInsert'\n"
> >>>>> "Example: stuff 'Now is the time.' 7 0 'NOT '\n"
> >>>>> "Note: nStart is rel-0 in C\n"), exit(0);
> >>>>> }
>
> >>>>> char *stuff(char *string, int start, int delete, char *insert) {
> >>>>> static char str1[LEN]; /* Return buffer */
> >>>>> char str2[LEN]; /* Temporary buffer */
> >>>>> strncpy(str1, string, start);
> >>>>> str1[start] = 0;
> >>>>> strcpy( str2, string+start+delete);
> >>>>> strcat( str1, insert);
> >>>>> return strcat(str1, str2);
> >>>>> }
>
> >>>>> int main(int argc, char **argv) {
> >>>>> if (argc < 5) usage();
> >>>>> printf("%s\n", stuff(argv[1], atoi(argv[2]), atoi(argv[3]), argv[4]));
> >>>>> return 0;
> >>>>> }
> >>>>> /* End of stuff.c */
>
> >>>>> Note stuff() is eight lines, not eighty. You are a fraud.
> >>>> This doesn't exactly do whatspinoza1111set out to do, and what the
> >>>> subsequent examples from others like Ben and Willem did. That combined
> >>>> with the fact that you're using static buffers means that a line count
> >>>> comparison of this program with the others is not very meaningful.
> >>> Gimme a break. One malloc() and one free() add two lines.
>
> >> How does that give you a function like the one being discussed
> >> elsewhere in the thread?
>
> > I must be missing something.spinoza1111came up with almost 100 lines
> > of code to solve what I consider to be a simple problem solvable in 10
> > lines or so. Maybe I didn't appreciate how hard a real programmer
> > would work on this sort of thing. Finding a substring and replacing it
> > with another is almost trivial.
>
> If your point was simply that "this is trivial" then we are in total
> agreement; but it looked like you were saying "*this* is how trivial
> it is" by giving an function to solve the problem. My point was that
> you really have to match the specification not use a related but
> slightly simpler one.

A word from the wise, indeed. The "spec" is "don't use string.h". I
can well imagine this "spec" obtaining in the real world, whether when
using a compiler without a complete library, or simply to save storage
in an embedded world. Or, working for some unreasonable manager from
hell who hates string.h. Like me, for example.

Real professionals enjoy Five Easy Pieces, that is revisiting the
basics. Phonies phear exposure.
>
> --
> Ben.

== 12 of 15 ==
Date: Tues, Feb 9 2010 1:51 am
From: "io_x"

"James" <no@spam.invalid> ha scritto nel messaggio
news:hkna39$9us$1@speranza.aioe.org...
> "Seebs" <usenet-nospam@seebs.net> wrote in message
> news:slrnhmtte2.lfb.usenet-nospam@guild.seebs.net...
> [...]
What about this?

#include <stdio.h>
#include <stdlib.h>
#define P printf

char* __stdcall SostituisciPercS(char* origin, char* whatSost, char* sost);

// origin has to came from malloc memory
int Print(char** origin, char* whatSost, char* sost)
{char *p=SostituisciPercS(*origin, whatSost, sost);
int i;
if(p==0) return 0;
P("Origin=%s|WhatS=%s|Sost=%s\n", *origin, whatSost, sost);
P("Result=%s\n", p);
free(*origin); *origin=p;
return 1;
}

int test(void)
{int r;
char *src, c;

src=realloc(0, 1024);
if(src==0) return 0;
for(r=0; ; ++r)
{c="XYXYX--XYXYXY--XYXYXY"[r];
// c="XY123XY456"[r];
src[r]=c;
if(c==0) break;
}

r = Print(&src, "XY", "AB");
if(r==0) {free(src); return 0;}
r = Print(&src, "--", "<-->");
if(r==0) {free(src); return 0;}
r = Print(&src, "--", "<-->");
if(r==0) {free(src); return 0;}
r = Print(&src, "<<", "|");
if(r==0) {free(src);return 0;}
r = Print(&src, ">>", "|");
if(r==0) {free(src); return 0;}
r = Print(&src, "ABABAB", "1234");
if(r==0) {free(src); return 0;}
r = Print(&src, "ABABX", "ABCDEFG");
if(r==0) {free(src); return 0;}
r = Print(&src, "-", "");
if(r==0) {free(src); return 0;}
r = Print(&src, "||", "<<XXX>>");
if(r==0) {free(src); return 0;}
r = Print(&src, "<X", "-");
if(r==0) {free(src); return 0;}
r = Print(&src, ">X", "--->");
if(r==0) {free(src); return 0;}
r = Print(&src, "X>", "X--->");
if(r==0) {free(src); return 0;}
r = Print(&src, "1234", "!");
if(r==0) {free(src); return 0;}
r = Print(&src, "<-XX--->>!", "!");
if(r==0) {free(src); return 0;}
r = Print(&src, "ABCD", "Hello");
if(r==0) {free(src); return 0;}
r = Print(&src, "EFG", " World");
if(r==0) {free(src); return 0;}
r = Print(&src, "!@#", "123456789");
if(r==0) {free(src); return 0;}
r = Print(&src, "!!", "!");
if(r==0) {free(src); return 0;}
r = Print(&src, "Hello", "Goodbye");
if(r==0) {free(src); return 0;}
r = Print(&src, "!", "! We are going to miss you!");
if(r==0) {free(src); return 0;}
free(src);
return 0;
}

int main(void)
{test();
return 0;
}

---------
section _DATA use32 public class=DATA

global SostituisciPercS
extern _realloc
extern _free

section _BSS use32 public class=BSS
section _TEXT use32 public class=CODE

; 0k,4j,8i,12b,16ra, 20P_fmt, 24P_WhatSost 28P_Sost + 64
; 84 88 92
; 0inString, 4sizeResult, 8NowArg
SostituisciPercS:
push ebx
push esi
push edi
push ebp
sub esp, 64
mov esi, dword[esp+ 84]
cmp dword[esp+ 88], 0
je .e0
cmp dword[esp+ 92], 0
je .e0
cmp esi, 0
je .e0 ; k=current arg, j array
mov edi, 0
mov dword[esp+ 0], 0
mov dword[esp+ 4], 0
mov ebx, 0
jmp short .0 ; 0led_isstring b is index [len]
.e: push edi
call _free
.e0: xor eax, eax
stc
jmp .z
.0: cmp ebx, dword[esp+ 4]
jb .1
mov ecx, ebx
add ecx, 32
push ecx
push ecx
push edi
call _realloc
add esp, 8
pop ecx
cmp eax, 0
je .e
mov edi, eax
mov dword[esp+ 4], ecx
.1: cmp dword[esp], 1
jne .3
xor eax, eax
mov al, [ebp]
cmp eax, 0
jne .2
mov dword[esp+ 0], 0
jmp short .0
.2: mov byte[edi+ebx], al
inc ebp
inc ebx
jmp short .0
.3: mov ebp, dword[esp+ 88]
xor eax, eax
mov ecx, esi ; cerca di vedere se le stringhe sono uguali
.4: mov al, [ebp]
cmp eax, 0
je .5
cmp al, [ecx]
jne .7
inc ecx
inc ebp
jmp short .4
.5: mov dword[esp+ 0], 1
inc esi
mov esi, ecx
mov ebp, dword[esp+ 92]
jmp short .0
.ee: jmp .e
.7: mov al, [esi]
mov byte[edi+ebx], al
inc esi
inc ebx
cmp eax, 0
je .8
jmp .0
.8: push ebx
push edi
call _realloc
add esp, 8
cmp eax, 0
je .ee
clc
.z:
lea esp, [esp+64]
pop ebp
pop edi
pop esi
pop ebx
ret 12
--------
Origin=XYXYX--XYXYXY--XYXYXY|WhatS=XY|Sost=AB
Result=ABABX--ABABAB--ABABAB
Origin=ABABX--ABABAB--ABABAB|WhatS=--|Sost=<-->
Result=ABABX<-->ABABAB<-->ABABAB
Origin=ABABX<-->ABABAB<-->ABABAB|WhatS=--|Sost=<-->
Result=ABABX<<-->>ABABAB<<-->>ABABAB
Origin=ABABX<<-->>ABABAB<<-->>ABABAB|WhatS=<<|Sost=|
Result=ABABX|-->>ABABAB|-->>ABABAB
Origin=ABABX|-->>ABABAB|-->>ABABAB|WhatS=>>|Sost=|
Result=ABABX|--|ABABAB|--|ABABAB
Origin=ABABX|--|ABABAB|--|ABABAB|WhatS=ABABAB|Sost=1234
Result=ABABX|--|1234|--|1234
Origin=ABABX|--|1234|--|1234|WhatS=ABABX|Sost=ABCDEFG
Result=ABCDEFG|--|1234|--|1234
Origin=ABCDEFG|--|1234|--|1234|WhatS=-|Sost=
Result=ABCDEFG||1234||1234
Origin=ABCDEFG||1234||1234|WhatS=|||Sost=<<XXX>>
Result=ABCDEFG<<XXX>>1234<<XXX>>1234
Origin=ABCDEFG<<XXX>>1234<<XXX>>1234|WhatS=<X|Sost=-
Result=ABCDEFG<-XX>>1234<-XX>>1234
Origin=ABCDEFG<-XX>>1234<-XX>>1234|WhatS=>X|Sost=--->
Result=ABCDEFG<-XX>>1234<-XX>>1234
Origin=ABCDEFG<-XX>>1234<-XX>>1234|WhatS=X>|Sost=X--->
Result=ABCDEFG<-XX--->>1234<-XX--->>1234
Origin=ABCDEFG<-XX--->>1234<-XX--->>1234|WhatS=1234|Sost=!
Result=ABCDEFG<-XX--->>!<-XX--->>!
Origin=ABCDEFG<-XX--->>!<-XX--->>!|WhatS=<-XX--->>!|Sost=!
Result=ABCDEFG!!
Origin=ABCDEFG!!|WhatS=ABCD|Sost=Hello
Result=HelloEFG!!
Origin=HelloEFG!!|WhatS=EFG|Sost= World
Result=Hello World!!
Origin=Hello World!!|WhatS=!@#|Sost=123456789
Result=Hello World!!
Origin=Hello World!!|WhatS=!!|Sost=!
Result=Hello World!
Origin=Hello World!|WhatS=Hello|Sost=Goodbye
Result=Goodbye World!
Origin=Goodbye World!|WhatS=!|Sost=! We are going to miss you!
Result=Goodbye World! We are going to miss you!

== 13 of 15 ==
Date: Tues, Feb 9 2010 1:56 am
From: Tim Streater

On 08/02/2010 23:33, Richard Heathfield wrote:
> Seebs wrote:
>> On 2010-02-08, Tim Streater <timstreater@waitrose.com> wrote:
>>> Only if you like slapstick. Personally, I can't stand it.
>>
>> I like very little of it. It is very rarely done well.
>
> Check out Norman Wisdom. He does it very well indeed.

Fractionally before my time (I think).

I saw Dudley Moore in some film (Arthur??) in which he is by a swimming
pool where there is a small table with a phone on it (not in the pool :-)

Needless to say, and entirely predictably, he tangles himself up in the
phone line and goes into the pool. With the phone.

It was very well done, I have to say, it looked almost entirely natural.
But the predictability of it turned it into a yawn.

--
Tim

"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"

Bill of Rights 1689

== 14 of 15 ==
Date: Tues, Feb 9 2010 1:59 am
From: spinoza1111

On Feb 8, 8:57 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > On 7 Feb, 16:56, Willem <wil...@stack.nl> wrote:
>
> > <snip>
>
> >> Of course, this will get horridly bad performance for some nasty inputs,
> >> especially when the 'replace' string has repeats.
>
> >> To fix that you need Boyer-Moore, IIRC (which I think strstr uses ?)
>
> > no. The standard doesn't specify algorithms. I'd be slightly surprised
> > if strstr() used Boyer-Moore, I thought it was a bit over the top for
> > the simple cases.
>
> You may be slightly surprised then. From the current glibc strstr
> sources:
>
> /* We use the Two-Way string matching algorithm, which guarantees
> linear complexity with constant space. Additionally, for long
> needles, we also use a bad character shift table similar to the
> Boyer-Moore algorithm to achieve improved (potentially sub-linear)
> performance.
>
> Seehttp://www-igm.univ-mlv.fr/~lecroq/string/node26.html#SECTION00260
> andhttp://en.wikipedia.org/wiki/Boyer-Moore_string_search_algorithm
> */
>
> It's not exactly Boyer-Moore but I suspect that this is more because
> this hybrid is superior rather than a reluctance to use BM. I don't
> know enough about this have an opinion (at east not one than anyone
> should listen to) about this choice.
>
> Anyway, here is a very important point for C programmers here: anyone
> who decides not to use the C library is cutting themselves off from a
> considerable pool of expertise.

This is true. However, people sail sailboats and walk to work, cutting
themselves off from the expertise of steamship and automobile
designers simply to stay human in the sense of recapitulating the
efforts needed before, and to create, advanced technology.

I've never implemented Boyer-Moore, although I saw it in
Communications of the ACM when it came out in 1977. All the more
reason to give it a whack in a later version of replace().
>
> --
> Ben.

== 15 of 15 ==
Date: Tues, Feb 9 2010 2:06 am
From: Nick Keighley

On 9 Feb, 08:57, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 8, 7:15 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> wrote:
> > Seebs <usenet-nos...@seebs.net> writes:

> > > On 2010-02-07,spinoza1111<spinoza1...@yahoo.com> wrote:
> > >> char * replace(char * strMaster,
> > >> char * strTarget,
> > >> char * strReplacement)
> > >> {
>
> > > So far, this looks fine.
>
> > Lack of consts makes it look amateurish.

I don't agree. Use of const slightly improves the code, but I probably
wouldn't reject code at a walkthru for lack of const (I might comment
though).

<snip>

> Pray why do we need constants?

"const" not "constants". "const" is a C keyword that indicates to the
compiler that the function isn't going to change the value. It labels
the parameters as strictly input only (it also the function using the
parameters as temporary variables- which should please you!). It has
semantics (in this case) of something like Ada's "in" parameters.
"const" is a bit like "assert" its much more powerful than you at
first appreciate.

> They are, almost by definition, one
> more point of failure.

how so? How are const parameters more prone to failure?

> I lack consts because I don't cover up
> incompetence by using "buffers" (the use of which term is always a
> sign of incompetence).

I've no idea what you are talking about

> I didn't need constants because I used a linked
> list, for I learned long ago that hard-coded limits are trouble.

what?

--
the unemployed programmer had a problem. "I know", said the
programmer, "I'll just learn perl." the unemployed programmer
now had two problems.
Eric Naggum (comp.lang.lisp)

==============================================================================
TOPIC: Missing braces around {0} initializer?!
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 1:03 am
From: Phil Carmody

Keith Thompson <kst-u@mib.org> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Seebs <usenet-nospam@seebs.net> writes:
>>>> On 2010-02-08, Tor Rustad <bwzcab@wvtqvm.vw> wrote:
>>>>> I am puzzled by a warning, I get when using {0} as initializer. This
>>>>> snippet demonstrate the warning:
>>>>
>>>>> There was no warning with { {0,0,0} }, but I thought { 0 } was perfectly
>>>>> conforming C as initializer above. Is this warning a compiler specific
>>>>> thing which I can turn off somehow, or am I completely missing something
>>>>> in Standard C here???
>>>>
>>>> I believe the answer is neither.
>>>>
>>>> Rather, it's a *warning*. A helpful warning that, if you are initializing
>>>> an array of structures, it is clearer to put braces around the structure
>>>> initializers. Which it is. Most people won't be quite sure of the semantics
>>>> of something like
>>>>
>>>> struct { int a, b, c; } foo[] = { 1, 2, 3, 4 };
>>>>
>>>> and thus gcc warns you that you should probably have the right number of
>>>> levels of braces.
>>>>
>>>> It's not saying your code violates the standard, just that your code has
>>>> characteristics which are very strongly suggestive that you have made a
>>>> typo.
>>>
>>> Which are very strongly suggestive *to gcc*.
>>>
>>> The initializer { 0 } sets all members of the initialized object to
>>> zero. This is, or should be, a common C idiom. gcc just doesn't
>>> recognize it.
>>
>> Please provide proof that it doesn't recognise it. Please be more
>> detailed than the above - precisely which bit of the construct do
>> you think it is unable to cope with? From my perspective, it looks
>> as if it understands the construct and the legality, and typical use,
>> of same, perfectly.
>
> Hmm. I really thought I was sufficiently clear.
>
> gcc, like any conforming C compiler, certainly recognizes the
> initializer { 0 } and correctly handles its syntax and semantics.
> What I meant is that it doesn't recognize it *as an idiom* for
> "recursively initialize this object and all its sub-members and
> sub-elements to zero".

Hmm. I really thought I was sufficiently clear. The above is no
proof that it's not recognised as an idiom for the above. Just
because it's recognised as an idiom doesn't mean the compiler can't
throw up warnings about it. Calling something an idiom doesn't
magically make everything that looks like it safe and not worth
warning about. Common mistakes can be idiomatic of a language too.

> Consider the following translation unit:
>
> struct s { int x; int y; int z; };
> struct s s1 = { 0 };
> struct s s2 = { 0, 0 };
>
> With "-Wmissing-field-initializers" or equivalent, gcc warns about
> both initializers. With "-Wno-missing-field-initializers", gcc
> doesn't warn about either of them.
>
> What I would like is a way to make gcc, or whatever compiler I happen
> to be using, to warn about the initialization of s2 (because it's
> missing an initializer for z), but not about the initialization
> of s1 (because it's using the "{ 0 }" idiom, and I *deliberately*
> omitted explicit initializers for most of the members).
>
> One possible drawback is that if I write "{ 0 }", I might really
> have meant that the object has exactly one member or element rather
> than that I don't want to specify how many it has.

Exactly. Treating elision to denote intent is dangerous. Sufficiently
dangerous for gcc to consider it worth a warning with most common
invocations.

> What I'd like even better is a change to the language so that "{ }"
> is equivalent to what "{ 0 }" currently means, but I can expect a
> compiler not to warn me about it.

I approve of that, certainly.

> I have another idea, but it would break tons of existing code, so it's
> unlikely ever to make it into the language. By default, require
> explicit initializers for all subobjects. Allow "..." to indicate
> that the current subobject and everything following it is implicitly
> zero. Thus:
>
> struct s s1 = { 0 }; /* constraint violation */
> struct s s2 = { 42, ... }; /* x = 42, y = 0, z = 0 */
> struct s s3 = { ... }; /* initialize all members to 0 */
> struct s s4 = { 1, 2, 3, ... }; /* probably ok */
>
> There would be a lot of details to work out; since it would break
> existing code, I won't bother.

I approve of an explicit '...' to represent an explicit request
(to initialise all further subobjects to 0) too. Only the orthogonal
addition of the requirement for other initialisations to be fully
explicit causes breakage.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

==============================================================================
TOPIC: SMTP Client
http://groups.google.com/group/comp.lang.c/t/fd5e81482c2e8dd1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 1:27 am
From: Nick Keighley

On 9 Feb, 02:07, J <seaworthyjer...@gmail.com> wrote:
> I am starting a new project to create a SMTP Client for Windows; I am
> using the winsock2 library. When I use the following commands I get an
> error (550):
>
> 220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
> HELO world
> 250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
> MAIL FROM: t...@test.com
> 250 OK
> RCPT TO: t...@gmail.com
> 550 authentication required
> QUIT
> 221 ns1.zanmo.com closing connection
>
> Please explain how to authenticate the session, and how do I
> Programmatically MX Lookup also using MX record?

try a better newsgroup. Maybe a microsoft one

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 1:44 am
From: Arved Sandstrom

Seebs wrote:
> On 2010-02-09, Arved Sandstrom <dcest61@hotmail.com> wrote:
>> At the moment those standards do not exist for the majority of software
>> developers. So it's pretty much a moot point.
>
> I am not convinced that they don't; formalization is not existance.
>
>> If the standards did exist, how would you know that a person who claimed
>> a title actually deserved it, without having them go through a
>> certification process?
>
> How would you know if there WERE a certification process? Answer: You
> wouldn't.

How would I, or you, not know? It's not like we are discussing Masonic
rites here.

I myself have chosen not to get any software development certifications,
except for one that I got from the technical campus of Dalhousie
University for a series of software development courses. It's not that I
consider many of the MS and Java etc etc certifications to be
individually useless - many are not - but lacking a larger professional
development framework to plug them into, and because the accountability
of software developers currently is risible, why bother?

> It's not as though no one's ever tried it. We have a number of certification
> processes. They consistently work, if what you want is to know that someone
> once managed to memorize a bunch of stuff for a test. I have seen nothing
> to suggest that any other field's "certification processes" are actually
> substantially better than this.

I can only comment on engineering (I am not one myself but I have a
diploma in engineering, and most of the credits for a baccalaureate in
engineering - I eventually decided to concentrate on a physics degree; I
am also reasonably familiar with how APENS, the Association of
Professional Engineers of Nova Scotia, does these things).

Engineering "certification" processes are considerably better and more
comprehensive than anything that most software developers are ever
exposed to. Starting with education - there's no requirement at all that
software developers have a relevant degree or associate degree, or
indeed any real SD training at all. Try that with prospective
professional engineeers.

It's not just entry-level certification that software developers lack.
It's code of conduct, professional education, duty to the client,
professional discipline and so forth. These are all standards. In order
for software "engineering" to really be engineering it has to adopt
similar standards.

Certainly, they are extremely popular,
> especially among people who have already obtained those certifications.
>
> -s

_What_ are extremely popular? Professional engineering accreditations or
software development certifications? I expect both are.

AHS

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

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

Tuesday, February 9, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts