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:

* Motivation of software professionals - 7 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
* plz explain the programs output - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/4af8d6827bc390b6?hl=en
* substring finding problem! - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
* Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours? - 7 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
* Efficency and the standard library - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* Draft paper submission deadline is extended: SETP-10, Orlando, USA - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/d93be6b44bc34544?hl=en

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

== 1 of 7 ==
Date: Sun, Feb 14 2010 8:54 am
From: Lew

James Kanze wrote:
>> Did you actually try using any free software back in the early
>> 1990's [sic]?

Seebs wrote:
> I did.

Same here.

> NetBSD was for the most part reliable and bulletproof during that time;
> it ran rings around several commercial Unixes. I had no interest in g++;
> so far as I could tell, at that time, "a C++ compiler" was intrinsically
> unusable. But gcc was stable enough to build systems that worked reliably,
> and the BSD kernel and userspace were pretty livable.

James Kanze wrote:
>> Neither Linux nor g++ were even usable, and emacs (by

That's pure fantasy.

I used a couple of Linux distributions in the early nineties, and they worked
better than commercial UNIX variants.

I used emacs and knew many who used vi back then. They were solid.

I used gcc by the mid-90s and it was rock solid, too.

I used free software even as far back as the late 80s that worked beautifully.

The facts to back up your assertions are not in evidence.

>> far the highest quality free software), it was touch and go, and
>> depended on the version. Back then, the free software community
>> was very much a lot of hackers, doing whatever they felt like,
>> with no control. Whereas all of the successful free software
>> projects today have some sort of central management, ensuring
>> certain minimum standards.

Seebs wrote:
> I have no idea what you're talking about. I cannot point to any point
> in the history of my exposure to free software (which predates the 1990s)
> at which any major project had no central management. Linux was pretty
> flaky early on, but then, in the early 1990s, all it had to do was be
> more stable than Windows 3.1, which was not a high bar to reach for.

--
Lew

== 2 of 7 ==
Date: Sun, Feb 14 2010 8:56 am
From: Seebs

On 2010-02-14, James Kanze <james.kanze@gmail.com> wrote:
> To be really effective, design and code review requires a
> physical meeting. Depending on the organization of the project,
> such physical meetings are more or less difficult.

Nonsense.

> Code review is *not* just some other programmer happening to
> read your code by chance, and making some random comments on
> it. Code review involves discussion. Discussion works best
> face to face.

IMHO, this is not generally true. Of course, I'm autistic, so I'd naturally
think that.

But I've been watching a lot of code reviews (our review process has named
reviewers, but also has reviews floating about on a list in case anyone
else sees something of interest, which occasionally catches stuff). And what
I've seen is that a whole lot of review depends on being able to spend an
hour or two studying something, or possibly longer, and write detailed
analysis -- and that kind of thing is HEAVILY discouraged for most people
by a face-to-face meeting, because they can't handle dead air.

Certainly, discussion is essential to an effective review. But discussion
without the benefit of the ability to spend substantial time structuring and
organizing your thoughts will feel more effective but actually be less
effective, because you're substituting primate instincts for reasoned
analysis.

I really don't think that one can be beaten. If what you need for a code
review is for someone to spend hours (or possibly days) studying some code
and writing up comments, then trying to do it in a face-to-face meeting would
be crippling. Once you've got the comments, you could probably do them
face-to-face, but again, that denies you the time to think over what you've
been told, check it carefully, and so on. You want a medium where words sit
there untouched by the vagaries of memory so you can go back over them.

But!

You do need people who are willing and able to have real discussions via text
media. That's a learned skill, and not everyone's learned it.

It is not universally true that discussion "works best face to face".
Certainly, there are kinds of discussions which benefit heavily from
face-to-face exposure. There are other kinds which are harmed greatly by
it. Perhaps most importantly, many of the kinds which are harmed greatly
by it *FEEL* much better face-to-face, even though they're actually working
less well.

The curse of being made out of meat is that your body and brain lie to
you. Knowing about this is the first step to overcoming the harmful side
effects.

-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 7 ==
Date: Sun, Feb 14 2010 9:46 am
From: Andy Champ

Lew wrote:
>
> What, with a name like "Bloch" I wouldn't know what I'm saying?
>

I might point out that all _we_ could see is that you are called Lew...

Andy

== 4 of 7 ==
Date: Sun, Feb 14 2010 10:14 am
From: Martin Gregorie

On Sun, 14 Feb 2010 16:45:43 +0000, Seebs wrote:

> I have no idea what you're talking about. I cannot point to any point
> in the history of my exposure to free software (which predates the
> 1990s) at which any major project had no central management. Linux was
> pretty flaky early on, but then, in the early 1990s, all it had to do
> was be more stable than Windows 3.1, which was not a high bar to reach
> for.
>
About the best free software I remember from that era was Kermit. It
worked and worked well and had ports to a large range of OSen and
hardware of widely varying sizes: I first used it on a 48 KB 6809 running
Flex-09 and still use it under Linux. It had an open development model
though it was managed within a university department, so the project
owners had pretty good control over it.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

== 5 of 7 ==
Date: Sun, Feb 14 2010 10:23 am
From: Lew

Lew wrote:
>> What, with a name like "Bloch" I wouldn't know what I'm saying?

Andy Champ wrote:
> I might point out that all _we_ could see is that you are called Lew...

You might, but that would be stupid.

--
Lew

== 6 of 7 ==
Date: Sun, Feb 14 2010 10:28 am
From: Nick Keighley

On 12 Feb, 21:22, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 11, 9:33 pm, Andy Champ <no....@nospam.invalid> wrote:
> > Lew wrote:
> > > Andy Champ wrote:

> > >> In 1982 the manager may well have been right to stop them
> > >> wasting their time fixing a problem that wasn't going to be
> > >> a problem for another 18 years or so. The software was
> > >> probably out of use long before that.
>
> > > Sure, that's why so many programs had to be re-written in 1999.
> > > Where do you get your conclusions?
>
> > Pretty well everything I saw back in 1982 was out of use by
> > 1999. How much software do you know that made the transition?
> > Let's see.. Operating systems. The PC world was... umm.. CP/M
> > 80? Maybe MS-Dos 1.0? And by 1999 I was working on drivers
> > for Windows 2000. That's at least two, maybe three depending
> > how you count it, ground-up re-writes of the OS.
> > With that almost all the PC apps had gone from 8 bit versions
> > in 64kb of RAM to 16-bit DOS to Windows 3.1 16-bit with
> > non-preemptive multitasking and finally to a 32-bit app with
> > multi-threading and pre-emptive multitasking running in
> > hundreds of megs.
>
> > OK, so how about embedded stuff? That dot-matrix printer
> > became a laserjet. The terminal concentrator lost its RS232
> > ports, gained a proprietary LAN, then lost that and got
> > ethernet. And finally evaporated in a cloud of client-server
> > computing smoke.

I know of system's that still poke data down 9600b lines.

> The "standard" life of a railway locomotive is thirty or fourty
> years. Some of the Paris suburbain trainsets go back to the
> early 1970's, or earlier, and they're still running.
>
> > I'm not so up on the mainframe world - but I'll be surprised
> > if the change from dumb terminals to PC clients didn't have a
> > pretty major effect on the software down the back.
>
> Have you been to a bank lately, and seen what the clerk uses to
> ask about your account? In more than a few, what you'll see on
> his PC is a 3270 emulator. Again, a technology which goes back
> to the late 1960's/early 1970's.

travel agencies seem to run some pretty old stuff

> > Where do you get your conclusions that there was much software
> > out there that was worth re-writing eighteen years ahead of
> > time?
>
> It depends on what you're writing, but planned obsolescence
> isn't the rule everywhere.

I believe the UK's National Grid (the high voltage country-wide power
distribution system) wanted one-for-one replacements for very old
electonic componants. What had been a rats nest of TTL (or maybe
something older) was replaced with a board containing only a few more
modern components (maybe one). But the new board had to have the same
form factor, electrical power requirements etc. This becasue they
didn't want to actually replace the computers they were part of.

I know of software that runs on an emulated VAX.

Sometimes software far out lives its hardware.

== 7 of 7 ==
Date: Sun, Feb 14 2010 12:07 pm
From: Andy Champ

Oh boy, that reply of mine stirred things up a bit. Nevertheless I'm
going to stick my head over the parapet again! Excuse me not replying
to someone in particular.

The context was where I suggested that the guys who wrote code with the
Y2k bug may have been justified.

I've been surprised by how many of you seem to be involved in ancient
software (Banks; Nextstep AKA OSX; the steam locos on the Darjeeling
Railway even though I'm not convinced they _have_ much software). And
come to think of it some of the avionics stuff I've brushed past seems
to have quite a long lifetime.

The point I wished to make is that software does not have to be perfect.
It has to be fit for purpose, and one of the ways in which it has to
be fit is to be in a state where it can be shipped. Go and read about
the "osborne effect"!

If you were writing an application for stock control of lettuces in 1970
it was probably a pretty good bet that the system wasn't going to need
to worry about the y2k problem. So the standard Cobol date was fine.

On the other hand, if it was a pensions application it most certainly
would - many current pensioners would have been born in the 19th
century, and many current contributors will not be taking their pensions
until the 21st. So for pensions, the standard date wasn't good enough.

When I knock up an application to read the log files from my overnight
tests it doesn't have to handle all possible errors. It doesn't have to
worry about getting the wrong data format. I _know_ what the data
format will be; being paranoid I'll check it quickly, but I won't
attempt to handle all possible formats, nor to recover from a bad one.
That app. isn't nearly as "good" as the stuff I ship - and it doesn't
have to be.

When Y2K came along there were almost no incidents. The problem was
understood, it was fixed. The software was (at least by then) "good
enough".

Andy

==============================================================================
TOPIC: plz explain the programs output
http://groups.google.com/group/comp.lang.c/t/4af8d6827bc390b6?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 14 2010 8:57 am
From: Seebs

On 2010-02-14, manish sahu <manish.comp05@gmail.com> wrote:
> but how we are getting this output?

I suggest that if your instructor really wishes to know, perhaps your
instructor should post the question here directly.

== 2 of 2 ==
Date: Sun, Feb 14 2010 9:36 am
From: Barry Schwarz

On Sun, 14 Feb 2010 04:45:05 -0800 (PST), manish sahu
<manish.comp05@gmail.com> wrote:

Are you going to ask this group to do everyone of your homework
problems?

--
Remove del for email

==============================================================================
TOPIC: substring finding problem!
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Feb 14 2010 8:59 am
From: Seebs

On 2010-02-14, fedora <no_mail@invalid.invalid> wrote:
> Not using string.h was the rule i thought.

No, that was just Nilges being contrary to the point of stupidity.

That said, it could be a good exercise. You've already had one of the
key insights: The thing replacing strstr() should be written as a function
which is called by other functions, so as not to overcomplicate a single
gigantic function.

== 2 of 4 ==
Date: Sun, Feb 14 2010 9:49 am
From: Ben Bacarisse

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-02-14, fedora <no_mail@invalid.invalid> wrote:
>> Not using string.h was the rule i thought.
>
> No, that was just Nilges being contrary to the point of stupidity.
>
> That said, it could be a good exercise. You've already had one of the
> key insights: The thing replacing strstr() should be written as a function
> which is called by other functions, so as not to overcomplicate a single
> gigantic function.

Another insight is that if one is not using strstr then its
replacement should be more helpful that strstr is.

The trouble is that strstr(x, y); returns NULL when y is not in x. It
scans x and then tells you almost nothing. If I were re-doing this
I'd at least make my strstr replacement act like GNU's strchrnul
(there is no strstrnul in GNU's library). I.e. str_str_nul should
return a pointer to the end of its first argument string when the
search fails. At the least this would allow one to avoid re-scanning
just to find the length[1].

Even when the search string /is/ present, the final call always scans
that tail with no valuable data being returned.

I'd argue that strtsr should have been defined this way from the
start, but such is the C library.

[1] At the expense of limiting the code to strings no longer than
PTRDIFF_MAX characters. I think it is quite fiddly to avoid this
restriction so I am not too bothered by that.

--
Ben.

== 3 of 4 ==
Date: Sun, Feb 14 2010 9:49 am
From: Seebs

On 2010-02-14, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Another insight is that if one is not using strstr then its
> replacement should be more helpful that strstr is.

That's a point.

> The trouble is that strstr(x, y); returns NULL when y is not in x. It
> scans x and then tells you almost nothing. If I were re-doing this
> I'd at least make my strstr replacement act like GNU's strchrnul
> (there is no strstrnul in GNU's library). I.e. str_str_nul should
> return a pointer to the end of its first argument string when the
> search fails. At the least this would allow one to avoid re-scanning
> just to find the length[1].

And you'd replace the if (ptr) with if (*ptr), which would be fine. Hmm,
I like that.

> I'd argue that strtsr should have been defined this way from the
> start, but such is the C library.

Hmm.

Here's my thought: The C library functions we currently have are defined
in a way that's simple and well-defined; "return a pointer to X", and if
you can't, don't return a valid pointer. I think that's easier to specify
or discuss than "return a pointer to X, or possibly a pointer to Y".

> [1] At the expense of limiting the code to strings no longer than
> PTRDIFF_MAX characters. I think it is quite fiddly to avoid this
> restriction so I am not too bothered by that.

Yeah.

== 4 of 4 ==
Date: Sun, Feb 14 2010 11:53 am
From: "Chris M. Thomasson"

Here is my humble little entry that took me around a half an hour or so to
create:

http://clc.pastebin.com/f62504e4c

If you want to avoid using `string.h' then you are going to have to implment
the following functions:
_________________________________________________
#define xstrstr strstr
#define xstrlen strlen
#define xstrcmp strcmp
#define xmemcpy memcpy
_________________________________________________

I personally don't see any need to do that unless you want to go through a
learning experience. Or perhaps if you just "know" that those functions are
very poorly implemented on your platform. Anyway, this code pre-computes all
of the substring matches and stores them in a linked-list. This gets around
having to scan the source string twice. It's fairly good at reducing the
number of list nodes by allowing a single node to hold multiple offsets into
the source string. So, in the code as-is, `malloc()/free()' is completely
avoided on list nodes _if_ there are less than or equal to 256 matches.

Any questions?

;^)

==============================================================================
TOPIC: Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours?
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
==============================================================================

== 1 of 7 ==
Date: Sun, Feb 14 2010 9:07 am
From: Ben Bacarisse

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

> On Feb 14, 4:11 pm, James Kanze <james.ka...@gmail.com> wrote:
>>
>> Dereferencing a null pointer is only undefined behavior if the
>> code is actually executed. Something like sizeof(
>> f(*(MyType*)0) ) is perfectly legal, and widely used in some
>> template idioms (although I can't think of a reasonable use for
>> it in C).
>>
> Nulls are dereferenced to produce the offsetof macro hack in C.

Then I would say that it is not an example of what James was talking
about. In his C++ example, no null pointer is dereferenced.

Obviously there is a terminology issue here in that you might want to
say that sizeof *(int *)0 is a dereference of a null pointer because,
structurally, it applies * to such a pointer; but I would rather
reserve the word dereference for an /evaluated/ application of * (or []
or ->). I'd go so far as to say that any other use is wrong.

--
Ben.

== 2 of 7 ==
Date: Sun, Feb 14 2010 9:30 am
From: Thad Smith

Michael Tsang wrote:
>
> Deferencing a NULL pointer is undefined behaviour,

Actually, dereferencing a null pointer _results in_ behavior undefined by
Standard C.

In answer to your subject line question "Knowing the implementation, are all
undefined behaviours become implementation-defined behaviours?", no.

In Standard C "implementation-defined behavior" means that the implementation
documents the behavior. Even if the behavior is consistent for a particular
implementation, it may not be documented.

--
Thad

== 3 of 7 ==
Date: Sun, Feb 14 2010 9:38 am
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <slrnhng9pl.2mq.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:

> while (ptr != 0) {
> /* blah blah blah */
> ptr = get_ptr();
> x = *ptr;
> }
>
>gcc might turn the while into an if followed by an infinite loop, because
>it *knows* that ptr can't become null during the loop, because if it did,
>that would have invoked undefined behavior.

As I've said before, the fact that the compiler can do this sort of
optimisation is often an indication of an error in the code. Why
would the programmer repeatedly test the pointer if it couldn't be
null? I would much rather that the compiler warned about this, instead
of just treating it as an opportunity to remove some code.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

== 4 of 7 ==
Date: Sun, Feb 14 2010 9:46 am
From: Seebs

On 2010-02-14, Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
> As I've said before, the fact that the compiler can do this sort of
> optimisation is often an indication of an error in the code. Why
> would the programmer repeatedly test the pointer if it couldn't be
> null? I would much rather that the compiler warned about this, instead
> of just treating it as an opportunity to remove some code.

That's an interesting point, and I think I'd agree. Maybe. Do we
want a warning for while(1), which we know definitely loops forever?

It could be that the loop was written because the programmer wasn't *sure*
it couldn't be null, but the compiler has proven it and thus feels safe
optimizing.

== 5 of 7 ==
Date: Sun, Feb 14 2010 10:00 am
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <slrnhngdv0.8ao.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:

>That's an interesting point, and I think I'd agree. Maybe. Do we
>want a warning for while(1), which we know definitely loops forever?

No, but only because it's a common idiom.

>It could be that the loop was written because the programmer wasn't *sure*
>it couldn't be null, but the compiler has proven it and thus feels safe
>optimizing.

All the more reason for a warning. Then the programmer can sleep
soundly, and perhaps modify the code accordingly. (And modify the
comment about it that he no doubt wrote.)

-- Richard
--
Please remember to mention me / in tapes you leave behind.

== 6 of 7 ==
Date: Sun, Feb 14 2010 10:02 am
From: Seebs

On 2010-02-14, Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
> In article <slrnhngdv0.8ao.usenet-nospam@guild.seebs.net>,
> Seebs <usenet-nospam@seebs.net> wrote:
>>It could be that the loop was written because the programmer wasn't *sure*
>>it couldn't be null, but the compiler has proven it and thus feels safe
>>optimizing.

> All the more reason for a warning. Then the programmer can sleep
> soundly, and perhaps modify the code accordingly. (And modify the
> comment about it that he no doubt wrote.)

Hmm.

The problem is, this becomes a halting problem case, effectively. It's like
the warnings for possible use of uninitialized variables. We *know* that
those warnings are going to sometimes be wrong, or sometimes be omitted when
they were appropriate, so the compiler has to accept some risk of error. I
think this optimization is in the same category -- there's too many boundary
cases to make it a behavior that people rely on or expect.

== 7 of 7 ==
Date: Sun, Feb 14 2010 11:02 am
From: Pete Becker

Thad Smith wrote:
>
> In Standard C "implementation-defined behavior" means that the
> implementation documents the behavior.

It's actually a little more than that: it means that the standard
*requires* the implementation to document the behavior. Providing
documentation does not turn undefined behavior into
implementation-defined behavior.

Even if the behavior is
> consistent for a particular implementation, it may not be documented.
>

Even if it's documented, it's still undefined behavior according to the
standard. It may well be well-behaved and consistent, but calling that
"implementation-defined" muddles meanings because
"implementation-defined" has a specific meaning within the standard.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Feb 14 2010 9:22 am
From: spinoza1111

On Feb 14, 4:17 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-14, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > Everybody makes stupid mistakes.
>
> I make them more than most people. As a compensating tactic, I can be pretty
> careful about working things out and testing them... But I tend not to when
> posting to Usenet (although I always check my facts before posting nonsense
> to Usenet!).
>
> > When professionals make stupid mistakes (and
> > yes, they do), they don't try to make the situation worse by denying or
> > covering up the mistake.
>
> In general, no. Someone pointed that one out, and I concede cheerfully that,
> yes, that's a pretty stupid mistake. I make stupid mistakes a *lot*, so I'm
> used to that. Note that I make them a lot less often on much more
> complicated things than on simpler things; a neat quirk of brain chemistry
> or something. And I don't just mean "less often, compared to other people"; I
> mean less often in absolute terms. I'm much more likely to get something
> trivial wrong than something interesting and challenging.
>
> > Schildt's mistake, and it's one which he has
> > yet to acknowledge as far as I am aware, is that he has failed to
> > produce a comprehensive errata list for his C books.
>
> I disagree. The problem is not the lack of an errata list; it's that he
> still doesn't even *understand* how feof() works. He's written a series
> of Pascal books which have been cleverly relabeled "C" and had some of the
> punctuation altered, in effect. He got several of the "easy" mistakes that
> were, say, posted on my page, fixed for the 4th edition. He didn't fix the
> much more serious logic flaws introduced by his unwillingness to comprehend
> how end-of-file conditions are handled in C.
>
> And that's the thing. Errata would be one thing. But if every example I
> read using feof() used it incorrectly, and multiple examples of how to do

In Herb's defense, I'd say that intelligent people find it hard to
treat mistakes (such as the design of feof) with respect, and enough
to remember the deviant implementation that feof is. Herb's failure to
recall to mind a massive boner means he's an intelligent person.
Whereas nasty little clerks (who as we saw this morning make their own
stupid mistakes, but expect to be forgiven) take a sour delight in
"learning" clap trap.

This isn't programming, Seebach. It's Trainspotting.

An intelligent programmer, when confronted with the incredibly poor
design of feof, turns right around and changes feof into a simple
macro:

#define READ(f) (attemptToRead(f), feof(f)) ? 0 : -1 // Change
attemptToRead to fgetc, fgets, etc.

He then can forget the design error, which is normalized deviance from
hell, since it forces the program to try to read SOMETHING to detect
IO. On any number of environments, this can change the state of the
underlying hardware in unpredictable ways. Even if the hardware can
signal to the runtime "don't you dare try to read from me, I have
nothing for you now", the C runtime HAS TO READ, which can easily
throw off auditing software or firmware, recording in all cases one
extra read.

Someone late at night has then to remember, while nodding weak and
weary, that oh yeah, this is a C program.

How many ruined marriages, late nights, alcoholic benders, and
suicides has this caused? How many little, stunted, substance abusing
and creepy personalities has this caused? And why do people think that
knowing these coding horrors is anything but an expense of spirit in a
waste of shame?

Herb should have done a better job, but the error is so common among
good programmers and intelligent people so as to cast the aspersion on
C and standards committee members too cowardly and incompetent to fix
it.

In case you hadn't noticed, the only reason for using a programming
language is to make programming intellectually manageable. The blame
lies upon the designers of C, and you had NO STANDING in pretending to
be more qualified than Herb Schildt, and advance your career without
suitable academic preparation thereby. You should have been taking
evening classes in comp sci. You especially have NO STANDING in light
of your own frequent errors.

The intended meaning of "C: The Complete Nonsense" was "look at me, I
am more qualified than Herb Schildt". But your errors in this thread,
and your failure to post decent code, means that you are far LESS
qualified.

You blame Herb for not publishing errata. New editions trump errata.
Sure, he should have fixed the bug: but what about the refusal of the
C standardizers to reform the numerous errors in C? I'd say this is
the greater crime, because again, the only reason for using a high
level language is to make problems intellectually manageable.

I've shown that this is possible in C with the replace() example this
week. My solution (and only my solution) showed aspects of the
problem which other solutions concealed. Had I been Herb, I would have
addressed the feof() issue head-on, but I'm not, and it may be that he
didn't want to confuse his readers.

But in light of how frequent feof() errors are (see the first Google
hit for "feof C" at http://www.cplusplus.com/reference/clibrary/cstdio/feof/:
it warns about the behavior of this turkey and then has a code sample
with the classic error), it was in fact libel for you to try to make
this global and normalized deviance stick to Schildt.

You have TWICE in the past week posted trivial code snippets with
errors (%s and off by one strlen). You had NO STANDING ten years ago,
and you have NO STANDING now in talking about other people's errors,
especially because with regards to McGraw Hill and here, you act like
an infant, refusing to work collaboratively and compassionately with
others while expecting us to have compassion for your oh-so-precious
and oh-so-unique personality disorders.

You need to WITHDRAW and APOLOGIZE FOR the "C: The Complete Nonsense".
NOW.

> input loops used feof() incorrectly, that suggests to me that these are not
> merely "stupid mistakes" (fencepost errors, typos, etcetera), but a genuine
> failure to comprehend something which I think can be reasonably regarded as
> fairly basic.

This is your self-serving interpretation. However,

* Posting a solution that is supposed to replace %s and replaces
instead all percents and the character following them, which may cause
a memory fault,

* Posting a strlen replacement which managed to be off by one in a
few short lines of code,

* Claiming that "the 'Heap' is a DOS term",

* Consistently asking forgiveness for errors whilst uncharitably
withholding it from colleagues,

* Being ignorant of the use of concrete memory layouts of stacks and
heaps in classrooms to explain how runtimes work,

* Throwing away email from Apress colleagues unread, and calling them
"morons" and impugning their credibility and sanity online

indicates a far more troubling personality.

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

== 2 of 4 ==
Date: Sun, Feb 14 2010 9:23 am
From: spinoza1111

On Feb 14, 8:21 pm, i...@localhost.claranet.nl (Ike Naar) wrote:
> In article <f3dd4ed8-600b-44cc-8f01-4ae6b910a...@l24g2000prh.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> >"You talk like a fag, and you're shit's all fucked up." - Idiocracy,
> >Mike Judge, 2005
>
> Paraphrasing again?
> "You talk like a fag, and your shit's all retarded" - Idiocracy,
> Mike Judge, 2006

Yes, correction accepted. I also screwed up the grammar. Your, not
you're.

== 3 of 4 ==
Date: Sun, Feb 14 2010 9:30 am
From: cri@tiac.net (Richard Harter)

On Sun, 14 Feb 2010 02:15:15 -0800 (PST), spinoza1111
<spinoza1111@yahoo.com> wrote:

>On Feb 14, 7:05=A0am, c...@tiac.net (Richard Harter) wrote:
[snip]
>
> At some point in the distant past, Harter, you were able to
> write competent code, for I saw an old 1990 program of yours
> that was competent. I think you are now some sort of
> manager

Chortle. Excuse me while I go whip some slaves, er,
admonish the programming staff.

> who is today unable, unlike me, to crank this level
> of code in the time I took...about two hours for the first
> version, and a total of 8..10 hours thereafter.

I certainly hope that I am never able to crank out that
level of code, regardless of the time it takes.

[snip]

>>
>> (10) Only one of strNew, strNewStart is needed.
>
>You don't know what you're talking about, and you have not diligently
>or adequately studied the code. strNew is needed to index through the
>new string, whereas we need to return strNewStart.

You are right. Mea culpa.
>
>"Never defined Index variables" is gibberish.

Well, no, it's not. In the C standard "defined" has a very
specific, parochial meaning. More generally, however, the
definition of a variable is a description of its usage in the
code. A comprehensive definition includes such things as the
invariants and constraints associated with the variable, and the
kind of things it represents.

There seldom is a need for elaborate definitions. Often none is
wanted. Often, however, the presence of an explicit definition
makes a lot of difference, both in reading the code and writing.
The absence of explicit definitions can lead to nasty, obscure
bugs.

It occurs to me that you did not recognize "Index variables" as
shorthand for the variables named ptrIndex0, etc. If that is
what you were on about, that was what was meant.

== 4 of 4 ==
Date: Sun, Feb 14 2010 9:44 am
From: Seebs

On 2010-02-14, Richard Harter <cri@tiac.net> wrote:
> On Sun, 14 Feb 2010 02:15:15 -0800 (PST), spinoza1111
><spinoza1111@yahoo.com> wrote:
>> who is today unable, unlike me, to crank this level
>> of code in the time I took...about two hours for the first
>> version, and a total of 8..10 hours thereafter.

> I certainly hope that I am never able to crank out that
> level of code, regardless of the time it takes.

And I certainly hope I never reach a point where a ten-minute project
takes two hours to write and maybe 8-10 hours thereafter to produce an
elaborate, complicated, inefficient, version which we still aren't totally
sure works.

==============================================================================
TOPIC: Draft paper submission deadline is extended: SETP-10, Orlando, USA
http://groups.google.com/group/comp.lang.c/t/d93be6b44bc34544?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 14 2010 12:30 pm
From: James Heralds

It would be highly appreciated if you could share this announcement
with your colleagues, students and individuals whose research is in
software engineering, software testing, software quality assurance,
software design and related areas.

Draft paper submission deadline is extended: SETP-10, Orlando, USA

The 2010 International Conference on Software Engineering Theory and
Practice (SETP-10) (website: http://www.PromoteResearch.org) will be
held during 12-14 of July 2010 in Orlando, FL, USA. SETP is an
important event in the areas of Software development, maintenance, and
other areas of software engineering and related topics.

The conference will be held at the same time and location where
several other major international conferences will be taking place.
The conference will be held as part of 2010 multi-conference
(MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in
Orlando, Florida, USA. The primary goal of MULTICONF is to promote
research and developmental activities in computer science, information
technology, control engineering, and related fields. Another goal is
to promote the dissemination of research to a multidisciplinary
audience and to facilitate communication among researchers,
developers, practitioners in different fields. The following
conferences are planned to be organized as part of MULTICONF-10.

• International Conference on Artificial Intelligence and Pattern
Recognition (AIPR-10)
• International Conference on Automation, Robotics and Control
Systems (ARCS-10)
• International Conference on Bioinformatics, Computational Biology,
Genomics and Chemoinformatics (BCBGC-10)
• International Conference on Computer Communications and Networks
(CCN-10)
• International Conference on Enterprise Information Systems and Web
Technologies (EISWT-10)
• International Conference on High Performance Computing Systems
(HPCS-10)
• International Conference on Information Security and Privacy
(ISP-10)
• International Conference on Image and Video Processing and Computer
Vision (IVPCV-10)
• International Conference on Software Engineering Theory and Practice
(SETP-10)
• International Conference on Theoretical and Mathematical Foundations
of Computer Science (TMFCS-10)

MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a
full-service resort that puts you in the middle of the fun! Located
1/2 block south of the famed International Drive, the hotel is just
minutes from great entertainment like Walt Disney World® Resort,
Universal Studios and Sea World Orlando. Guests can enjoy free
scheduled transportation to these theme parks, as well as spacious
accommodations, outdoor pools and on-site dining — all situated on 10
tropically landscaped acres. Here, guests can experience a full-
service resort with discount hotel pricing in Orlando.

We invite draft paper submissions. Please see the website
http://www.PromoteResearch.org for more details.

Sincerely
James Heralds

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

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

Sunday, February 14, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts