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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: question
http://groups.google.com/group/comp.lang.c/t/4c7d70ccf9ccb9d9?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Apr 11 2010 12:07 am
From: Seebs

On 2010-04-11, Abdulmalik Muhammad <deskuuul@gmail.com> wrote:
> Hi, my name is Abdulmalik Muhammad Yusuf and my question
> is..................................
> what is array in c programming lang?

Ask your instructor, or buy the textbook.

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

== 2 of 3 ==
Date: Sun, Apr 11 2010 1:22 am
From: Keith Thompson

Abdulmalik Muhammad <deskuuul@gmail.com> writes:
> Hi, my name is Abdulmalik Muhammad Yusuf and my question
> is..................................
> what is array in c programming lang?

Please tell your instructor and fellow students at IUT that asking
elementary questions like this in a newsgroup is a very bad way to
learn the language, and that those of us who actually participate in
the newsgroup are becoming quite annoyed.

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

== 3 of 3 ==
Date: Sun, Apr 11 2010 1:27 am
From: J de Boyne Pollard

> Hi, my name is Abdulmalik Muhammad Yusuf and my question
> is..................................
> what is array in c programming lang?

It's like an array in other programming languages, but different.
It's exceptionally not like arrays in the islands of Indonesia. It's
not like a boiled egg; although if it's an array of unsigned char it
is not only guaranteed to be quite filling but helpful when dealing
with boiled eggs, especially if you are exchanging your boiled eggs
with other people by sending them along wires (or, nowadays, magically
through thin air). It's sometimes like the queues at the post office,
but only if you aren't an old fogey that hates modern glitz and you
are happy about using the word "stack" in polite company. It's not
like an array in the C++ programming language, except when it is,
because it's not one of those classy things that can be bought from a
Tupperware catalogue (into which one can of course put boiled eggs).
Sometimes, it only looks like an array, but in fact is only a pretend
array that someone has argued you into receiving, and is sizeably
different from the real thing. And it's always like the piers at
Brighton, except without the railings.

You'll know when you've become a C/C++ programmer, because you'll come
back to the above and realize that in fact it made sense.

==============================================================================
TOPIC: lvalues and rvalues
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Apr 11 2010 12:20 am
From: J de Boyne Pollard

> > For what it's worth: Several authorities consider "whether or not"
> > to be synonymous with "whether", and the "or not" to be, as M.
> > Uno might have been enquiring, superfluous.
>
> In informal English, or in formal technical English?

The authorities that I've seen don't make a distinction
when talking about "whether or not".

> In formal technical English, saying "whether or not"
> clearly removes a possible ambiguity; [...]

What ambiguity?

> For example, we can know for sure that a given
> program has no uninitialized variables, but we
> can't always know for sure that a program
> _doesn't_ have uninitialized variables.

You've just apparently said the same thing twice
("has no uninitialized variables" "does not have
uninitialized variables") and cast the twain as
opposites. Did you make a typing error there?

==============================================================================
TOPIC: Test of a preprocessor symbol defined as nothing vs. zero
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Apr 11 2010 12:56 am
From: Mark Adler

On 2010-04-10 17:22:35 -0700, Seebs said:
> On 2010-04-11, Mark Adler <madler@alumni.caltech.edu> wrote:
>> However I'd wonder if there won't be a compiler that would complain
>> about "-+1" as an expression.
>
> Why would it? - - - - - - - - - - - 5 is a perfectly valid expression.

I wasn't worried about the minus, I was worried about the plus. Unary
plus was not always valid in C. K&R and the old Sun C didn't allow it.

Mark

== 2 of 4 ==
Date: Sun, Apr 11 2010 1:07 am
From: Mark Adler

On 2010-04-11 00:56:48 -0700, Mark Adler said:
> I wasn't worried about the minus, I was worried about the plus. Unary
> plus was not always valid in C. K&R and the old Sun C didn't allow it.

Oh, wait. Then there's an easy fix:

#if -FOO - -1 == 1

Should do the same thing, where - - -1 is clearly valid. Testing ...
and ... it works!

Thank you all for your help. This looks like the most portable solution.

Mark

== 3 of 4 ==
Date: Sun, Apr 11 2010 1:25 am
From: Keith Thompson

Mark Adler <madler@alumni.caltech.edu> writes:
> On 2010-04-10 17:22:35 -0700, Seebs said:
>> On 2010-04-11, Mark Adler <madler@alumni.caltech.edu> wrote:
>>> However I'd wonder if there won't be a compiler that would complain
>>> about "-+1" as an expression.
>>
>> Why would it? - - - - - - - - - - - 5 is a perfectly valid expression.
>
> I wasn't worried about the minus, I was worried about the plus. Unary
> plus was not always valid in C. K&R and the old Sun C didn't allow it.

Unary + was introduced by ANSI in the C89 standard. If you're using a
compiler so old that it doesn't support it, then it doesn't conform to
*any* standard, and you're likely to have worse problems than that.

== 4 of 4 ==
Date: Sun, Apr 11 2010 4:46 am
From: Ben Bacarisse

Mark Adler <madler@alumni.caltech.edu> writes:

> On 2010-04-11 00:56:48 -0700, Mark Adler said:
>> I wasn't worried about the minus, I was worried about the plus.
>> Unary plus was not always valid in C. K&R and the old Sun C didn't
>> allow it.
>
> Oh, wait. Then there's an easy fix:
>
> #if -FOO - -1 == 1
>
> Should do the same thing, where - - -1 is clearly valid. Testing
> ... and ... it works!
>
> Thank you all for your help. This looks like the most portable
> solution.

If you are really trying to get something that works for pre-ANSI C then
you need to remember that K&R C does not say what happens in case A
where FOO is not defined. At least +1 will generate an error message on
such systems. In some K&R C implementations, undefined FOO may be
treated as if FOO were defined to be empty (though, to be honest, I
can't remember any particular behaviour).

--
Ben.

==============================================================================
TOPIC: C the complete nonsense
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Apr 11 2010 1:52 am
From: Malcolm McLean

On 11 Apr, 07:37, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
wrote:
> > > If what you say is right then we've actually discovered
> > > something very interesting. The books sell well, and are
> > > into edition 4. So either there are a lot of deluded
> > > people out there, or technical accuracy really isn't so
> > > important in a programming book.
>
> > That's an easy one. There are a lot of deluded people out
> > there.
>
> I disagree. One doesn't necessarily know that a book is
> poor, or at least not what one thought it to be, when one
> buys it. The choices set forth by M. McLean are not
> exhaustive, and are really a false dichotomy.
>
If you sell something under false pretences then of course you get a
few sales. But Schildt is the best-selling C author. His sales go into
the millions. It's most unlikely that so many people are buying the
book on the basis of its cover, then regretting their purchase. And
it's not as if the anti-Schildt lobby is being censored - I've tried
to find a positive review of the book from a notable name, and so far
failed. The books must be valuable to the people who buy them.

You're right, however. it's not really a dichotomy - mass delusion
versus the books are valuable - there might be another explanation.
It's just that no obvious one presents itself.

== 2 of 4 ==
Date: Sun, Apr 11 2010 2:24 am
From: Willem

Malcolm McLean wrote:
) If you sell something under false pretences then of course you get a
) few sales. But Schildt is the best-selling C author. His sales go into
) the millions. It's most unlikely that so many people are buying the
) book on the basis of its cover, then regretting their purchase. And
) it's not as if the anti-Schildt lobby is being censored - I've tried
) to find a positive review of the book from a notable name, and so far
) failed. The books must be valuable to the people who buy them.
)
) You're right, however. it's not really a dichotomy - mass delusion
) versus the books are valuable - there might be another explanation.
) It's just that no obvious one presents itself.

Most people who buy the book are those who wisth to learn C, and are
therefore inherently unqualified to judge the quality of the book.

This would, of course, imply that there are millions of people out there
who now make the same mistakes as Schildt does. Which makes sense, given
the poor average quality of C code floating around.

I work at a large company. One of the languages used is C. I have
not gone through all the code in detail, but thus far I have fixed one
program that had intermittent failures, because it was using a
while(!feof()) loop. Most of the times, it worked, by sheer luck.

I have also seen lots of other errors involving a basic misunderstanding
of C.

Now, I wonder if those people learned C from Schildt's books, but in
any case it's a good data point for the existence of a lot of people
who don't know C well enough to judge a book on the subject.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

== 3 of 4 ==
Date: Sun, Apr 11 2010 5:19 am
From: Colonel Harlan Sanders

On Sat, 10 Apr 2010 23:24:41 -0700 (PDT), J de Boyne Pollard
<J.deBoynePollard@Tesco.NET> wrote:

>> >There you go. You actually *did* know that this
>> >sort of thing doesn't work in practice before you
>> >asked why I didn't use it.
>>
>> Sorry to butt in, but why do you say that Tinyurl
>> (or any of several similar services) "doesn't work
>> in practice"?
>
>Because the next step in the silly dance is all of the people
>complaining "I/my network administrator/my company refuse to
>follow URLs from TinyURL, because the text displayed in my
>status bar doesn't show what WWW page I'll actually end up
>at.". And the step after that is where they tell you at
>length why preview mode is just as bad. If you've been
>through the dance often enough, as I have, you'll recognize
>the steps.
>
>Get yourself a WWW site whose URLs are necessarily quite
>long, put helpful content on it, and try pointing people
>to it for a decade or so. You'll find that the belligerent
>silliness of M. Thompson here, trying to make out that xe's
>been mortally offended by simply being no more than pointed
>towards something that would actually help xem, is but one
>example of the many creative ways that humans have found to
>react stupidly to being helped. (-:
>
>> but your alternative of not giving an address at all
>
>That's not my alternative. As *noted in the original posts*,
>I sent hyperlinks to the people concerned *right at the
>start* -- before posting, even. You're thinking of the
>alternative of the people who don't believe in using the
>right tools for the job, such as hypertext for hyperlinks,
>of whom am I not one.

You didn't send the address to me. And anyone who happens across this
post in the future would also be left out of the loop. And many
people, myself included, do not advertise their email address on
Usenet.
If you only want to communicate with select group of "people
concerned", then do the whole thread by email rather than making a
puzzle out of the Usenet thread.

>> Of course, your quote of the longer URL above was mangled
>> by Google.
>
>Exactly. And it will be mangled by NUAs that word-wrap it
>in quotations, mangled in Usenet gateways, mangled in
>archives of Usenet postings accessible from the WWW, and
>mangled by programs that "helpfully" do things like
>replacing slashes, minus signs, and other characters in
>URL-like text with various kinds of quoting sequences.
>You should see some of the broken incoming links that
>Google Webmaster Tools reports pointing to my WWW pages.
>And those are just the ones where the breakage has
>occurred far enough into the URL to miss the domain names
>and account names.
>
>Ask yourself this: Do we give out hyperlinks with the
>intention that people are able to follow them and read
>what is hyperlinked to, or just to decorate postings?
>Only in the latter case does it not matter that people
>reading the post, and quotes of the post, and copies of
>the post on WWW sites, will get something mangled and
>unusable.
>
>And that's even discounting all of the
>but-that-hyperlink-doesn't-work-for-me timewasting that
>occurs.

You've wasted far more time in this long justification for your
refusal to post links in Usenet posts, despite several simple and
reliable methods being suggested.

1) Just paste the damn link as-is. If it gets broken by your Usenet
agent (Google?), I'm sure readers of this group will be able to
repair it.
1a) Break the URL yourself into 40 character lines and advise the
reader to paste them together.
2) Use TinyUrl, or any similar service; or a Pastebin.
3) Add a note that if anyone has a problem with the URL to email you,
since you seem to be happy to do that.

And many other methods; all of which would be easier both for you and
the readers than finding email addresses and sending a URL out of
band.

>> >> (I have no idea why there's a "." after the
>> >> ".com", but it seems to work anyway.)
>>
>> >There's a Frequently Given Answer on that, too.
>> >CIS URLs are subject to search path spoofing.
>>
>> Okay, I'm sure this is a stupid question, but
>> what is a "CIS URL"? You don't appear to be in
>> Russia....
>
>Go to the Frequently Given Answer that you already
>know about, hit your WWW browser's "Up" button on
>its navigation toolbar, scroll down in the index
>to the World Wide Web section, and read the FGA
>mentioned above.

Thanks, but I didn't really expect that a FAQ on DOS EOF markers would
be related to Whatever the Hell CIS URLs are, so I did not look at the
rest of that site. From the snarky tone of your reply I suspect now
that when you say "Frequently Given Answer" that you are in fact
referring to your website, not a generic "Frequently given answer",
if so, WHY NOT SAY SO?

>Or put "CIS URLs" into Google Web, where you'll
>find the FGA usually on the first page of results.

Again, thanks a bunch.
I actually have heard of Google. I did search for "CIS URL" and found
nothing enlightening. Of course, "CIS URLs" does give your link.
Everything is so clear when you already know what the answer is and
where to look.

So while I do appreciate the information you provide, it does seem
that you make giving a URL into a needlessly dramatic and complex
affair.
Are you actually trying to be helpful, or looking for an opportunity
to sneer at people for not knowing how to decipher your references?

== 4 of 4 ==
Date: Sun, Apr 11 2010 5:33 am
From: Richard Heathfield

Malcolm McLean wrote:
<snip>

>>
> If you sell something under false pretences then of course you get a
> few sales. But Schildt is the best-selling C author. His sales go into
> the millions. It's most unlikely that so many people are buying the
> book on the basis of its cover, then regretting their purchase.

They may never learn enough about C to realise that they ought to be
regretting their purchase.

> And
> it's not as if the anti-Schildt lobby is being censored - I've tried
> to find a positive review of the book from a notable name, and so far
> failed. The books must be valuable to the people who buy them.

Every week, millions of people buy lottery tickets that turn out to be
valueless. Simply because many people do something, that doesn't mean
it's a sensible thing to do.

> You're right, however. it's not really a dichotomy - mass delusion
> versus the books are valuable - there might be another explanation.
> It's just that no obvious one presents itself.

The most obvious explanation is Sturgeon's Law.

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

==============================================================================
TOPIC: C progreamming
http://groups.google.com/group/comp.lang.c/t/fc9113386afdfc9b?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Apr 11 2010 2:09 am
From: Phil Carmody

Keith Thompson <kst-u@mib.org> writes:
> saif raihan <saifraihan.lc@gmail.com> writes:
>> Hi,
>> I am Saif Raihan. Ihave a question:
>>
>> " What is String?"
>>
>>
>> Any answer will be granted.
>
> Let me guess: you're a student of IUT.

Resolves to Bangladesh.

To the O/P - if you have access to the internet, then you must
presume your instructor has access to the internet too, and
will see you not doing your work. There are plenty of online
resourses for you to read that will contain all the answers
to such questions, such as Steve Summit's C FAQ. Read those
*before* asking silly questions please.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 2 of 2 ==
Date: Sun, Apr 11 2010 4:53 am
From: Nick Keighley

On 10 Apr, 14:10, saif raihan <saifraihan...@gmail.com> wrote:
> Hi,
> I am Saif Raihan. Ihave a question:
>
> " What is String?"
>
> Any answer will be granted.

stay awake in lectures

==============================================================================
TOPIC: Generic linked list with internal storage?
http://groups.google.com/group/comp.lang.c/t/d36ff63bef634bcc?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Apr 11 2010 2:16 am
From: Phil Carmody

Willem <willem@turtle.stack.nl> writes:
> jacob navia wrote:
> ) Which of
> )
> ) strcpy(dst,src);
> )
> ) or
> ) for (int i = 0; i<=strlen(src);i++) // [I added an 'i']
> ) dst[i] = src[i];
> )
> ) is clearer?

Given that they do different things, you can't compare clarity.

> You're missing the point, which would have been illustrated
> by the following:
>
> Which of
>
> strcpy(src, dst);
>
> or
>
> for (i = 0; dst[i] != 0; i++)
> src[i] = dst[i];
>
> is clearer ?

Well, both clearly have issues, so does that make them
equally clear?

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 2 of 4 ==
Date: Sun, Apr 11 2010 3:13 am
From: jacob navia

Phil Carmody a écrit :
> Willem <willem@turtle.stack.nl> writes:
>> jacob navia wrote:
>> ) Which of
>> )
>> ) strcpy(dst,src);
>> )
>> ) or
>> ) for (int i = 0; i<=strlen(src);i++) // [I added an 'i']
>> ) dst[i] = src[i];
>> )
>> ) is clearer?
>
>
> Given that they do different things, you can't compare clarity.
>

Step 0: The first character of src is copied into dst. If src
has length zero, the terminating zero is copied
Step 1: If the length of the source is greater than zero
the second character is copied.

etc

You are wrong (again) carmody.

Note the <=, that means that the terminating zero is copied.
Note that neither src nor dst are touched: they point always to
the start of the source and destination buffers.

== 3 of 4 ==
Date: Sun, Apr 11 2010 4:45 am
From: pete

Phil Carmody wrote:
>
> Willem <willem@turtle.stack.nl> writes:
> > jacob navia wrote:
> > ) Which of
> > )
> > ) strcpy(dst,src);
> > )
> > ) or
> > ) for (int i = 0; i<=strlen(src);i++) // [I added an 'i']
> > ) dst[i] = src[i];
> > )
> > ) is clearer?
>
> Given that they do different things, you can't compare clarity.
>
> > You're missing the point, which would have been illustrated
> > by the following:
> >
> > Which of
> >
> > strcpy(src, dst);
> >
> > or
> >
> > for (i = 0; dst[i] != 0; i++)
> > src[i] = dst[i];
> >
> > is clearer ?
>
> Well, both clearly have issues, so does that make them
> equally clear?

You got it backwards.
jacob navia's for loop, does what strcpy does.

Willem's for loop, doesn't write a null byte.

--
pete

== 4 of 4 ==
Date: Sun, Apr 11 2010 5:40 am
From: Eric Sosman

On 4/10/2010 6:10 PM, ImpalerCore wrote:
> [...]
>>> But for
>>> a plain vanilla linked list ... Why bother?
>>
>> Generally, true. I don't even consciously notice adding a small
>> list implementation -- it's too trivial to notice.
>
> I'm curious what you consider a plain vanilla linked list?

I'll assume a basic familiarity with the notions of "list"
and of "link" (if these are lacking, ask any IUT student). As
expressed in C, a list's nodes are usually structs because this
is a convenient way to package payload and link(s) together in
one easily-managed blob. Each node contains a link to its
successor and perhaps also to its predecessor. The links are
usually struct pointers, sometimes array indices (if all the
nodes inhabit a single array), with a null pointer (or a special
index value) indicating "no successor/predecessor." There'll
also be some metadata: At the very least, a link to the list's
first node and often a link to the last as well (sometimes a
pointer-to-struct, sometimes a pointer-to-pointer-to-struct).
The metadata may be free-standing, or may inhabit a special
"list header" (especially for a circular list).

I'd consider the variations covered by the above to be
"plain vanilla" linked lists. Programmers should be familiar
with -- and comfortable with -- the basic operations of inserting,
deleting, searching, and traversing such lists. These operations
are so basic, in my view, that hiding the details away behind an
interface is (1) overkill and (2) obfuscatory. It makes about
as much sense to me as

int fetchFromIntArray(const int *array, size_t index) {
return array[index];
}
void storeIntoIntArray(int *array, size_t index, int value) {
array[index] = value;
}

What things might change a list's flavor to something other
than vanilla, to some flavor that might justify more opacity? A
non-exhaustive, er, list:

- Unusual links. If the links are self-relative offsets (as
might be used in lists shared between processes that map them
to different virtual addresses), or if the stored values are
the XOR of a forward and backward link, or some other odd
encoding is used, link manipulation may become intricate
enough to justify being packaged away somewhere.

- Bit-diddling. If the bits of the links' representation are
twiddled to encode additional information (e.g., by using
a few low-order "known to be zero" bits as flags), it's
probably best to put the encoding and decoding out of sight
somewhere. (The writers of LISP interpreters seem particularly
attracted to such techniques.)

- Peculiar nodes. If the list nodes are not structs, there's
usually something slightly exotic going on, worthy of being
hidden from us easily-scandalized maiden aunts.

- Mammoth metadata. If a list carries more than the usual
amount of metadata -- a node count, a link to the node most
recently inserted (at whatever position), a link to the node
at the midmost position, whatever -- it's probably best to
let a function package take care of the maintenance.

- Additional linkage. If there are additional links, as in
a skip list or some such, the burden of maintaining them
grows to the point where pre-packaging becomes justifiable.

... and so on. However, it doesn't seem to me that a "generic"
package is what's needed for this sort of thing; the oddities are,
well, odd, and not easily generified. If you've got a list in
shared memory, using self-relative links whose low-order bits
encode extra information about the pointed-to nodes, you'll most
likely write a few functions to manage lists of exactly that
description; the IUT Senior Thesis Generic List Package simply
won't suffice.

> Perhaps if
> you could describe the vanilla list feature subset, maybe by listing
> functions of an existing implementation like GLib or the C++ STL list,
> or is there even a function interface to it?

I'm not intimate with GLib, and I have an irrational dislike
for all things C++, so I'll take a pass on this one.

> Do you feel that adding a c_compare_function_t makes it a 'chocolate
> twist with jimmies' linked list?

Sorry; I don't even know what a c_compare_function_t might be.

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================
TOPIC: In the Matter of Herb Schildt: a Detailed Analysis of "C: The Complete
Nonsense"
http://groups.google.com/group/comp.lang.c/t/caf17fab4e7d8530?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Apr 11 2010 3:11 am
From: blmblm@myrealbox.com

In article <slrnhs1d64.qt9.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-04-10, blmblm myrealbox.com <blmblm@myrealbox.com> wrote:
> > It might be worth asking whether anyone knows which form is preferred
> > for (Mac) OS X -- I mean, supposedly it's "UNIX under the hood", and
> > certainly in my limited experience it has a text-mode interface that
> > feels very much like other UNIX systems I've used, aside from the
> > fact that the default filesystem setup is apparently case-insensitive.
>
> Under the hood:
> * OS X is plain old UNIX for such purposes.

And for other purposes -- not so much?

But yeah, nice to have agreement here.

What I *have* noticed is that the OS X systems I've worked with
sometimes have the BSD versions of particular tools rather than
than the GNU versions, and sometimes that matters, and that they
don't have Linux-specific tools, and sometimes *that* matters.

But then, that's UNIX for you, right? Multiple different versions,
all *more or less* the same, but sometimes subtly different. :-)?
or maybe it's a :-(.

> * Actually, the default filesystem is case-preserving, which is subtly
> different.

That *is* a better term for how I understand things to work --
case is *preserved* in filenames, but ignored in deciding whether
two names refer to the same file (e.g., one can't have both a
"Foo" and a "foo" in the same directory). This can make things
interesting when one tries to copy files in bulk from a "real UNIX"
filesystem to an OS X filesystem.

> * OS 9 did, in fact, have at least one kind of application which did not
> have any capacity for a meaningful return value. When targeting such
> applications, it was a "freestanding implementation", since it did not
> provide relevant hooks for a large number of standard library features;
> if you wanted a hosted implementation, you could also get one, and in
> that, main() returned int just like everywhere else.

Interesting data point.

> > I don't quite understand who you're saying stole from whom here,
> > but whatever. (I'm also not sure why you spell the Linux
> > originator's name with a y, when no one else seems to, but
> > "whatever" on that too.)
>
> I think it's just that he can't spell.

But it doesn't matter! because orthography is not .... Yeah,
yeah, sorry. Well, I guess it's not uncommon to think that the
things we do well are important, while the things we do less
well aren't.

> > If it were only Linux, maybe not -- but it's not, as discussed
> > previously.
>
> Most significantly, it's also DOS. DOS batch files can depend on the
> values returned from programs. Programs which don't return a value tend
> to produce arbitrary results.

Another interesting data point, and as you say more significant.

> >> My sexism is ironic. Real malice, of the sort shown Kenny, Navia,
> >> Schildt, Chinese visitors and myself, as well as competent female
> >> programmers, is my concern here.
>
> > I have no idea what "ironic" means here.
>
> It means "ha ha only serious". (See the Jargon file.)

In case it wasn't clear -- I wasn't asking what "ironic" means in
general (I know that!) but how it applies in this context. Does
that change your answer .... <shrug>

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

== 2 of 3 ==
Date: Sun, Apr 11 2010 3:12 am
From: blmblm@myrealbox.com

In article <slrnhs1d71.qt9.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-04-10, blmblm myrealbox.com <blmblm@myrealbox.com> wrote:
> > In article <165bc196-c803-4a16-9099-da444354a2c6@x20g2000yqb.googlegroups.com>,
> > rigs <rigorist@gmail.com> wrote:
> >> On Apr 8, 5:23 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> >> > On Apr 7, 8:24 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> >> Who knew the Frankfurt School offered degrees in Internet Kookery?
>
> > Say what? Often GIM[*]F, but not in this instance. ?
>
> > [*] My.
>
> http://en.wikipedia.org/wiki/Frankfurt_School

I wonder why I didn't find that myself. (Could Google somehow
know that sometimes I criticize, however mildly, their GG
archive-searching and Usenet-posting services?! Nah, sheer
paranoia .... :-)? )

> Accurate enough summary, I think. :P

If you say so! I admit I found the first few paragraphs slow
enough going that I bailed out, though I did recognize some names.
Maybe I'll try again at some point. Apparently some of the
enthusiasm I had for non-STEM subjects as an undergraduate has
evaporated over the years. :-(

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

== 3 of 3 ==
Date: Sun, Apr 11 2010 4:19 am
From: Nick <3-nospam@temporary-address.org.uk>

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:

> It may be that all(?) of the ways of invoking a program in a
> Windows environment ignore its return value. This is not the
> case in all operating systems:

It isn't - you can use "errorlevel" in a batch file to check the return
value.

> And didn't JCL for the venerable IBM OS/VS operating system(s) use
> the value returned by a called program to control execution flow?
> That's how I remember it anyway.

I'm pretty sure you're right here.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: weird problem with strcmp()
http://groups.google.com/group/comp.lang.c/t/701c12c082eb3aa7?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Apr 11 2010 3:16 am
From: Nick <3-nospam@temporary-address.org.uk>

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

> On 2010-04-03, TheGist <thegist@nospam.net> wrote:
>> Seebs wrote:
>>> On the systems I've used that function on, it was also accessible from
>>> <string.h>.
>
>>> But I wouldn't usually use it, just because of the portability issues.
>
>> The OP was just playing around with some toy problem.
>
> Yup.
>
>> Why bother harping about "portability"?
>
> Because sloppy work is habit forming.
>
>> What does that even mean in this case?
>
> It means that if you get in the habit of writing code which relies on
> non-portable things without good justifications, you will spend more
> time dealing with the aftermath later, usually at the least convenient
> possible time.
>
>> Surely bzero is available on windows(cygwin), mac os x,
>> and any modern *nix variant.
>
> We were talking about strcasecmp(), which is not as widely available
> as you might think -- largely because, while the functionality is common,
> some systems call it stricmp().

Which is why my messy-bits-of-stuff file has caseless_strcmp #defined to
one or the other. If you don't have either you can write your own, of
course. I also keep in the right part of the namespace, and have a more
meaningful name as well (the one thing that strcasecmp isn't is "case").

I actually use autoconf to find out which is around, but just doing it
by hand is a big step forwards.

It took me years to realise the benefits of these sorts of things.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: Son of Snarky Tirade: a response to Seebach's new CTCN: part 1
http://groups.google.com/group/comp.lang.c/t/383e6d5a95dc3f75?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Apr 11 2010 4:24 am
From: spinoza1111

This is my reply (part 1) to Peter Seebach's new edition of "C: the
Complete Nonsense" at http://www.seebs.net/c/c_tcn4e.html. Further
parts of my complete reply will be forthcoming.

Introduction

"Back in 1996, having heard horror stories about Herbert Schildt's C:
The Complete Reference, I decided to check it out. I flipped the book
open; I found glaring errors. I paged through it. I found more glaring
errors. In short, the book had lived up to the hype; it was awful.
Being a pedantic sort, and having just recently started having a web
site, I wrote about it, in the previous version of this page."

I'm afraid that this matter, for Seebach, has remained for fourteen
years, a parlor game. Literate people tend not to "flip books open"
and find "errors" so readily unless they are experts in their fields,
and for the most part not even then; and Seebach is no such expert. He
has, by his own admission, taken no computer science classes and has
no academic certification. Instead, he has held a sequence of jobs as
a programmer, specializing in unix-Linux, which disqualifies him from
commenting on a book directed at all C programmers. He also served on
the C99 standard.

Schildt's book is not great, but we know that some C programmers find
it useful. Schildt's book contains errors, but they often manage to be
useful errors.

But the issue is not Schildt. It is Seebach's behavior, which is
obsessive and stalking but "rational" in that Seebach seems to be
stalking Schildt in a zero-sum game where he has tried to establish a
reputation as a good programmer, which we now know is unwarranted, by
destroying another person's reputation.

This type of behavior creates software crises and, as seen in many
American programmers, has destroyed their productivity, since most
American programming environments are characterized by Seebach's
behavior. It is normed deviance.

"Time passed. People forgot about it. A 4th edition of the book came
out (back in 2000), but I didn't even know this. Until, more recently,
I started hearing queries and concerns. My half-baked page, thrown
together in an afternoon, had become the topic of Fearsome Disputes.
People were arguing over whether it was any good. Worse, people were
arguing that the flaws (and there are some, certainly) in my web page
somehow showed that the book wasn't utter crap."

No, Peter. We found that the flaws on the page and in the code you
submitted to clc in recent years means that you have no standing as a
critic. This means you are stalking.

We discovered that you constantly make very basic errors; you cannot
use switch() statements in a structured fashion, you cannot write a
one-line version of strlen without an off by one error. In writing,
you are very clumsy with words: whereas a careful writer would use
"apparently clear" owing to the received usage of "clear" [1], you
called Schildt "clear" which was to shoot yourself in the foot: you
fashion clumsy neologisms such as illucid which etymologically use
words to mean the reverse of what the closest verb means: and, most
perniciously, you cannot disambiguate a NPOV tech review from a
stalking attack.

[1] OED online: Clear: Of words, statements, explanations, meaning:
Easy to understand, fully intelligible, free from obscurity of sense,
perspicuous.

In ordinary language, intelligent listeners and readers do not find
falsehood "easy to understand" because when someone says something
false, ordinary listeners and readers do not understand why he said
it, because in ordinary language that is in Habermas' sense not self-
seeking bullshit (such as the special and inhuman way language is used
in many business offices) there is a common altruistic search for
agreement and truth. Seebach, a self-confessed ADHD autist, does not
understand this.

Language in what Jurgen Habermas calls the lifeworld is not a debate.
It is a survival mechanism in which we get useful work done (as in a
structured walkthrough) by trying to understand things as meaningful
and true with no little decency and charity.

Yet as Habermas (a German philosopher, look him up now) knows, people
for individual rather than collective survival also use language
competitively as you do so: to get ahead, and fuck the group or their
fellow human being where necessary. This "operational" use, in
Habermas, is said to "colonize the lifeworld". For example, in
structured walkthrough, lifeworld helped the operational, but the
lifeworld in structured programming was defeated because individual
participants would put the worst possible interpretations on what
their competitors said in order to Look Good.

This is based on a (discredited) model (completely discredited) of
language in which language is like a formal calculus or math in which
statements can be "clear and false", whence your clumsy mistake.

"Well, it is. And the 4th edition, while it fixes some of the errors
reported (including the infamous void main which Schildt long defended
as not being an error), preserves some, introduces others, and
continues to be an exceptionally bad book."

Truly literate and urbane people don't think there are many "bad"
books. However, in my experience, incompetent programmers (which is to
say most American programmers) are always making snarky remarks, not
only about computer books, but about books, literature, literacy, the
humanities, classical music, art, and non-white people.

"I am no longer some random guy who likes C. I spent about a decade on
the C committee—and unlike Schildt, I actually showed up, submitted
papers and proposals, worked to resolve defects, and otherwise
contributed to the process. I am no longer the mildly autistic kid who
had never really studied writing or communication; I'm now a mildly
autistic adult with years of experience writing and communicating,
including experience writing publishable material."

You have published one book, a piece of a book not well-received (C
Unleahsed) and a variety of articles. So, as it happens, have I. You
also worked on the C99 standard. I believe that vendor pressure
"opened" the standard to incompetents because vendors, above all,
wanted their compilers to be certified as "standard" with as few
changes as possible by people as ignorant as possible, who wouldn't
take stands and engage in "academic" debate.

"Don't Make Me Think!" - best seller along with "Who Moved My Cheese?"

To do this, they allowed unqualified people to contribute, and as a
result, the standard doesn't properly determine C's semantics, which
any language standard must do.

"So if people want a better-written page on the topic, well, I'm
willing to provide one. Readers may also appreciate Clive Feather's
very helpful review of Schildt'sThe Annotated ANSI C Standard, which
also illustrates that Schildt does not seem to have a good grasp on
the C language."

I'm afraid that Clive appears to be a bit of a politician, and his
review was a copycat drive by shooting.

"In comp.lang.c, some recent discussions of this led to an
observation. Flip C:TCR open to a random page. You will probably find
an error. This game is easier with the 2nd and 3rd editions, because
of the prevalence of the incorrect void return type for main(), but
even in the fourth edition, there's plenty of room for fun. I've
sorted these in numerical order."

The void return type is in fact compiled even on standard compilers.
It's unacceptable for a "standard" language in order to have loopholes
in the form of several levels of warning messages, which many C
compilers have, because one language has not been thereby defined:
several have.

The C FAQ hides the language of the standard which permits
freestanding environments where the name and type of the function
called at program startup is implementation defined. Any compiler
which allows a void main, and most do (some with weasel warnings) is
standard, because it's running in a freestanding environment. It is in
fact a lie to say that the standard forbids void main; it does not (in
allowing freestanding environments) and cannot. The lie was propagated
by Linux evangelists who want all code to run under a copy of unix, a
1970s OS.

It's absurd for you to think that a programming language standard can:

1. Fail to deterministically specify semantics as we'll see, and

2. Dictate to programmers. You see, a deterministic standard would
refuse to compile a void main with no bullshit, but this is not done
by the C standard which is deliberately nondeterministic, both in
allowing freestanding and hosted environments and in many other ways.

"Don't void" is not a programming language standard, because a
programming language standard defines as fully and usefully as
possible the syntax and semantics of a language.

It doesn't tell programmers not to use features that compile at some
level of error messaging, and which on any system where the OS does
not use the value express meaning. That is a set of stylistic rules
for good C programming at best, and a childish in-joke at worst.

Page 51

"Here's a fairly typical example of the kind of thing you get wrong if
you don't have much real experience with portability:"

Schildt: "As bits are shifted off one end, zeroes are brought in the
other end. (In the case of a signed, negative integer, a right shift
will cause a 1 to be brought in so that the sign bit is preserved.)"

Seebs: "Clear, lucid, but not actually true. What happens when you
right-shift a signed, negative number, is "implementation-
defined" (C99, 6.5.7, paragraph 5); that is to say, the implementation
has to document what happens. While the behavior Schildt describes is
one of the common choices, other systems have been known to shift in
zeroes. There may be other behaviors out there. This ties in somewhat
with Schildt's comments about the use of two's complement
representations, where the behavior he describes is common but not
actually required."

This is like my C student "Otto" who constantly annoyed the other
students. He constantly disrupted the flow of exposition because of
his resentment that his mainframe assembler skills were out of date.

Schildt could have written "zeroes are shifted in when the number is
positive; when the number is negative, ones may be shifted in
depending on the implementation of C and whether twos-complement
arithmetic is in use".

But: any competent editor would have rejected my rephrase. Why?

Because the rephrase is nondeterministic language and nondeterministic
language is precisely what beginner and intermediate programmers do
not want to hear. They understand as intelligent human beings that
there are exceptions that prove the rule.

Interestingly, this phrasing, which expresses what you want Herb to
say, is strikingly similar to your assignment of db_header in your
queue.c code; that assignment likewise contains a non-deterministic
aporia, or hole if you please.

Note that my rephrase fails to tell the programmer what will happen in
fact. A teacher owes it to his students to provide positive knowledge.

You seem to be down a quart on International Baccalaureate Theory of
Knowledge and you seem not to have taken or comprehended a class in
the philosophy of science.

Instead, you have a folk philosophy of science. Like Creationists, you
crave the mantle of scientific authority, yet even as many
Creationists are one of the sets "uneducated boob", "failed
autodidact" or "academic fraud", you're actually completely uneducated
in computer science.
Therefore, your science has regressed to saws, shibboleth,
classification and taxonomy formation.

Prior to the Enlightenment, and in the middle ages and Renaissance,
much of what passed for science was naming, rules drafting and
taxonomy. The "names" of traditional grammar such as "gerund", which
for so many generations of students have confused and concealed rather
than revealed, and many of the lists (of syllogistic forms and
informal fallacy) of informal logic, while useful, confuse and mislead
because they are names and not theories, and are easily replaced by
equivalently "true" systems.

Biology during this era was the naming and classification of animals
and plants. Anthropology during this era was the naming and
classification of "races" with infamous results.

Creationism doesn't "get" the value of theory formation, not only for
religious reasons but also because theory formation is liberating. It
allows people to think for themselves, and avoids the scholastic
sadism of memorizing arbitrary taxonomies and rules.

However, in service of a nonexistent "standard C" in which we'll all
use Linux and supposedly fight the power of Microsoft (while not
noticing that we're enslaved to a new god), the FAQ approach regresses
to naming, which as we see in the example of racism produces shaming,
as opposed to theory formation, which promotes participation,
confirmation, refutation, affirmation and joy.

A "theory" of real C must acknowledge that it exists in several
dialects, only one of which requires avoidance of void main().

Suppose someone writes a brilliant, cutting edge, efficient and well
structured program with one flaw: it has void main().

The problem isn't in the program. It is in anyone, and you know who
you are, who dully applies the intolerant FAQ approach (related as
FAQs are to the worst kind of religious fundamentalism, at times
sounding like a religious catechism with sing-song answers mindlessly
droned) and not only says "bad program" but usually runs to the
personal and ritual shaming of the programmer.

Peter, if you had taken tuition in International Baccalaureate Theory
of Knowledge or philosophy of science, you would be familiar with Sir
Karl Popper. In simultaneous reaction to cruder forms of Marxist
bullshit and the Logical Positivist theory that "meaningful statements
must be verifiable", Popper developed a more robust theory.

This is that to have meaning, statements must be falsifiable.

Herb's statements have this property, as do most meaningful and useful
statements about such an inchoate artifact as C.

This means that you are disrupting the class if, without any academic
qualification in computer science, you provide counterexamples while
the rest of the class is struggling to remember an image of the most
common case: the shift of an ordinary positive number.

The fact that you can find errors in Schildt but not in the Standard
(which although nondeterministic in many real-world situations
including pre and post increment evaluation and the evaluation of
actual parameter values, is, especially for you, necessarily true by
definition) means that Schildt is a teacher, while the Standard is a
dead PDF…and you're a disruptive and repulsive stalker.

In Popper's sense, Schildt is meaningful because he can be falsified.
The Standard, like the Soviet constitution, can never be falsified.
Oops.

Professor Walter Lewin of MIT proves the theory of kinetic energy and
its conservation by rigging a lead ball to swing towards is face,
accepting the risk of calculation error. Schildt took the risk of
explaining C to programmers outside of the unix and linux world. Both
make gestures that are meaningful and useful, even courageous because
falsifiable.

You have a childish theory of language which you try to dignify as a
fashionable disease, but the fact is "zero bits are shifted in unless
the number is negative, where ones are shifted in unless twos
complement is in use, and if twos complement is not in use, I do not
know what happens" can be symbolized as follows:

Z: zero bits are shifted in
N: the number is negative
S1: one bits are shifted in
T: twos complement is in use
WTF: I don't know what happens

Symbolizing, my rephrase of Herb is: Z || (T && N && S1) || WTF

Whereas Herb doesn't say this, but here and elsewhere leaves these
underdetermined conditions unaddressed in order to avoid confusion;
the real crime was yours insofar as you didn't address them in C99.
The confusion was created by C "standardization" in order grant a
plenary approval to multiple compilers as a result of vendor greed.
This confusion cannot be redressed by a single computer author, and if
you as you say were on the committee for ten years, you made this
mess.

Note that any part of the formalized statement of how rotation works
can be said to be "false", and you can autistically snip any statement
or code example out of context to "prove" a lie or error.

But the big lie is your bizarre theory of language. In teaching we say
false things; trivially we say something false after the not sign in
"~A" and something that may be false before the or in A || B.

But this is silly. You're worse than silly. The only proper judgement
of a book which isn't kiddie porn in a free society is the market.
Sure, the same tolerance should be extended to criticism, but not when
that criticism meets, as yours does, the tests for a malicious libel.
The purpose of the whole text is to educate a disparate number of C
programmers, some of whom need to conform to Linux and others, to
Windows.

Page 259

"Here's what I found the first time I tried flipping the 4th edition
book to a random page. This is page 259 in the 4th edition, or 251 in
the 3rd edition. (The only difference between them is the declaration
for main.)"

"The following program uses freopen() to redirect stdout to a file
called OUTPUT:"

#include <stdio.h>

int main(void)
{
char str[80];

freopen("OUTPUT", "w", stdout);

printf("Enter a string: ");
gets(str);
printf(str);

return 0;
}

"In general, redirecting the standard streams by using freopen() is
useful in special situations, such as debugging. However, performing
disk I/O using redirected stdin and stdout is not as efficient as
using functions like fread() and fwrite()."

This is not an error on Herb's part. It's a matter of "efficiency"
which will vary according to platform and implementation.

Two can play the silly game of "portability", "efficiency", and using
a non-determined assertion to "refute" a deterministic assertion that
is generally but not always true. Saying that "to redirect is not as
efficient as using functions" is no more a part of the C Standard than
is twos complement, so, the reader might ask, what gives you the right
to refute what's a simple code example with something that might not
be always true?

But it's quite possible that my finding many of your assertions "non-
deterministic" seems to you, in your smugness, to be the ravings of a
madmen, and you may get similar spirits to agree if you select a small
number. It may even seem strange to an educated computer scientist.

You see, as a computing autodidact, you never understood, as far as I
can see, the concept of a non-deterministic automata, algorithm, or
assertion, because (for example) when a mere programmer like you needs
to construct a lexical analyzer, based on a DFA or deterministic
finite automaton, he need only know the deterministic part of a richer
theory.

An NDFA can only be simulated by a useless program doing random number
generation, therefore it's technically unnecessary to understand the
academic transformation of the grammar to an NDFA and from thence to a
DFA. The mere programmer today is better advised to find a good
algorithm that combines these steps.

But the mere programmer without education in computer science lost an
opportunity to separate statements like "actual parameter evaluation
order is undefined in C" versus "actual parameter evaluation order is
strictly left to right in my C compiler". To him, the previous
statement is true therefore somehow "better than" the more narrow
statement, or "most modern C compilers evaluate left to right".

He, and many ordinarily educated computer scientists, doesn't realize
that the first statement cannot be falsified, and is so uselessly true
as to constitute a criminal mistake in a vendor greed-driven standard.
He doesn't have the academic training in logic to recognize a class of
statements that are true but non-falsifiable and therefore without
merit or standing in engineering.

What shall we do, what shall we do, with all this useless beauty? –
Elvis Costello

1. "The printf command does not send a newline, nor is the stream
flushed. On many systems, doing this to the console would not display
the prompt until some later point. (See Newlines and Output.)"
The intent is clear as in understanding and truth. Herb is merely
expressing his intention to allow, on the many systems where the
printf works, the user to enter the data on the same line.
In a profession in which the grave and senior deliver so many bugs,
for example in which the pompous Keith Thompson of clc gravely
approved your one-line, off by one strlen, your false perfection and
useless beauty, a standard which you so signally fail to self-apply,
creates bugs.

Suppose Herb had been told by a user that the input as typed must
appear on the same line. You'd assault his professionalism in a
walkthrough based on the possibility that in some systems, omitting a
newline in a printf might not "push" the data out. You'd be "right"
but nothing would get accomplished.
Of course, there is probably a way of doing this, but the non-
obviousness is a flaw in C.

It would be a bug in the runtime for it to wait to "print" until eof.
It is contrary to the entire stream-of-characters io text model of C
to "wait" until end of line. In other words, you trash a guy because
of an error in C which you and others failed to fix in C99.
"For that matter, the file was opened in text mode, not binary mode.
In text mode, you may have to provide a newline at the end of your
output; since it is permissible for an implementation to require this,
you should always do it, especially in sample programs in a book
purporting to teach C."

In other words, the standard gave a plenary indulgence or get out of
jail free card to buggy compilers owing to vendor greed. And you fell
for it. Or did it.

And your advice is wrong. Any number of programs need to print
characters in a loop using printf in the loop, and delaying the
newline until the loop is complete. To follow your advice, the
programmer would have to allocate a buffer, and "buffer" creation is
usually a sign of incompetence and a source of bugs.

An ethical standard for a programming language would not impose such a
silly limitation on intelligent programmers. Herb is describing how to
use C, not your silly shibboleths.

2. "The gets() function is dangerous, and should never be used; it has
no provision for preventing input data from overrunning the buffer
given to it. (This may seem "harmless", but a reference book should
not illustrate such bad habits.) Schildt acknowledges the dangers
elsewhere in the book, but uses it anyway. (Note that gets() is
officially deprecated, as of Technical Corrigendum 3 to C99; it's not
even present in the C201X drafts anymore.)"

3. "The gets() function strips the newline from a line of input;
however, printf() does not add one, so the line printed by printf()
will be missing its newline."

4. "For that matter, it's incredibly dangerous to pass an arbitrary
string as the first parameter to printf -- if the user happens to
enter something like %ssomewhere in the string, your program is likely
to behave unexpectedly, or crash. So that should have been
printf("%s", str) or more likely puts(str)."

5. "No error check on freopen()."

6. "The first item in this list was misleading. See, I implied that
the prompt would have gone to the console, assuming that freopen()
succeeded. Of course, it wouldn't; it would have gone to the just-
opened file "OUTPUT" instead."

7. "The comment about using stdin and stdout being "less efficient"
has no particular basis in reality. It's not even coherent; you can
use fread() and fwrite() with those streams; the presented dichotomy
between redirected standard streams and the other file I/O functions
is not a real dichotomy. It's like saying that usingint isn't as
efficient as using + and -."

"What this tells you is that this code was never actually tried;
printing the prompt is incoherent after the freopen(), and the
mismatch between input and output would have been caught by even
casual testing. This is an atrocious example. This should never have
been written, let alone made it past whatever presumed technical
review might have happened."

Not all illustrative examples are "actually tried" for the same reason
that a math professor doesn't have to prove every example on the
blackboard. Not all illustrative examples are "actually tried" in a
software planning session, which is more akin to a classroom or
introductory text than software writing. I for one got heartily sick
of people who in high level design try to be prematurely clever.

Knuth and Dijkstra both define "programming" as the communication of
an intent as to the use of a computer to another human being. In this
example, that was the meta-intent and it does the job of showing
redirection. On specific platforms, the debugging (like a proof in
some math classes) was left to the reader.

An administrative decision was probably made NOT to test all the code
because of a lack of time. I can think of two ways this somewhat
questionable administrative decision, probably no more questionable
than corners cut in your book, can be defended.

In my own book (Build Your Own .Net Language and Compiler Apress
2004), owing to lack of time, I made such a decision; I decided that
all major objects in the Quick Basic interpreter would have and pass
stress tests built in to the class, and I promise the reader that all
code would work, which it has, I believe, for most readers. Some book
errata were received and posted at Apress. But in the people who
responded to my invitation to get updates and information about new
compilers, nobody has reported any code errata.

The first defense of a similar decision in Schildt's case is that it
is literally impossible, owing to Ritchie's failure to think through
the semantics of his language (order of evaluation of preincrement in
pathological cases being an example) and then owing to your failure to
confront vendor greed in C99, to create examples that will work for
all C compilers…even all standard C compilers, owing to the cowardly
use of non-deterministic, plenary language in the C99 standard. Most
so-called "portable" C is portable only between linux and unix. For
true portability you have to use Java.

I hereby challenge you to code a version of the Schildt code that is
guaranteed to work without any change on all POSSIBLE compilers,
because "portability" doesn't mean blindly following a set of rules of
thumb and shibboleths. It means working without change not on some
platforms, or many platforms, but on all or almost all conforming
platforms. This goal was approached in a satisfactory by C Sharp and
Java. C completely misses it. C programs must be "ported" by someone
who's an expert in C.

Based on the code you have posted at clc this year, I don't think you
can code portable examples based on Schildt. Therefore, you need to
stop stalking him.

Page 264

"Another "let's just flip the book open and see what we get".

Peter, quit fucking around. You and Richard, as seen on clc, started
this adolescent "flip the book open" game just last week, the first
week of April 2010. This doesn't constitute a serious technical review
and cannot be referenced in Wikipedia without a serious violation of
"biographies of living persons".

"This example also occurred in the 3rd edition on page 262, although
it wasn't quite the same."
Schildt: "In this way, if you need to change the size of the array,
you will need to change only the #define statement and then recompile
your program. For example:"

#define MAX_SIZE 100
/* ... */
float balance[MAX_SIZE];
/* ... */
for(i=0; i<MAX_SIZE; i++) printf("%f", balance[i]);
/* ... */
for(i=0; i<MAX_SIZE; i++) x =+ balance[i];

"The last line of this example is new in the fourth edition. So,
what's wrong with this one?"

1. "The printf loop has no newlines or spaces, so all the numbers
would be run together. Not a huge problem with the code as such, but
certainly a shoddy bit of work."

2. "Usually, when the size of an array is called MAX_SIZE, that
implies that the actual size may well be some smaller value. This is a
nitpick; we could reasonably assume that the implication is that the
whole array has been initialized."

3. "There hasn't been an =+ operator in C since the 1970s."

"You might think the =+ wouldn't compile, but in fact, it will. C89
standardized the 'unary +' operator, which exists only for symmetry
with a leading - used on negative numbers. Thus, this is equivalent to
x = +balance[i] which is in turn equivalent to x = balance[i], so the
last loop is precisely equivalent to the non-loop statement x =
balance[MAX_SIZE - 1]; (at least, assuming that x isn't volatile...).
Oops."

Two nits and a typo. Don't break your arm patting yourself on the
back. And had you not preferred being a creep and a stalker to McGraw
Hill's offer that you tech review the document for typos, there'd be
no typo.

"Again, this kind of stuff should never have made it past any kind of
review."

I guess you missed the point about macro substitution that was made.
The purpose was not to show off, it was simply to provide an example
of macro substitution.

Page 264, again.

"While looking for the previous example in the 3rd edition, I happened
to look at the example after it. This is on page 264-265 of the 4th
edition, and 262-263 of the 3rd edition"
"This form of a macro is called a function-like macro. For example:"

#include <stdio.h>

#define ABS(a) (a) < 0 ? -(a) : (a)

int main(void)
{
printf("abs of -1 and 1: %d %d", ABS(-1), ABS(1));

return 0;
}

"When this program is compiled, a in the macro definition will be
substituted with the values -1 and 1. The parentheses that enclose a
ensure proper substitution in all cases. For example, if the
parentheses around a were removed, this expression"

ABS(10-20)

"would be converted to"

10-20 < 0 ? -10-20 : 10-20

"after macro replacement and would yield the wrong result."

"Ahh, Mr. Schildt. So close, and yet, so far. Here's a little thought
experiment:"

printf("ABS(-3) - 1): %d\n", ABS(-3) - 1);

"See how that works? (It prints 3, not 2.) Schildt forgot the most
important part of parenthesizing a function-like macro; you must
parenthesize the entire definition. He had a great opportunity here to
cover the reasons for both parentheses around the entire definition,
and parentheses around each individual macro argument. He missed it,
instead claiming that the partial solution worked correctly "in all
cases", which it does not."

I in fact discussed this whole issue last week and I suspect you stole
the idea while screwing up by using the misnomer "function-like" as
we'll see, since having looked over your code for (not really) finding
and replacing %s, your queue.c abomination of desolation, and your
celebrated strlen boner, I do not think you are that type of
programmer who, first and foremost, follows his own rules and eats his
own dog food.

No, I think you are a far more common type, as common as dirt.

I think you're the irritating office loudmouth who terrorizes younger
and women programmers for their infractions. Then, when his parallel
failings are found in his code, he pulls a new rule out of his hat:
that in a pinch, at the crisis, real men know that there's "not enough
time to worry about nits", although we usually can tell he fucked up
and is making excuses. In other words,

The Fascist is he
In a permanent state of emergency
Who writes a beautiful Constitution
Shortly after the revolution,
Admonishing all
Prelapsarianly but after the Fall,
To respect the rights of Man:
But for the duration he will shitcan
The rights of citoyen…and citoyenne.

My practice is more complex. I classify macros into expression-type
(intended to return an expression) and block-type.

"Function-like" is a complete misnomer, far more serious and far more
revealing of a complete lack of computer science education, than any
of Schildt's solecisms. This is because the material intended for
return by abs is NOT A FUNCTION; it is a C expression which is
intended to return the absolute value.

Two can play the pedant game
'Twas you that tried Herb Schildt to shame
Now, since your own dog food you don't eat
Try some of this nice crow meat.

A function, in C, is sometimes inline and usually not. It has actual
and formal parameters which are called by value in all cases. Whereas
the intent of a macro is to do a textual substitution using parameters
called by name.

It is merely true that both are attempts to express a mathematical
function, something which is different from either. But "expression-
type" expresses the real effect and intention, which is to return some
sort of valid C expression, ideally one that can be reused, and which
will work as expected, anywhere a C expression is valid.

The alternate type could be called "statement list-type" or "block-
type" according to taste:
#define E(a) { a = 0; printf("%s\n", "a set to 0"; }

In the above I've used my own standard for "block-type" macros, which
is to always (without exception) encase them in curly brackets.

Another suggestion that handles a few more problems:

#define E(a) do { a = 0; printf("%s\n", "a set to 0"; } while(0);

This was suggested on clc to me some months ago by a very talented
programmer who is sadly being slowly more and more corrupted by the
mob rule of the corporate programming world, since when I credited him
with another suggestion on code I had contributed to clc, he asked me
to remove the credit. I noticed at Bell-Northern Research that people
who get programming jobs in corporations immediately regress to the
ethics and manners of 14 year olds, and can only conclude that this
programmer didn't want to be associated with someone who was unpopular
because he'd so criticized the thugs in residence at clc.

But Seebach lacks the literacy, constructive spirit and urbanity as a
stalker to helpfully describe good practice. And … it turns out that
the practice is not necessary.

Most macros are developed for internal use in a specific piece of code
by the same programmer who is going to use them. He could easily be
expected, if far better at C than Seebach, to just remember to rather
compulsively add parentheses to expression-type macros and braces to
block-type macros.

Or…in many real-world educational contexts, he could forget the whole
thing. It is an advanced issue and students can be simply told that
macro calling is a text operation and take it from there.

At this point, I shall end the first part of my reply to Seebach's
Snarky Tirade.

== 2 of 2 ==
Date: Sun, Apr 11 2010 6:03 am
From: Willem

spinoza1111 wrote:
) This is my reply (part 1) to Peter Seebach's new edition of "C: the
) Complete Nonsense" at http://www.seebs.net/c/c_tcn4e.html. Further
) parts of my complete reply will be forthcoming.
<snip>
) At this point, I shall end the first part of my reply to Seebach?s
) Snarky Tirade.

Your *entire* reply consisted of nothing but ad-hominem attacks.

It reads like you desire to find fault with every little thing that
Seebs writes and if you can't, you go for the man behind the words.

==============================================================================
TOPIC: Question about void
http://groups.google.com/group/comp.lang.c/t/7cda9a8237a38531?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Apr 11 2010 5:22 am
From: James Kanze

On Apr 10, 8:18 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:

> > On Apr 10, 1:00 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >> sandeep <nos...@nospam.com> writes:
> >>> WHY we cannot have a void variable?

> >> In C, »void« is an incomplete type and, therefore, lacks
> >> information needed to determine the size of x.

> >> I do not recommend crossposting such a question to both
> >> comp.lang.c and comp.lang.c++: Because they are separate
> >> languages, this should be discussed separately. Therefore,
> >> I did not answer for C++, but only for C above.

> > Except that in this particular case, C and C++ are identical.

> Not at all.

> Look else-thread and you'll find a lot of C-specific
> discussion, and a lot of C++-specific discussion.

Concerning what you might do with it *if* it were allowed. The
definition of void, however, is identical in C and in C++, as is
the requirement that a type be complete when you define a
variable using it (and the fact that "extern void x;" is also
illegal, although just declaring a variable doesn't normally
require a complete type).

> > In general, C++ tries to be compatible with C when it is a
> > question of only the basic types (or composite types which it
> > has in common with C). Thus, any differences in the definition
> > of int in C and in C++ can be considered bugs in the C++
> > standard.

> 'int'?

The difference has been recognized as a defect in the C++
standard, and is being addressed.

> Anyway, although your point is irrelevant to the present
> discussion (see below), it's not the case that C++ fundamental
> types that have corresponding types in C are equivalent to
> those C types. In particular the languages differ, as I
> recall, in allowing/disallowing padding bits and trap
> representations for fundamental types.

No. It's quite clear that both languages allow padding bits and
trap representations in everything but char types. (There may
be a difference with regards to plain char: C definitely allows
trapping representations in plain char; I don't think C++ does.
In practice, it's not an issue, since the trapping
representations can only occur with 1's complement or signed
magnitude representation, and all of the systems using those
representations define plain char to unsigned.)

> > And void, of course, is a basic type in C, and thus in C++.

> Consider 'char&' in C++.

That's not a type common to C and C++, so the rules for it are
obviously not common in both languages.

> This is one thing you can do with 'char' in C++ that
> you cannot do with it in C.

And you can make char a member of a class, or have a char
parameter to a template. But how is this relevant to the
semantics of char: char doesn't have any special characteristics
in C++, which would make it incompatible with C, for this.
These are characteristics of references, classes and templates,
not of char. The type char, in C++, is exactly the same as in
C, or it is a bug in the C++ standard. (In this case, I think
that there is a bug, but it's slight, and of no practical
consequences.)

--
James Kanze

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

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, April 11, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts