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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 21 2010 9:10 am
From: Keith Thompson

raltbos@xs4all.nl (Richard Bos) writes:
> "bartc" <bartc@freeuk.com> wrote:
[...]
>> That is, for systems where newline isn't something crazy, like an entry
>> in a database the other side of the file system.
>
> Or a preceding line length, which IIRC actually has been used. But
> that's the problem: what _do_ you suggest we do for such systems? Ignore
> them? Java can afford to do that; C cannot.

A preceding line length would make some things easier, such as
reading a potentially very long line into memory. Just read the line
length first, allocate that much memory, and read that many bytes.

I wonder why the people who complain about '\0'-terminated strings
don't complain about '\n'-terminated lines.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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

== 1 of 5 ==
Date: Sun, Mar 21 2010 9:18 am
From: spinoza1111

On Mar 21, 1:00 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Mar 21, 9:35 am, Seebs <usenet-nos...@seebs.net> wrote:
>
>
>
>
>
> > On 2010-03-21, Rob Kendrick <n...@rjek.com> wrote:
>
> > > That, and I don't know of any news readers with built-in C syntax
> > > checkers. And it's not as if anybody writes valid C perfectly first
> > > time all the time.
>
> > I'm particularly prone to trivial and obvious mistakes, while I tend
> > to get other stuff right more easily. This is apparently stereotypical
> > for severe ADHD. As a result, I'm quite likely to, say, have fencepost
> > errors in string processing, or try to compile something only to discover
> > that I changed the name for a variable halfway through an implementation.
> > On the other hand, I added thread safety to pseudo, using a part of the
> > POSIX thread API I'd probably seen maybe once before, and (once I got past
> > the obvious and trivial errors) the actual thread safety design worked
> > flawlessly on the first try.
>
> > The hard part is easy; the easy part is hard. This pattern has been with me
> > all my life.
>
> > -s
> > --
> > Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
>
> The following code, from Peter's "pseudo root simulator", is submitted
> to this discussion group as evidence that he is incompetent, and is
> unethically using this newsgroup to get debugging assistance for code
> that he will then claim as his own. And because he is incompetent, he
> has defamed Herb Schildt and myself in a legally actionable sense.
>
> If I am wrong I will apologize for basing this charge on this evidence
> but will not withdraw the charge, since other evidence exists. I am
> the best programmer in this newsgroup, but by no means the best C
> programmer, so I may have missed something.
>
> Sources: the thread starts athttp://groups.google.com.hk/group/comp.lang.c/msg/54dfb34c84373f26?hl=en
> ("A hunk of not-very-portable code I've written"). This post
> references code in github athttp://github.com/wrpseudo/pseudo/blob/master/pseudo.c
> line 664 at this moment in time.
>
> int
> pseudo_server_response(pseudo_msg_t *msg, const char *tag) {
> switch (msg->type) {
> case PSEUDO_MSG_PING:
> msg->result = RESULT_SUCCEED;
> if (opt_l)
> pdb_log_msg(SEVERITY_INFO, msg, tag, "ping");
> return 0;
> break;
> case PSEUDO_MSG_OP:
> return pseudo_op(msg, tag);
> break;
> case PSEUDO_MSG_ACK:
> case PSEUDO_MSG_NAK:
> default:
> pdb_log_msg(SEVERITY_WARN, msg, tag, "invalid message");
> return 1;
> }
>
> }
>
> OK. My understanding of C is that for ACK and NAK, the code will fall
> through to "invalid message", and this is not intended. Good style
> alone demands a break after the ack and nak cases. The same sort of
> error is repeated above the code at github above this code, therefore
> this isn't "ADHD". It is, as far as I can see, incompetence which
> taken together to an out of order and in the same code, means that
> Seebach has not mastered the C programming language as of this year,
> and did not know C when he published "C: The Complete Reference", his
> defamatory attack on Herb Schildt.
>
> I am making very serious charges involving legal liability to Peter or
> myself, and possibly involving Wind River Systems, so due diligence is
> essential.
>
> First as to authorship: this is from Peter's readme for the pseudo
> root simulator:
>
> "My various coworkers, both engineering and management, made this
> possible.
> While I did most of the actual typing, this code has benefitted
> greatly
> from detailed code reviews, excellent reproducers for bugs, and the
> consistent support of the whole group for the project. It's been a
> great
> deal of fun, and I'm pretty happy that we're finally ready to make it
> available for other people to look at."
>
> The claim that there were "detailed code reviews" appears to be a lie.
> This use of case is a common bug but one that never is concealed in
> testing and one that is typically found in code reviews. Furthermore,
> Seebach's online conduct here in this ng demonstrates that in a code
> review, he is probably disruptive and cannot function.
>
> I believe that Peter, hopefully without authorization from Wind River
> Systems, who is either a client or former employer or something else
> in relation to him (the relation is not clear) is submitting
> unacceptable code to this newsgroup for review by competent people in
> a relationship of slave labor. As in the case of wikipedia editors,
> who are like him masquerading as competent, he knows enough to
> recognize competent people who can write such as myself, and he fears
> these people because they may expose his scam. This is the reason for
> his vicious attacks on me.
>
> My "due diligence" was to reread the 2005 C99 standard PDF, since good
> programmers, unlike Seebach, always put breaks in null cases so that
> they can forget in part just how poorly the switch statement was
> designed by Ritchie, or Pike, or Kernighan, or Kermit the Frog. This
> means we're not always "up to speed" on the actual rules of C, which
> are in some part, mistakes masquerading as rules.
>
> The standard has an example of a fallthrough, but it may be that
> Seebach believes that the logic doesn't fall through if there is no
> code in the case. So, I tested this using Microsoft C++ .Net in C
> mode:
>
> switch(1)
> {
> case 1:
> case 2:
> default: printf("foo\n");
> };
>
> The above code printed foo.

In this particular case, it is possible that Seebach never got around
to deciding and coding what ack and nak should do. A nak sounds like
an error in which you should wait until a maximum. But I do not
understand how an ack could be an error. "hey, I'm here! Fuck you,
you're an error! Mom!"

I am waiting for him to lie about this situation.

Furthermore, there is a command processor switch statement directly
above the code I'm discussing: it seems to want to process pseudo root
commands. Many commands seem "stubbed", yet strangely, not with a
break to get out of the switch statement. As a result, a mkdir will do
a mknod.

[Parenthetically, one wonders what a pseudo root is for. OK, you want
to make directories and stuff without bothering Linux or being in
protected mode? Or maybe you are a programmer only in virtual reality
and you like simulating what the big boys do? Hell, I love writing
simulators myself. But isn't Linux really, really good at making
directories in reality? Are we reinventing the wheel? Don't get me
wrong, I might be The Greatest Programmer in the World but I know dick
about Linux.]

The code, which is too large to include, starts at line 456 at
http://github.com/wrpseudo/pseudo/blob/master/pseudo.c.

I do not understand why the operations he has supported at this time
have a break but the unsupported operations do not. The apparent error
is consistent, and Peter has told us that he gets trivial matters
wrong.

However, programming isn't high level conceptual handwaving. When I
wrote the compiler for "Build Your Own .Net Language and Compiler" I
wrote all 26K lines by myself. Real programmers don't like
collaboration save for pair programming.

I believe that if I'd submitted this code, Peter would have been on me
like a fly on shit, claiming that I am both incompetent and insane,
once others noticed the error. I believe he's no better than somebody
coming here for homework completion, and possibly worse.

Here's another troubling error, in the function containing the
troubling case statements. A "pseudo_msg_t" named db_header is
declared with no initialization, and then assigned using this code:

if (found_ino && (prefer_ino || !found_path)) {
db_header = by_ino;
} else if (found_path) {
db_header = by_path;
}

Hmm...if you have found an ino and you prefer it, or if no path was
found, then you set db_header to by_ino. Otherwise if you have a path
you use that.

[Oh shit, I hope I know how else and if and stuff work. Yup I think
that the above if has sprung a leak.]

OK, perhaps this is an error which "can't happen". However, competent
programmers handle many (but not all) things which can't happen. I
worry in strstr about a null target. I don't worry AT THIS TIME (after
two hours work) about a target or a master that is NULL.

But...Peter says this code has been worked on by him for two months.
It is to me unwise to not put in error checking early so as to "eat
your own dog food" when errors occur.

Nope, I think the code is globally incompetent and was brought here to
be beat into shape by slaves for whom Peter, and Wind River Systems,
have naught but contempt, as indicated by his treatment of dissident,
uppity slaves like me.

Is this what Open Source has come to?

I would have given db_header an initial null value. OK, is this
attention disorder in action, which conceals A Heartbreaking Work of
Staggering Genius? Is this the first pseudo root thingie ever written
for linux, and did many a man try and fail to solve this problem?

Oh, here is a switch statement at line 88. It uses GNU getopt with a
smartass remark to the effect that GNU did it wrong; Peter, at an
early age, seems to have regarded himself as a Superior and Gifted
person who Just Knew that you study calculus before trig, and that you
don't have to take computer science to be a Genius Programmer. Perhaps
big hairy guys that rode motorcycles and looked like Schildt made fun
of him and give him noogies and swirlies.

OK, all cases have a break and all do something. Cool.

Oh crumbs, no default handler, with an error message, perhaps snarkily
blaming the error on GNU.

Two months work? Wow.

== 2 of 5 ==
Date: Sun, Mar 21 2010 9:22 am
From: spinoza1111

On Mar 21, 11:54 pm, ralt...@xs4all.nl (Richard Bos) wrote:
> Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >spinoza1111<spinoza1...@yahoo.com> writes:
> > I don't expect you to change your style -- you've evolved it to
> > provoke a response here
>
> And once again, he's succeeded. Well done for falling for it, jerk.

Excuse me. I am not here to provoke anyone. Nor am I here, as I
suspect Peter Seebach is, to get really bad code (Peter's pseudo root
simulator) fixed by unwitting slaves.

I just thought it would be fun to plan, pre-document and write strstr
without using string.h. I did so, composing a test suite which at this
writing is being used by others who don't care that they are stealing
intellectual production while not supporting a fellow human being
subject to absurd and unconscionable treatment. I again sparked an
interesting, on topic and useful thread in the best tradition of clc.

But unlike a corporate dweeb who sucks up to the money and shits on
people when he thinks he can get away with it, I am not afraid of a
fight. So don't fuck with me.
>
> Richard

== 3 of 5 ==
Date: Sun, Mar 21 2010 10:42 am
From: cri@tiac.net (Richard Harter)

On Sun, 21 Mar 2010 13:08:42 +0100, Moi
<root@invalid.address.org> wrote:

>On Sun, 21 Mar 2010 01:35:15 +0000, Seebs wrote:
>
>> On 2010-03-21, Rob Kendrick <nntp@rjek.com> wrote:
>>> That, and I don't know of any news readers with built-in C syntax
>>> checkers. And it's not as if anybody writes valid C perfectly first
>>> time all the time.
>>
>> I'm particularly prone to trivial and obvious mistakes, while I tend to
>> get other stuff right more easily. This is apparently stereotypical for
>> severe ADHD. As a result, I'm quite likely to, say, have fencepost
>> errors in string processing, or try to compile something only to
>
>I think most of us do, actually.
>First, you get the basics right (the "skeleton" of the algorithm/program)
>, then you polish the corner cases and tackle the fencepost errors.
>See for example Knuth's "never getting binary search right the first time"
>musing.

If I may disagree a bit, in my experience it is often better to
get the invariants, the pre-conditions, and the post-conditions
worked out before proceeding to the actual code. Yes, you want
to get the idea of an algorithm first, but don't code immediately
from the idea. I admit that this is a counsel of perfection, and
that all too often I violate my own strictures. However when I
do I sometimes pay the price.

The problem with dealing with corner cases et al as afterthoughts
is that it is all too easy to overlook special cases. When
testing doesn't catch these glitches the result can be long term
latent bugs.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 4 of 5 ==
Date: Sun, Mar 21 2010 11:03 am
From: Richard Heathfield

Richard Bos wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> spinoza1111 <spinoza1111@yahoo.com> writes:
>
>> I don't expect you to change your style -- you've evolved it to
>> provoke a response here
>
> And once again, he's succeeded. Well done for falling for it, jerk.

Ben is a knowledgeable contributor to this newsgroup, and most polite
with it. You would do well to try to emulate him rather than insult him.

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

== 5 of 5 ==
Date: Sun, Mar 21 2010 11:55 am
From: "io_x"

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4ba5edaf$0$1133$4fafbaef@reader1.news.tin.it...
i forgot to say that the strstrrWithIndex()
and main() functions are by E. Nilges
post here in this thread
news:0827d2cd-b832-4112-8c99-e68be9a8d3f3@k6g2000prg.googlegroups.com...
thank to him
thanks to all you, for all

> #include <stdio.h>
...

> #define TRUTH -1
> #define FALSITY 0
> #define NULLITY 0

...
> char* strstrrWithIndex(char* a, char* b, uns* i)
> {char *r;
> if(i==0) R 0;
> r=strstrr(a,b);
> if(r==0) {*i=-1; R 0;}
> else {*i=r-a; R r;}
> }
>
> int main(void)
> {
> char *ptrIndex1 = NULLITY;
> uns intIndex1 = 0;
> printf("strstr Simplified\n\n");
> printf("Expect 0: %d\n", strstrr("", ""));
> printf("Expect 0: %d\n", strstrr("0123456789", ""));
> printf("Expect 0: %d\n", strstrr("", "0"));
> printf("Expect 0: %d\n", strstrr("Here", "There"));
> ptrIndex1 = strstrrWithIndex("There", "here", &intIndex1);
> printf("Expect 1: %d\n", intIndex1);
> ptrIndex1 = strstrrWithIndex("They seek him here",
> "here",
> &intIndex1);
> printf("Expect 14: %d\n", intIndex1);
> ptrIndex1 = strstrrWithIndex("They seek him there",
> "here",
> &intIndex1);
> printf("Expect 15: %d\n", intIndex1);
> ptrIndex1 = strstrrWithIndex
> ("The clc regs seek him everywhere",
> "here",
> &intIndex1);
> printf("Expect 28: %d\n", intIndex1);
> printf("Expect 'h': %c\n", *ptrIndex1);
> ptrIndex1 = strstrrWithIndex
> ("Is he in Heaven? Or in Hell?",
> "?",
> &intIndex1);
> printf("Expect 15: %d\n", intIndex1);
> printf("Expect '?': %c\n", *ptrIndex1);
> ptrIndex1 = strstrrWithIndex
> ("That damn'd elusive Spinoza won't tell!",
> "Spinoza",
> &intIndex1);
> printf("Expect 20: %d\n", intIndex1);
> printf("Expect 'p': %c\n", *(ptrIndex1+1));
> printf("Expect '0': %c\n", *strstrr("0123456789", "0"));
> printf("Expect '1': %c\n", *strstrr("0123456789", "1"));
> printf("Expect '0': %c\n", *strstrr("0123456789", "0"));
> printf("Expect '9': %c\n", *strstrr("0123456789", "9"));
> printf("Expect '5': %c\n", *strstrr("0123456789", "345") + 2);
> printf("Expect '8': %c\n", *strstrr("0123456789", "89"));
> ptrIndex1 = strstrrWithIndex("0123456789A89AB",
> "89AB",
> &intIndex1);
> printf("Expect 11: %d\n", intIndex1);
> return 0;
> }

==============================================================================
TOPIC: c99 multidimensional arrays contiguous?
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Mar 21 2010 9:52 am
From: Luca Forlizzi

On 21 Mar, 17:08, Keith Thompson <ks...@mib.org> wrote:
> Luca Forlizzi <luca.forli...@gmail.com> writes:
> > On 21 Mar, 12:57, Seebs <usenet-nos...@seebs.net> wrote:
>
> > I redirect to comp.std.c maybe it's more appropiate
>
> No, you didn't; there was no Followup-To: header in your article.
>

ouch... I am a usenet newbe :-)

Do you think it's appropriate to redirect the topic in comp.std.c ?

== 2 of 6 ==
Date: Sun, Mar 21 2010 11:11 am
From: Luca Forlizzi

On 21 Mar, 14:17, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

> I hope the following clarification helps, because I am not sure we've
> got to the bottom of Luca's question. I'm not replying to you to tell
> you stuff, I am hanging this post here because this is the place with
> the right context.

it does help to me! But I am still not convinced that p2 and p3 can
legally access any int inside X
(see below)

> There are three situations:
>
> int X[10][10];
> int *p1 = &X[0][0]; /* or = X[0]; since X[0] gets converted */
> int *p2 = (void *)&X[0]; /* or = X; since X gets converted */
> int *p3 = (void *)&X;
>
> <snip>
>
> I would summarise the majority view as being that p1[10] is an invalid
> access and that p3[10] (indeed p3[99]) is valid. Luca's example is
> the same as p2 and I think the majority view is that p2[10] is also
> fine.
>
> The arguments all revolve around 6.5.6 p8 about adding to a pointer.
> That clause defines the result of the addition only when the result is
> within the array pointed "into" by the pointer. Specifically: "if the
> pointer operand points to an element of an array object, and the array
> is large enough...".

The problem that I have is not exactly the array size. You informally
say *array pointed into*
but the standard says "pointer operand points to an element of an
array object".
What exactly is an element of an array. In my mind, since X is an
array of arrays, the elements of X are arrays,
so p2 and p3 do not point to element of X (so 6.5.6 p8 does not apply
to them and X).
You (and Peter, too) seem to imply that the int objects that are
elements of the elements of X are also elements
of X (i.e. "being element" is a transitive relation). But I can't find
this in the standard.

Please note that I would love yours to be the right interpretation of
the standard, I find it more
comfortable and close to real usage of the language.

Luca

== 3 of 6 ==
Date: Sun, Mar 21 2010 11:18 am
From: Luca Forlizzi

On 21 Mar, 19:11, Luca Forlizzi <luca.forli...@gmail.com> wrote:

sorry in my previous post I mistyped a sentence. Below is the correct
text
>
> The problem that I have is not exactly the array size. You informally
> say *array pointed into*
> but the standard says "pointer operand points to an element of an
> array object".
> What exactly is an element of an array. In my mind, since X is an
> array of arrays, the elements of X are arrays,
> so p2 and p3 do not point to element of X (so 6.5.6 p8 does not apply
> to them and X).

The problem that I have is not exactly the array size. You informally
say *array pointed into* but the standard says "pointer operand points
to an *element* of an
array object". I am not convinced that the objects pointed by p2 and
p3 are elements of X.
What exactly is an element of an array? In my mind, since X is an
array of arrays, the elements of X are arrays,
so p2 and p3 do not point to element of X (so 6.5.6 p8 does not apply
to them and X).

== 4 of 6 ==
Date: Sun, Mar 21 2010 12:07 pm
From: Seebs

On 2010-03-21, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> I hope the following clarification helps, because I am not sure we've
> got to the bottom of Luca's question. I'm not replying to you to tell
> you stuff, I am hanging this post here because this is the place with
> the right context.

Sounds fine to me. I'm not totally sure I have this right, myself.

> int X[10][10];
> int *p1 = &X[0][0]; /* or = X[0]; since X[0] gets converted */
> int *p2 = (void *)&X[0]; /* or = X; since X gets converted */
> int *p3 = (void *)&X;

> (I've used void * simply to avoid questions about implementation
> defined conversions and I've written the addresses in the most
> explicit form I can, without any array to pointer conversions. I've
> also used X as the array name because 'a' is confusing in English
> text).

Okay.

> I would summarise the majority view as being that p1[10] is an invalid
> access and that p3[10] (indeed p3[99]) is valid. Luca's example is
> the same as p2 and I think the majority view is that p2[10] is also
> fine.

I would agree.

> The array X consists of 11 arrays -- the whole one and 10 sub-arrays.
> The central question is what is the array into which the various
> p[1-3] pointers point?

Good point. This is like those brain-teasers where you see a triangle
subdivided into smaller triangles, and you're supposed to figure out
how many triangles there are.

> p1 points to an element of X[0] so it is natural to deduce the array
> over which is ranges is just X[0] and not X as a whole. I don't think
> there any support in the standard for the idea that p1 points to an
> element of X, at least not formally.

Right.

> p2 is a converted from a pointer that clearly points to an element of
> X (the first one) so here one can reasonably say that the converted
> pointer may range of the whole of X.

Yes. Now, for an illustration of the boundary, consider:
int *p4 = (void *)X[0];

I think that, because "X[0]" decays into "the address of X[0][0]", this
is more like p1 than like p2.

Basically, the "&" jumps you out a level.

int i = X[0][0]; /* not useful as a pointer to anything */
/* = int */
int *q1 = (void *) &X[0][0]; /* a pointer to the contents of X[0] */
/* = pointer to int */
int *q2 = (void *) X[0]; /* a pointer to the contents of X[0] */
/* = array[10] of int, => pointer to int */
int *q3 = (void *) &X[0]; /* a pointer to the contents of X */
/* = pointer to array[10] of int */
int *q4 = (void *) X; /* a pointer to the contents of X */
/* = array[10] of array[10] of int,
=> pointer to array[10] of int */
int *q5 = (void *) &X; /* a pointer to the contents of X */
/* = pointer to array[10] of array[10] of int */

Looking at the types (see the /* = <type> */ comments), you can see
that q1 and q2 have the same type, and q3 and q4 have the same type.
q5's really a different case, but since X itself is not a member
of an array, it's treated as an array[1] of its own type, so everything
still works.

> So &X is considered (for this purpose) to be a pointer into to the
> first element of a one-element array. Thus "the array" referred to in
> paragraph 8 is the whole of X.

Yes! I believe that's the key -- &X is a pointer to a one-element array
of arrays of 10 arrays of 10 integers. So it can be used to point to anything
in any of those 10 arrays of 10 integers.

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

== 5 of 6 ==
Date: Sun, Mar 21 2010 12:13 pm
From: Seebs

On 2010-03-21, Luca Forlizzi <luca.forlizzi@gmail.com> wrote:

(context)
int X[10][10];

> You (and Peter, too) seem to imply that the int objects that are
> elements of the elements of X are also elements
> of X (i.e. "being element" is a transitive relation). But I can't find
> this in the standard.

It's not immediately obvious, but:

Consider the array object X[1] (not the pointer it decays into the moment
you refer to it in an expression, but the thing that is the operand of
sizeof(X[1]).

Clearly, X[1] is an element of X, so a pointer derived from X can be used
to access X[1].

But what can you do with X[1]? It's an array. You can look at its members.

Basically, you can use a pointer derived from X to look at X[1][5] for the
same reason that you can derive a pointer derived from X[0][0] to iterate
over the individual bytes in the object; once you have access to an object,
you're allowed to access its components.

Think about, as an example:
struct abc { int a, b, c; };
struct abc Y[10] = { { 0 } };
struct abc *p = &Y[0];
++p;
p->a = 1;

In other words: Yes, being an element-of is transitive. If you can access
an aggregate object, you can access its members.

== 6 of 6 ==
Date: Sun, Mar 21 2010 12:14 pm
From: Seebs

On 2010-03-21, Richard Bos <raltbos@xs4all.nl> wrote:
> Seebs <usenet-nospam@seebs.net> wrote:
>> sizeof(<type> [10]) == sizeof(<type>) * 10
>>
>> There's no room for any padding. The array of 10 ints must have size
>> precisely 10*sizeof(int). The array of 100 ints must have size
>> precisely 10*(10*sizeof(int)).
>>
>> So a is a region of 100*sizeof(int) bytes, while a[0] is a region of
>> 10*sizeof(int) bytes.
>
> Yes, so you have the sizes stitched up neatly. Now consider fat
> pointers.

The bounds stored in the fat pointers have to match the size of the object,
and casting allows you to view them as different types, as long as you
know for sure what the layout is. Which you do, with arrays.

==============================================================================
TOPIC: Edward Nilges' lie
http://groups.google.com/group/comp.lang.c/t/14c6f4a4afe68f60?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 21 2010 10:14 am
From: Colonel Harlan Sanders

Another instalment in this random selection of Nilges' lies.

Recently he has gone manic, posting dozens of missives every day, full
of pompous boasting and vicious tirades against his enemies, past,
present and imaginary.

Just a couple of the most outrageous and entertainingly absurd posts
to give a flavour of this :

On Fri, 19 Mar 2010 10:40:05 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:
>You backstabbed Herb Schildt and paid your way into your current job,
>and you're here for commercial gain as an employee of Wind River
>Systems. I suggest you leave.

On Sat, 20 Mar 2010 19:33:54 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:
>It is to me an amusing paradox that I'm the best C programmer in this
>newsgroup while not really knowing dick about C.

On Sun, 21 Mar 2010 09:22:59 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:
>Excuse me. I am not here to provoke anyone.

That's a killer.

Mostly they're so full of wild invective you can feel almost feel the
spittle spraying on the keyboard.

== 2 of 2 ==
Date: Sun, Mar 21 2010 12:19 pm
From: Seebs

On 2010-03-21, Colonel Harlan Sanders <Harlan@kfc.com> wrote:
> Another instalment in this random selection of Nilges' lies.

These are AWESOME!

> Recently he has gone manic, posting dozens of missives every day, full
> of pompous boasting and vicious tirades against his enemies, past,
> present and imaginary.

I was wondering why clc always had fewer posts in it than the group
browser suggested.

> Just a couple of the most outrageous and entertainingly absurd posts
> to give a flavour of this :

> On Fri, 19 Mar 2010 10:40:05 -0700 (PDT), spinoza1111
><spinoza1111@yahoo.com> wrote:
>>You backstabbed Herb Schildt and paid your way into your current job,
>>and you're here for commercial gain as an employee of Wind River
>>Systems. I suggest you leave.

... wow, that is beautiful.

I'm pretty sure I can sort of trace the heritage of that one. He's taken
the fact that standards committee members must pay dues to mean that I
"paid my way" onto the standards committee, which makes about as much sense
as accusing Doug Gwyn of "paying his way" onto the standards committee (via
his employer, presumably). And therefore, I "paid my way" into my current
job.

I have no clue about the backstabbing remark. I'm pretty sure that
backstabbing implies some kind of relationship prior to the "backstabbing",
but I really don't get it.

And no, I'm not here for commercial gain as an employee of $DAYJOB. I'm
here because I love working with and talking about C, and because it's
fun. Back when I was trying to figure out why I couldn't use getch()
on my Amiga, various CLC folks got me unstuck and pointed me towards a way
of thinking about C that has made the language a joy to work with for the
last twenty years or so. I figure I owe the newbie programmers of the world
an occasional tip. (... Oh, who am I kidding. I still learn more than I
teach.)

==============================================================================
TOPIC: How should I test for a null pointer?
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Mar 21 2010 10:22 am
From: Barry Schwarz

On 21 Mar 2010 09:31:10 GMT, Seebs <usenet-nospam@seebs.net> wrote:

>On 2010-03-21, Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
>> How should I test for a null pointer within a C program?
>
> if (!ptr)
>
>in my opinion.
>
>> I have also seen the following, but I am unsure on this because can the value
>> of a null pointer be guaranteed to be zero? If it is not zero, does the pling
>> operator recognize this anyway, and the condition still works?
>
>> if ( !ptr ) { dosomething }
>
>!ptr is the same as (ptr != 0), and the 0 would be converted to a null
>pointer.

Of course you meant ptr == 0.

>
>In short, no matter what pattern of bits in memory represents a "null
>pointer", it compares equal to zero, and is thus "false".
>
>-s

--
Remove del for email

== 2 of 6 ==
Date: Sun, Mar 21 2010 11:05 am
From: Hamiral

Mark Hobley wrote:
> How should I test for a null pointer within a C program?
>
> Presumably the following will work:
>
> if ( ptr == NULL ) { dosomething }
> if ( !ptr ) { dosomething }

if(!ptr) is very common, and everybody should undestand it.
But I personnally prefer being the most clear I can, so I always use
if(ptr == NULL) -- and in general I never use if(!anything)
Using NULL shows a bit more that you're dealing with pointers.

Ham

== 3 of 6 ==
Date: Sun, Mar 21 2010 11:43 am
From: Nick <3-nospam@temporary-address.org.uk>

Hamiral <hamiral@hamham.com> writes:

> Mark Hobley wrote:
>> How should I test for a null pointer within a C program?
>>
>> Presumably the following will work:
>>
>> if ( ptr == NULL ) { dosomething }
>> if ( !ptr ) { dosomething }
>
> if(!ptr) is very common, and everybody should undestand it.
> But I personnally prefer being the most clear I can, so I always use
> if(ptr == NULL) -- and in general I never use if(!anything)
> Using NULL shows a bit more that you're dealing with pointers.

! works well in some constructions:

"if(!done)", for example, reads as "if not done".
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 4 of 6 ==
Date: Sun, Mar 21 2010 12:02 pm
From: pete

Nick wrote:
> Hamiral <hamiral@hamham.com> writes:
>
>> Mark Hobley wrote:
>>> How should I test for a null pointer within a C program?
>>>
>>> Presumably the following will work:
>>>
>>> if ( ptr == NULL ) { dosomething }
>>> if ( !ptr ) { dosomething }
>> if(!ptr) is very common, and everybody should undestand it.
>> But I personnally prefer being the most clear I can, so I always use
>> if(ptr == NULL) -- and in general I never use if(!anything)
>> Using NULL shows a bit more that you're dealing with pointers.

I also use NULL when testing pointers, for the same reason.
and I use '\0' when testing for a null byte char.

>
> ! works well in some constructions:
>
> "if(!done)", for example, reads as "if not done".

if (!X) works well when (X) is boolean in nature,
such as when (X) is a ctype character testing function.

if (!isalnum(c))
if (!isspace(c))

--
pete

== 5 of 6 ==
Date: Sun, Mar 21 2010 12:22 pm
From: Seebs

On 2010-03-21, Barry Schwarz <schwarzb@dqel.com> wrote:
> On 21 Mar 2010 09:31:10 GMT, Seebs <usenet-nospam@seebs.net> wrote:
>>!ptr is the same as (ptr != 0), and the 0 would be converted to a null
>>pointer.

> Of course you meant ptr == 0.

... Yeah.

I think at this point I can safely say that no one is going to mistake
me for one of those natural wizards who never makes obvious mistakes, huh.

== 6 of 6 ==
Date: Sun, Mar 21 2010 12:33 pm
From: Hamiral

Of course, I never test booleans like if(somebool == TRUE)...
I thought that was evident enough that people doing this just didn't
understand boolean expressions ;)

Ham

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

== 1 of 1 ==
Date: Sun, Mar 21 2010 12:10 pm
From: Rainer Weikusat

Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>
writes:
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

In addition to the useless crosspost, the HTML is also unkind.
I was actually seriously trying to edit this into a readable text in
order to address your somewhat 'weird' statements about malloc
implementations not written by yourself but quickly grew tired of the
effort. Feel free to repost this in human-readable form and with a
selection of 'newsgroups' that lets you look less like a troll.

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

== 1 of 1 ==
Date: Sun, Mar 21 2010 12:10 pm
From: Eric Sosman

On 3/21/2010 11:54 AM, Richard Bos wrote:
> Dr Malcolm McLean<malcolm.mclean5@btinternet.com> wrote:
>
>> On 20 Mar, 13:08, markhob...@hotpop.donottypethisbit.com (Mark Hobley)
>
>>> #define USMALL unsigned int
>>>
>> The problem with that is that the code rapidly becomes almost
>> unreadable.
>>
>> void zeroduplicates(UBIG *x, USMALL N)
>> {
>> USMALL i;
>> for(i=0;i<N-1;i++)
>> if(x[i] == x[i+1])
>> x[i] = 0;
>> }
>>
>> it's hard to spot the bug.
>
> Pray tell. It's so hard to spot that I can't spot it.

zeroduplicates(pointer, 0);

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

==============================================================================
TOPIC: Does the name Edward Nilges ring a bell?
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 21 2010 12:14 pm
From: pete

barbara@bookpro.com wrote:
> On Sun, 21 Mar 2010 07:16:50 -0500, pete <pfiland@mindspring.com>
> wrote:
>
>> Jonathan de Boyne Pollard wrote:
>>>>>> does the name Edward Nilges ring a bell?
>> My favorite Mike Godwin quote:
>>
>> "Not only do I not recall having threatened Ed Nilges,
>> but I am clueless as to how I might meaningfully
>> threaten Nilges with anything, that Nazi!" -- Mike Godwin
>
> IFYPFY.

A point of trivia, is that Godwin's Law is actually about N1ggles.

Another point of trivia is that N1ggles,
much like our Kibo,
greps newsfeed for his own name.

--
pete

== 2 of 2 ==
Date: Sun, Mar 21 2010 12:15 pm
From: Seebs

On 2010-03-21, Peter Flass <Peter_Flass@Yahoo.com> wrote:
> Seebs wrote:
>> Something like! I'm curious, but not curious enough to try to strip
>> it down to a reproducer.

> Since the original code is a bug anyway, why bother?

Because understanding how undefined behavior can produce a particularly
surprising result is often useful to me.

==============================================================================
TOPIC: nothing much
http://groups.google.com/group/comp.lang.c/t/3040e7c069dc5b93?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 21 2010 1:01 pm
From: Phred Phungus

Eric Sosman wrote:
> On 3/19/2010 1:49 AM, Phred Phungus wrote:
>> It's nice to see that russians are free enough to spread spam porn.
>>
>> I read elsewhere that signed integer division was undefined in C, with
>> maybe a change having come in C99.
>>
>> Is that true?
>
> No, with Yes.
>
> 17 / 3 and 17 % 3 are and always have been well-defined,
> evaluating to 5 and 2, respectively.
>
> 17 / -3 and 17 % -3 are also well-defined, and have been
> ever since the ANSI Standard was adopted. But in that Standard
> they could evaluate to -5 and -2 or to -6 and 1, the choice
> being left to the implementation. The implementation had to
> document its choice (and could not produce some third result),
> so again the division operation was well-defined, although
> (potentially) defined differently on different systems, just
> as CHAR_MIN is zero on some systems, negative on others.
>
> C99 *did* make a change: It removed the implementation's
> freedom of choice. The results must now be -5 and -2, and the
> pair -6 and 1 are forbidden. The operations are still defined.
>
> Integer division or mod by zero, signed or unsigned, has
> always been undefined. There's a rumor that the Committee is
> considering making INT_MIN % -1 (which must now be 0) either
> undefined or implementation-defined, I'm not sure which.
>

An interesting read. Beyond what Ben and Lawrence had to comment, I was
curious about this language:

> The implementation had to
> document its choice ....

Implementations have to document something? How general is this
requirement?
--
fred

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

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, March 21, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts