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

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

comp.lang.c@googlegroups.com

Today's topics:

* 'sizeof' in defensve programming - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/e9a378626cd7a329?hl=en
* Exercise from Kernagan and Richie - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/32e394ad7ea38efe?hl=en
* lvalues and rvalues - 9 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
* struct assignment and indeterminate values - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/c15233bd771f1091?hl=en
* C: The Complete Nonsense (4th Edition) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c680d289fb50dd06?hl=en
* ●●●【FREE SHIPPING!!!】Cheap Wholesale Nike Jordan 1-22,Shox, NIKE AIR MAX,
TN, Puma ,Dunk, Air Force One ect. <www.fjrjtrade.com> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e31f9321b63f18a4?hl=en
* C the complete nonsense - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en

==============================================================================
TOPIC: 'sizeof' in defensve programming
http://groups.google.com/group/comp.lang.c/t/e9a378626cd7a329?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Apr 8 2010 2:38 pm
From: Phil Carmody

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 4/8/2010 4:16 AM, Mark wrote:
...
>> But are there other reasons stopping
>> from using sizeof in everyday's code?
>
> C has three sizeof-related traps I'm aware of. Two require
> vigilance, and the other can be avoided with simple discipline.
>
> The first is that a function parameter declared as an array
> is not actually an array, but a pointer to the array's element
> type. In `size_t bar(char array[42]) { return sizeof array; }'
> might expect the function to return 42, the number of bytes in a
> 42-char array. What it actually returns, though, is the number of
> bytes in a char*, a pointer to the element type; this is usually
> 4 or 8 (but *could* be almost anything, even 42).
>
> The second is that until fairly recently `sizeof' never
> evaluated its argument. But the C99 Standard introduced the
> "variable-length array," an array whose size is given by a non-
> constant run-time expression. If you apply `sizeof' to such an
> array, it *does* evaluate, at least enough to figure out the
> value of the size-controlling expression. And if that expression
> has side-effects, re-evaluating it may be problematic.

I think I'd say the third is sizeof('a') not being sizeof(char).

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: Thurs, Apr 8 2010 5:07 pm
From: "Mark"

Hm, I got it all wrong I guess. Thanks for enlightening me, should be more
careful before posting silly question the next time.

--
Mark

==============================================================================
TOPIC: Exercise from Kernagan and Richie
http://groups.google.com/group/comp.lang.c/t/32e394ad7ea38efe?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Apr 8 2010 3:04 pm
From: Phil Carmody

Phil Bradby <nospam@nospam.com> writes:
> I am using K&R to teach a course in C and I'm puzzled by Exercise 2-2,
> "write a loop equivalent to the for loop above without using && or ||".
>
> Here is my answer:
>
> for(i=0; i<lim-1?(c=getchar())!='\n'?c!=EOF:0:0; i++) s[i]=c;
>
> These are my questions.
>
> 1) Is my answer right? I think so but it makes my head ache to think
> about it!

If the original was something like the following, then yes:

for(i=0; i<lim-1 && (c=getchar())!='\n' && c!=EOF; i++) s[i]=c;

> 2) Is it what they had in mind? It wasn't really obvious to me what
> solution they were thinking of and I don't think many of my students will
> come up with the answer above.

If I've got the problem right, then I'd answer exactly the same as you.

> 3) What's the point of the question? I can't think of any circumstances
> where && and || wouldn't be available - why would you want to tie your
> hands by avoiding a language feature that does exactly what's needed?

Perhaps it's an exercise in avoiding wrong answers. For example this
might be suggested by some as the condition, but would be badly wrong
((i<lim-1) + ((c=getchar())!='\n') + (c!=EOF)) == 3
as it loses both the shortcircuit operation, but more importantly
can evaluate c=getchar() and c!=EOF in either order, and therefore
invokes undefined behaviour.

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: Thurs, Apr 8 2010 5:46 pm
From: James Harris

On 8 Apr, 21:43, Phil Bradby <nos...@nospam.com> wrote:
> Hi
>
> I am using K&R to teach a course in C and I'm puzzled by Exercise 2-2,
> "write a loop equivalent to the for loop above without using && or ||".
>
> Here is my answer:
>
> for(i=0; i<lim-1?(c=getchar())!='\n'?c!=EOF:0:0; i++) s[i]=c;
>
> These are my questions.
>
> 1) Is my answer right? I think so but it makes my head ache to think
> about it!

As a rule (especially as you are teaching) I'd say always strive for
simplicity and clarity. So I'd have a go at this:

for (i = 0; i < lim - 1; i++) {
c = getchar();
if (c == '\n') break;
if (c == EOF) break;
s[i] = c;
}

It's intended to show the structure of the computation:

1. keeps the main loop control together as a unit in the for statement
(incrementing i),

2. shows sequential statements as sequential.

I would say this is easier to understand and easier to maintain (and
hence less likely to cause a headache!) and so is a better solution -
but others may disagree.

> 2) Is it what they had in mind? It wasn't really obvious to me what
> solution they were thinking of and I don't think many of my students will
> come up with the answer above.

Since both ?: which you used and break which I used are covered later
I suspect they intended students to write something horrendous.

AIUI you can use the bitwise & and | to get ands and ors with bit
patterns which, if used in a test evaluate as 0 => false, anything
else => true - but they also are not introduced until later.

For the point of the question: I have no idea. For why write some code
without a specific feature: this could be nothing more than a
challenge to test understanding.

Actually I've just had a thought that you could modify i to end the
loop which allows the following which I think only uses features
introduced to where Ex 2-2 is found (page 42 in my edition of K&R2).

for (i = 0; i < lim - 1; i++) {
c = getchar();
if (c == '\n')
i = lim - 2;
else if (c == EOF)
i = lim - 2;
else s[i] = c;
}

It sets i to lim - 2 because the i++ will execute at the end of the
loop and hence i will be lim - 1 when tested. This is both the limit
condition of the loop and known to be in the range of i's type.

If I had the choice I'd use the version with break, above, as it is
clearer.

James

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

== 1 of 9 ==
Date: Thurs, Apr 8 2010 3:18 pm
From: Phil Carmody

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-04-08, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Hmmm, what prevents...
>
> Nothing. :)
>
>> static FILE __system_fps[3] = { /* populated in some system-specific way */ };
>> stdin = &__system_fps[0];
>> stdout = &__system_fps[1];
>> stderr = &__system_fps[2];
>
> That would be fine, I think.
>
>>> Basically, you can't get a pointer without the compiler at some point having
>>> known what it pointed to. Therefore, you can check bounds.
>
>> Not always when there's a separation between the compiler and the
>> standard library.
>
> According to the standard, there is not. :)

According to the standard, processing of phase 8 may be separate from
phase 7 in 5.1.1.2 Translation phases. Phases 1-7 do not necessarily
have any information about the Library components linked to in phase 8.

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 9 ==
Date: Thurs, Apr 8 2010 3:33 pm
From: Seebs

On 2010-04-08, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> According to the standard, processing of phase 8 may be separate from
> phase 7 in 5.1.1.2 Translation phases. Phases 1-7 do not necessarily
> have any information about the Library components linked to in phase 8.

True, but "the implementation" as a whole is entitled to have such information
if it wants to.

The claim I'm making is that an implementation *can* correctly implement such
bounds checking, not that it is *required* to be designed so that it can do
so. If an implementer chooses to separate these components in such a way that
proper bounds-checking is impossible, then that implementation can't do bounds
checking. That doesn't prevent other implementations from making choices
which allow them to do it.

-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 9 ==
Date: Thurs, Apr 8 2010 5:07 pm
From: "bartc"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnvdc3592q.fsf@nuthaus.mib.org...
> Nicklas Karlsson <karlsson.nicklas@gmail.com> writes:
>> Let me summarize what I make of this (hopefully its correct):

>> Silly question, the lvalue (expression) itself has no type right? But
>> when its evaluated the compiler finds out what type the object that
>> the lvalue identifies has?
>
> No, an lvalue, like any expression, has a type.

In:

int a,b;

a=b;

what's the type of the lvalue?

--
Bartc

== 4 of 9 ==
Date: Thurs, Apr 8 2010 5:16 pm
From: "bartc"

"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
news:87fx37hkab.fsf@kilospaz.fatphil.org...
> "bartc" <bartc@freeuk.com> writes:

>> int A,B;
>>
>> A = B;

>> I would handle the assignment above as follows:
>>
>> *(&A) = B;
>
> So you'd not want your variables in registers? Why on earth not?

In my case I didn't have to contend with explicit register variables (that
would more likely be the optimiser's job).

But the *,& trick depends on the exact form of the left-hand-side, and any
register lhs would be treated differently.

In any case no actual * or & ops are explicitly inserted; it's just how the
AST is processed.

--
Bartc

== 5 of 9 ==
Date: Thurs, Apr 8 2010 4:34 pm
From: Keith Thompson

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
[...]
>>>> And an address register might very well contain something that looks
>>>> like, and can be operated on as, an integer.
>>>>
>>>> A C pointer value, conceptually at least, does not.
>>>
>>> I don't see how that addresses my point. A machine's address
>>> register can be used to refer to more than just an atomic
>>> entity at a single address.
>>
>> I'm not sure exactly what your point is. Can you clarify? C doesn't
>> describe pointers in terms of the behavior of a machine's address
>> register.
>
> Nor do I imply that it does, in fact quite the opposite, as we were
> in the context of your contrast:
>
>>>>>> a C pointer value is conceptually different, and at a
>>>>>> higher level, than a machine address.
>
> Which is what we agree on. However where we diverge is this part:
>
>>>>>> I find it clearer to think of
>>>>>> an address (pointer value) as pointing to the entire object.
>
> where that is being contrasted to machine addresses.
>
> Whenever I write assembly language, I never think of the addresses
> and address registers as being untyped. If they are addresses of
> structs, then there always be a range of meaningful offsets (which
> I will have symbolic names for) off which I can index them, and if
> they are addresses of elements of an array, there's always just one
> meaningful delta to increment or decrement them by (which again I
> will have a symbolic name for). The language doesn't enforce this,
> but you were talking about the conceptual level, and conceptually
> it appears I view assembly language as being at a higher level than
> you. A6 may be the address of the first byte of an object, but it's
> also the address of the object, and usually I'd prefer to keep that
> latter abstraction in mind than the former.
[...]

Ok.

I tend to think of assembly language as a one-to-one (or very nearly
so) representation of machine language. In my view, any typing
information you impose on an address in that context is part of your
mental model of the program, not something that's part of the language
itself.

For example, if I increment a struct foo* in C, the fact that it
advances sizeof(struct foo) bytes is part of the semantics of the
language. If I do the same thing with, say, an ADD instruction in
assembly, that's not part of the semantics of the ADD instruction.

Mentally imposing higher-level concepts on asembly language programs
is a very good thing. It's just not, in my experience, part of the
language itself.

Disclaimer: I haven't written any assembly language in longer than I
care to admit.

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

== 6 of 9 ==
Date: Thurs, Apr 8 2010 4:37 pm
From: Keith Thompson

"bartc" <bartc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnvdc3592q.fsf@nuthaus.mib.org...
>> Nicklas Karlsson <karlsson.nicklas@gmail.com> writes:
>>> Let me summarize what I make of this (hopefully its correct):
>
>
>>> Silly question, the lvalue (expression) itself has no type right? But
>>> when its evaluated the compiler finds out what type the object that
>>> the lvalue identifies has?
>>
>> No, an lvalue, like any expression, has a type.
>
> In:
>
> int a,b;
>
> a=b;
>
> what's the type of the lvalue?

I see two lvalues there, ``a'' and ``b'' (the latter is being used in
a context that doesn't require an lvalue). Both of them are of type
int.

That seems sufficiently obvious that I suspect there was some other
meaning in your question, but I don't know what it might be.

== 7 of 9 ==
Date: Thurs, Apr 8 2010 6:13 pm
From: "bartc"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnwrwh349v.fsf@nuthaus.mib.org...
> "bartc" <bartc@freeuk.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnvdc3592q.fsf@nuthaus.mib.org...
>>> Nicklas Karlsson <karlsson.nicklas@gmail.com> writes:
>>>> Let me summarize what I make of this (hopefully its correct):
>>
>>
>>>> Silly question, the lvalue (expression) itself has no type right? But
>>>> when its evaluated the compiler finds out what type the object that
>>>> the lvalue identifies has?
>>>
>>> No, an lvalue, like any expression, has a type.
>>
>> In:
>>
>> int a,b;
>>
>> a=b;
>>
>> what's the type of the lvalue?
>
> I see two lvalues there, ``a'' and ``b'' (the latter is being used in
> a context that doesn't require an lvalue). Both of them are of type
> int.
>
> That seems sufficiently obvious that I suspect there was some other
> meaning in your question, but I don't know what it might be.

Only that the OP seemed to have got the idea that an lvalue was some sort of
address, in which case it would have a type that was 'pointer-to-something'.
But in fact lvalues and rvalues look the same, and even have the same types!

But I would say that lvalue-ness was a kind of property or attribute of a
term, which you can't deduce just from looking at the expression or even
knowing it's type. It that case, it wouldn't be meaningful for an lvalue to
have a type.

--
Bartc

== 8 of 9 ==
Date: Thurs, Apr 8 2010 5:39 pm
From: Keith Thompson

"bartc" <bartc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnwrwh349v.fsf@nuthaus.mib.org...
>> "bartc" <bartc@freeuk.com> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:lnvdc3592q.fsf@nuthaus.mib.org...
>>>> Nicklas Karlsson <karlsson.nicklas@gmail.com> writes:
>>>>> Let me summarize what I make of this (hopefully its correct):
>>>
>>>
>>>>> Silly question, the lvalue (expression) itself has no type right? But
>>>>> when its evaluated the compiler finds out what type the object that
>>>>> the lvalue identifies has?
>>>>
>>>> No, an lvalue, like any expression, has a type.
>>>
>>> In:
>>>
>>> int a,b;
>>>
>>> a=b;
>>>
>>> what's the type of the lvalue?
>>
>> I see two lvalues there, ``a'' and ``b'' (the latter is being used in
>> a context that doesn't require an lvalue). Both of them are of type
>> int.
>>
>> That seems sufficiently obvious that I suspect there was some other
>> meaning in your question, but I don't know what it might be.
>
> Only that the OP seemed to have got the idea that an lvalue was some
> sort of address, in which case it would have a type that was
> 'pointer-to-something'. But in fact lvalues and rvalues look the same,
> and even have the same types!
>
> But I would say that lvalue-ness was a kind of property or attribute
> of a term, which you can't deduce just from looking at the expression
> or even knowing it's type. It that case, it wouldn't be meaningful for
> an lvalue to have a type.

Hmm.

The lvalue-ness of an expression is a binary attribute of the
expression, i.e., a given expression either is or is not an lvalue.
So "lvalue-ness" doesn't have a type. But *an lvalue* is an
expression, which therefore does have a type.

An lvalue doesn't have a pointer type (unless it happens to designate
an object of pointer type), but it does have a type (the type of the
object it designates).

If you look through section 6.5 of the standard, you'll find that the
section for each type of expression states whether it's an lvalue or
not. You very nearly *can* tell whether an expression is an lvalue or
not just by looking at it. If it's an object name, or if the
highest-level operator is unary * or [], it's an lvalue. A
parenthesized lvalue is an lvalue; a parenthesized non-lvalue is not
an lvalue. And so forth.

== 9 of 9 ==
Date: Thurs, Apr 8 2010 7:11 pm
From: Uno

Keith Thompson wrote:

> You very nearly *can* tell whether an expression is an lvalue or
> not just by looking at it.

Is there an extra negative in this sentence?
--
Uno

==============================================================================
TOPIC: struct assignment and indeterminate values
http://groups.google.com/group/comp.lang.c/t/c15233bd771f1091?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Apr 8 2010 3:18 pm
From: "Ersek, Laszlo"

On Thu, 8 Apr 2010, Seebs wrote:

> While reading up on some of the stuff in C:TCR, I've found something which
> looks as though it used to be an error but possibly isn't.
>
> Consider:
> int main(void) {
> struct { int a, b; } x, y;
> x.a = 10;
> y = x;
> return 0;
> }
>
> Is the behavior of this program well-defined? My assumption would have been
> that it was not, because x.b was indeterminate and accessed through an lvalue
> of non-character type. However, C99 TC3 says (6.2.6.1, paragraph 3):
> "the value of a structure or union object is never a trap
> representation, even though the value of a member of the structure
> or union may be a trap representation".
>
> That looks as though, after the assignment, no undefined behavior has occurred,
> but it is possible that y.b is a trap representation. Interestingly, it looks
> as though this might be true even if y had been fully initialized before the
> assignment from x.
>
> Thoughts?

Is there any rationale for the quoted passage of TC3? What you wrote made
me remember C99 6.2.6.1p6, footnote 42: "Thus, for example, structure
assignment may be implemented element-at-a-time or via memcpy." (I seem to
remember somebody mention that footnotes are not normative.)

I also remember a warning issued by gcc for a similar case.

http://lists.debian.org/debian-mentors/2009/10/msg00474.html

I could not reproduce that warning now with your code, though.

Cheers,
lacos

== 2 of 5 ==
Date: Thurs, Apr 8 2010 3:36 pm
From: Seebs

On 2010-04-08, Ersek, Laszlo <lacos@caesar.elte.hu> wrote:
> Is there any rationale for the quoted passage of TC3?

I don't know. It's a change from TC1.

TC1:

When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object representation
that correspond to any padding bytes take unspecified values.(42)
The values of padding bytes shall not affect whether the value of
such an object is a trap representation. Those bits of a structure
or union object that are in the same byte as a bit-field member,
but are not part of that member, shall similarly not affect whether
the value of such an object is a trap representation.

TC2:

When a value is stored in an object of structure or union
type, including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values.(42) The value of a structure or union
object is never a trap representation, even though the
value of a member of the structure or union object may be
a trap representation.

So there is a change there as of TC2, but I don't know the history.

I think it is probably intended specifically to address the case of
structure assignment, although it seems like that may be contradicted
by footnote 42. (And yes, footnotes are non-normative.)

> I could not reproduce that warning now with your code, though.

It could be that gcc has changed the handling of that case on the grounds
that the standard has clarified its intent. I'm not sure.

== 3 of 5 ==
Date: Thurs, Apr 8 2010 4:35 pm
From: Peter Nilsson

Seebs <usenet-nos...@seebs.net> wrote:
> ...C99 TC3 says (6.2.6.1, paragraph 3):
> "the value of a structure or union object is never a trap
> representation, even though the value of a member of the
> structure or union may be a trap representation".
<snip>
> Thoughts?

Consider a struct record where not every field requires
a value in certain contexts. For example, consider a
simple token record...

struct token
{
int kind;
union {
maxint_t u;
long double d;
int keyword;
...
} detail;
};

If one of the 'kind's does not require a detail (e.g.
whitespace,) should the language still insist that one
of the union members be filled in when such a token is
assigned to another token object?

The TC just legalised a construct that has long been
taken for granted.

--
Peter

== 4 of 5 ==
Date: Thurs, Apr 8 2010 4:47 pm
From: Seebs

On 2010-04-08, Peter Nilsson <airia@acay.com.au> wrote:
> If one of the 'kind's does not require a detail (e.g.
> whitespace,) should the language still insist that one
> of the union members be filled in when such a token is
> assigned to another token object?

I would have thought it did!

> The TC just legalised a construct that has long been
> taken for granted.

As someone who never took it for granted, I am not totally sold on
this; I have been carefully initializing the whole structure all along.

However, I certainly grant that no great injury is done to the language
by permitting this.

Thanks for pointing out this case, where the nature of the structure's
usage suggests strongly that it's undesireable to be forced to initialize
a field with no meaningful values.

== 5 of 5 ==
Date: Thurs, Apr 8 2010 5:04 pm
From: Keith Thompson

Peter Nilsson <airia@acay.com.au> writes:
> Seebs <usenet-nos...@seebs.net> wrote:
>> ...C99 TC3 says (6.2.6.1, paragraph 3):
>> "the value of a structure or union object is never a trap
>> representation, even though the value of a member of the
>> structure or union may be a trap representation".
> <snip>
>> Thoughts?
>
> Consider a struct record where not every field requires
> a value in certain contexts. For example, consider a
> simple token record...
>
> struct token
> {
> int kind;
> union {
> maxint_t u;
> long double d;
> int keyword;
> ...
> } detail;
> };
>
> If one of the 'kind's does not require a detail (e.g.
> whitespace,) should the language still insist that one
> of the union members be filled in when such a token is
> assigned to another token object?
>
> The TC just legalised a construct that has long been
> taken for granted.

Here's an example that I find clearer:

struct string {
size_t len;
char str[MAX_LEN];
};

struct string hello;
hello.len = 5;
strcpy(hello.str, "hello");

There's no need to initialize elements of hello.str past the ones that
are actually in use.

(Yeah, char doesn't have trap representations; consider a similar
example with an array of double.)

==============================================================================
TOPIC: C: The Complete Nonsense (4th Edition)
http://groups.google.com/group/comp.lang.c/t/c680d289fb50dd06?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Apr 8 2010 5:15 pm
From: Seebs

Based on feedback from people here, I've concluded that it was possible
that the earlier edition of C: The Complete Nonsense did not provide the
reader with a fair, accurate, and reasonably comprehensive picture of
the quality of Herbert Schildt's book, "C: The Complete Reference".

Having put a few hours of work into reviewing the current edition, I have
created a new page which analyzes it in some detail. I have concluded that
the previous document significantly understated the abundance and depth of
misunderstandings and errors in Schildt's book. Even the 4th edition, in
which several errors pointed out in my previous page have been corrected,
continues to astound me with the sheer depth of its errors.

Perhaps more importantly, I had not previously noticed, or remarked on,
the great volume of things which were simply not covered by Schildt, which
should have been in any book purporting to teach C or to serve as a reference
for it. In fact, the errors of omission are in some cases more serious.

Anyway, here we have it:

http://www.seebs.net/c/c_tcn4e.html

Special thanks to a number of reviewers and commenters, especially Keith
Thompson and der Mouse, both of whom caught me out in a number of humorous
errors. (For what it's worth, I believe that one or two cases were ones where
I had mistakenly identified some of Schildt's writing as being in error, and
a dozen or more were cases where I had failed to spot all of the errors.)

As always, comments, corrections, and feedback are welcome. (Disclaimer:
By standing policy, I will delete any private contacts from Nilges unread.
I also won't actually read his posts, except for amusement value. If someone
thinks he's spotted a genuine error, feel free to bring it to my attention,
but I won't be holding my breath.)

==============================================================================
TOPIC: ●●●【FREE SHIPPING!!!】Cheap Wholesale Nike Jordan 1-22,Shox, NIKE AIR
MAX, TN, Puma ,Dunk, Air Force One ect. <www.fjrjtrade.com>
http://groups.google.com/group/comp.lang.c/t/e31f9321b63f18a4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Apr 8 2010 5:51 pm
From: nice

●●●【FREE SHIPPING!!!】Cheap Wholesale Nike Jordan 1-22,Shox, NIKE AIR
MAX, TN, Puma ,Dunk, Air Force One ect. <www.fjrjtrade.com>

Minimum order is one,factory price also! Paypal payment free
shipping,ship time will take 4-7 working days.

Cheap Wholesale Jordan 1 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 1.5 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 2 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 2.5 Man (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 3 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 3.5 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 4 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 4.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 5 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 5.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 6 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 6.5 Kid (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 7 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 7.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 8 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 9 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 9.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 10 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 11 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 11.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 12 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 12.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 13 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 14 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 15 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 15.5 Man (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 16 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 17 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 18 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 19 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 19.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 22 Man (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 22.5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 23 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 24 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Air Yeezy (free shipping www.fjrjtrade.com)

Cheap Wholesale Jodan 23+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 1+Jordan 2+Jordan 5+Jordan 7

Cheap Wholesale Jordan 3+AF1 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 3+Jordan 5+Jordan 15 (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 4+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 4.5+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 5+AF1 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 6+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 9+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 9+Jordan 23 (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 11+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 11.5+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 11+Anthony (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 11+Jordan 12 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 11+Jordan 13 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 11+Jordan 23 (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 11+Obama (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 12+AF1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 13+AF1 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 13+AJ6Rings (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 16.5+AF1 (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 18+Jordan 23 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 20+AF1 (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan 21+Jordan 23 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 25+AF1 (paypal payment)(www.fjrjtrade.com )

Cheap Wholesale Jordan 6 unite1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan 8 unite1 (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan flying (paypal payment)
(www.fjrjtrade.com )

Cheap Wholesale Jordan foamposite liite Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan Melo M5 Man (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan True Flight (free shipping www.fjrjtrade.com)

Cheap Wholesale Jordan Trunner Q4 (free shipping www.fjrjtrade.com)

Cheap Wholesale Shox NZ <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox OZ <www.fjrjtrade.com> free shipping
Cheap Wholesale Shox R2 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox R3 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox R3+R4 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox R4 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox R5 <www.fjrjtrade.com> free shipping
Cheap Wholesale Shox Reverie lover
Cheap Wholesale Shox RZ <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox TL <www.fjrjtrade.com> free shipping
Cheap Wholesale Shox Torch <www.fjrjtrade.com> paypal payment
Cheap Wholesale Shox TZ <www.fjrjtrade.com> paypal payment

Cheap Wholesale Nike Air Max 87 <www.fjrjtrade.com> free shipping
Cheap Wholesale Nike Air Max 89 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max 90 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max 91 <www.fjrjtrade.com> free shipping
Cheap Wholesale Nike Air Max 92 Man <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Nike Air Max 93 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max 95 <www.fjrjtrade.com> free shipping
Cheap Wholesale Nike Air Max 97 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max 180 Man <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Nike Air Max 2006 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max 2009 <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max Clssic BW <www.fjrjtrade.com> free
shipping
Cheap Wholesale Nike Air Max LTD <www.fjrjtrade.com> paypal payment
Cheap Wholesale Nike Air Max Skyline <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Nike Air Max STAB <www.fjrjtrade.com> free shipping
Cheap Wholesale Nike Air Max Tailwind <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Nike Air Max TN <www.fjrjtrade.com> paypal payment

Air Force one <www.fjrjtrade.com> paypal payment
Cheap Wholesale Air Force One Man <www.fjrjtrade.com> paypal payment
Cheap Wholesale Air Force One Women <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Air Force One M&W <www.fjrjtrade.com> paypal payment
Cheap Wholesale Air Force one 25 Man <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Air Force One 25 Women <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Air Force One Kid <www.fjrjtrade.com> paypal payment
Cheap Wholesale Air Force one Mid Man <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Air Force one Mid Women <www.fjrjtrade.com> paypal
payment
Cheap Wholesale Air Force one Hight Women <www.fjrjtrade.com> paypal
payment

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

== 1 of 5 ==
Date: Thurs, Apr 8 2010 7:57 pm
From: spinoza1111

On Apr 9, 2:53 am, Walter Banks <wal...@bytecraft.com> wrote:
> Nick Keighley wrote:
> > On 8 Apr, 13:24,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > Maliciously "cruel and unusual" behavior of Schildt's enemies
> > > is idemnified and forgiven. Stupid errors such as "the heap is a DOS
> > > term" by mob leaders are idemnified and forgiven. But in this mob
> > > action, nothing Herb says is either idemnified, nor forgiven.
>
> > if he or his publishers had acceptted criticism early on and published
> > errata (maybe online even!) it would probably saved a lot of grief.
>
> Most technical books have errata and publish errata on line. This
> material is usually accumulated by the author and available from
> the author's personal website or the publishers website. It
> re-enforces the commitment the author has with the readers of
> their works.
>
> Seeb's and Clive's reviews have been posted for a long time
> on the internet and essentially forgotten until Nilges brought

This is not correct. They were referenced in making the Schildt
"biography" on wikipedia in 2006 and over these years, there has
always been a high frequency of references. Furthermore, newbies have
always been directed to the C FAQ which makes a libel a fact.

> the comments back to life a year or two ago here. The bulk of
> the criticism now aimed at Schildt is that he knew about errata

It is clear that he did not since Peter has admitted that the CTCN
errata have been fixed. In a stunt of astonishing vulgarity, Seebach
has taken credit for this...and in response, is renewing his "open
source" call to find more errors. Again, he does not offer to work
with Schildt. He has learned nothing.

Inadvertent errors that are matters of interpretation. Seebach, in
these errata, makes unambiguous errors such as "the heap is a DOS
term". He does not have the ability to construct an errata.

> and failed to use the information with understanding in newer
> editions of the publication and that he failed to inform his readers
> of inaccurate information in a published work.. The reviews we
> not a comprehensive editing pass but a short overview of the
> types of errors that were found.
>
> Nilges rants about twenty errors and then chided a reviewer
> for not demonstrating a claim that there were hundreds of errors
> has prompted the kind of detailed error posting that both confirm
> the presence of hundreds of errors and may result in a very
> hard look at Schildt's publications.
>
> Nilges has forcefully questioned the accuracy of the reviews on
> Schildt's book. His questions are being tested by looking at the
> review issues in detail and individual book pages are being
> selected at random and scanned for errors. Nigles is free to
> challenge the tests point by point in an academic search for the
> truth. He will need to demonstrate intellectual honesty to be
> credible.
>
> w..

== 2 of 5 ==
Date: Thurs, Apr 8 2010 8:10 pm
From: rigs

You're right, seebs. This dude is funny as hell.

Think he'll make me some money?

== 3 of 5 ==
Date: Thurs, Apr 8 2010 8:19 pm
From: Seebs

On 2010-04-09, rigs <rigorist@gmail.com> wrote:
> You're right, seebs. This dude is funny as hell.

> Think he'll make me some money?

No. But he will brighten an otherwise dull afternoon*.

I'm hoping he's happy now that the Wikipedia article no longer refers to an
out-of-date article that is not adequately researched, fact-checked, and
documented. I mean, the problem, as described, was that the Wikipedia entry
linked to something essentially obsolete and not very well-organized. I
have corrected this deficiency.

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

== 4 of 5 ==
Date: Thurs, Apr 8 2010 9:15 pm
From: Walter Banks

spinoza1111 wrote:

> On Apr 9, 2:53 am, Walter Banks <wal...@bytecraft.com> wrote:
>
> >
> > Seeb's and Clive's reviews have been posted for a long time
> > on the internet and essentially forgotten until Nilges brought
>
> This is not correct. They were referenced in making the Schildt
> "biography" on wikipedia in 2006 and over these years, there has
> always been a high frequency of references. Furthermore, newbies have
> always been directed to the C FAQ which makes a libel a fact.
>
> > the comments back to life a year or two ago here. The bulk of
> > the criticism now aimed at Schildt is that he knew about errata
>
> It is clear that he did not since Peter has admitted that the CTCN
> errata have been fixed.

Some of the specific errata have been fixed in a later edition
but the same errors elsewhere not directly referenced in Seeb's
were left unchanged. A solid technical editing pass should have
been made between revisions and the examples should have
been validated against the written description and run in the
context that the fragments were intended.

> In a stunt of astonishing vulgarity, Seebach
> has taken credit for this...and in response, is renewing his "open
> source" call to find more errors. Again, he does not offer to work
> with Schildt. He has learned nothing.

It is Schildt's work Seeb's email address is readily available he
could have easily contacted Seeb (maybe he did). Seebs has
no obligation to work with Schildt. The current review started
directly with your call to treat Schildt honestly. Classify the errors
in some rigorous way starting with mundane to serious and
let the results stand for themselves.

Knuth paid for bug reports. Haberson and Steele author
published errata might be a good example to follow.

http://careferencemanual.com/errata.htm

w..

== 5 of 5 ==
Date: Thurs, Apr 8 2010 9:47 pm
From: J de Boyne Pollard

> (Sigh) If you post a new document:
>
> 1. Questions will still remain at wikipedia how you misled them with
> the old document for fifteen years, violating their Biographies of
> Living Persons policies with maliciously false information [...]

Hey! M. Seebach! You violated a Wikipedia policy with something not
even written on Wikipedia, and managed to do it for six years before
Wikipedia even existed. Did you know you were capable of such feats?

Archimedes Plutonium thinks that Wikipedia existed in 1997, too.

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

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

Thursday, April 8, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts