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

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

comp.lang.c@googlegroups.com

Today's topics:

* Implementing strstr - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
* Cheap Wholesale Armani T-Shirt BBC T-Shirt Christina Audigier Ecko T-Shirt
Gucci Ralph Lauren Polo T-Shirt(www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/af2082919ce0b82d?hl=en
* Edward Nilges' lie - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/14c6f4a4afe68f60?hl=en
* Containers: The iterator object - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
* Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
* How should I test for a null pointer? - 9 messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
* Ask for book for efficient coding in C - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/1b697accaac68aeb?hl=en
* 16:32 far pointers in OpenWatcom C/C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
* usage of size_t - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* Public/private in C - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/85a22d944f826cec?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en

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

== 1 of 4 ==
Date: Mon, Mar 22 2010 5:48 am
From: Richard Heathfield

spinoza1111 wrote:
> On Mar 22, 5:24 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> spinoza1111wrote:
>>> On Mar 22, 2:47 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> <snip>
>>>> Ben is a knowledgeable contributor to this newsgroup, and most polite
>>>> with it. You, like Richard Bos, would do well to try to emulate him
>>>> rather than insult him.
>>> I'm not "insulting" him.
>> No, you only called him an asshole. That's not an insult, is it? Of
>> course not.
>
> No

Wrong.

<nonsense snipped>

>> <some nonsense snipped>
>>
>>> You have posted letters you claim that I have written
>> No, I haven't. If you disagree, you can easily prove your point by
>> posting the message ID in which I did this. Since I didn't, however, you
>> can't prove your point. You will therefore have to resort to weasel
>> words, pop psychiatry, downright lies, or non sequiturs, as usual.
>
> When your type is cornered you bleat for evidence.

Yup, them's weasel words all right.

> Richard, you posted
> a forgery. It's legally actionable now.

No, I didn't, and no, it isn't, and no, you won't, because you know
you'll end up paying my costs if you do.

<snip>

>>> and you have
>>> lied about my publication in comp.risks.
>> Wrong again.
>
> Yes, you did.

You need to look up the meaning of "lie". You have completely
misunderstood what it means.

<nonsense snipped>

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

== 2 of 4 ==
Date: Mon, Mar 22 2010 8:18 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <87wrx4x19s.fsf@kilospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> replied to Ben, thusly:
>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> spinoza1111 <spinoza1111@yahoo.com> writes:
>> I don't expect you to change your style -- you've evolved it to
>> provoke a response here
>
>== TROLL

Ben is a troll now?

Wow - I guess you really have to watch your back in this NG...

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

== 3 of 4 ==
Date: Mon, Mar 22 2010 8:27 am
From: spinoza1111

On Mar 22, 11:18 pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <87wrx4x19s....@kilospaz.fatphil.org>,
> Phil Carmody  <thefatphil_demun...@yahoo.co.uk> replied to Ben, thusly:
>
> >Ben Bacarisse <ben.use...@bsb.me.uk> writes:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> I don't expect you to change your style -- you've evolved it to
> >> provoke a response here
>
> >== TROLL
>
> Ben is a troll now?
>
> Wow - I guess you really have to watch your back in this NG...
>
> --
> (This discussion group is about C, ...)
>
> Wrong.  It is only OCCASIONALLY a discussion group
> about C; mostly, like most "discussion" groups, it is
> off-topic Rorsharch revelations of the childhood
> traumas of the participants...

Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
photographed on a motorcycle in his first book) used to give guys like
Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
have been nursing the hurt ever since. And confronting their bullying
is NOT itself bullying.

== 4 of 4 ==
Date: Mon, Mar 22 2010 8:29 am
From: spinoza1111

On Mar 22, 8:48 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Mar 22, 5:24 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> spinoza1111wrote:
> >>> On Mar 22, 2:47 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> <snip>
> >>>> Ben is a knowledgeable contributor to this newsgroup, and most polite
> >>>> with it. You, like Richard Bos, would do well to try to emulate him
> >>>> rather than insult him.
> >>> I'm not "insulting" him.
> >> No, you only called him an asshole. That's not an insult, is it? Of
> >> course not.
>
> > No
>
> Wrong.
>
> <nonsense snipped>
>
> >> <some nonsense snipped>
>
> >>> You have posted letters you claim that I have written
> >> No, I haven't. If you disagree, you can easily prove your point by
> >> posting the message ID in which I did this. Since I didn't, however, you
> >> can't prove your point. You will therefore have to resort to weasel
> >> words, pop psychiatry, downright lies, or non sequiturs, as usual.
>
> > When your type is cornered you bleat for evidence.
>
> Yup, them's weasel words all right.
>
> > Richard, you posted
> > a forgery. It's legally actionable now.
>
> No, I didn't, and no, it isn't, and no, you won't, because you know
> you'll end up paying my costs if you do.
>
> <snip>
>
> >>> and you have
> >>> lied about my publication in comp.risks.
> >> Wrong again.
>
> > Yes, you did.
>
> You need to look up the meaning of "lie". You have completely
> misunderstood what it means.

The British lower middle class have a touching faith in dictionaries
that started with prize giveaways of Johnson's Dictionary, but Becky
Sharp threw it out her carriage window in Thackeray's Vanity Fair.
Some of us learn words by reading, not by memorizing the dictionary,
and you tell lies, Richard.
>
> <nonsense snipped>
>
> --
> 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: Cheap Wholesale Armani T-Shirt BBC T-Shirt Christina Audigier Ecko T-
Shirt Gucci Ralph Lauren Polo T-Shirt(www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c/t/af2082919ce0b82d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 6:31 am
From: yoyo

T-shirt
Cheap Wholesale 5ive Jungle T-Shirt <www.vipchinatrade.com paypal
payment>
Cheap Wholesale A&F T-Shirt
Cheap Wholesale Adidas T-Shirt low price with high quality
Cheap Wholesale AFF T-Shirt low price with high quality
Cheap Wholesale Akademiks T-Shirt <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Armani T-Shirt
Cheap Wholesale Baby T-Shirt low price with high quality
Cheap Wholesale Bape T-Shirt low price with high quality
Cheap Wholesale BBC T-Shirt
Cheap Wholesale Blar Label T-Shirt <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Burberry T-Shirt
Cheap Wholesale Christina Audigier T-Shirt low price with high
quality
Cheap Wholesale Coogi T-Shirt
Cheap Wholesale Crown Holder T-Shirt low price with high quality
Cheap Wholesale D&G T-Shirt
Cheap Wholesale Diesel T-Shirt low price with high quality
Cheap Wholesale Ecko T-Shirt
Cheap Wholesale ED Hardy T-Shirt <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Evisu T-Shirt
Cheap Wholesale G-STAR T-Shirt low price with high quality
Cheap Wholesale GGG T-Shirt
Cheap Wholesale Gucci T-Shirt low price with high quality
Cheap Wholesale juicy T-Shirt
Cheap Wholesale Lacoste T-Shirt <www.vipchinatrade.com paypal
payment>
Cheap Wholesale LEVI S T-Shirt
Cheap Wholesale LV T-Shirt low price with high quality
Cheap Wholesale Nike T-Shirt low price with high quality
Cheap Wholesale Ralph Lauren Polo T-Shirt low price with high
quality
Cheap Wholesale Rocawear T-Shirt
Cheap Wholesale SMET T-Shirt low price with high quality
Cheap Wholesale Smful T-Shirt low price with high quality
Cheap Wholesale Versace T-Shirt <www.vipchinatrade.com paypal payment>

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

== 1 of 1 ==
Date: Mon, Mar 22 2010 6:53 am
From: spinoza1111

On Mar 22, 8:26 pm, Colonel Harlan Sanders <Har...@kfc.com> wrote:
> You can't get a better example of a Nilgean barefaced denial of the
> facts than this. Though he professes to welcome corrections, he can't
> help but perceive anyone pointing out his errors as attacking his
> manhood, and lashes back reflexively. (One explanation of his
> inability to hold a job in the field.)

You're here to bully: you don't contribute code.
>
> Ben Bacarisse spent considerable time and effort to disentangle and
> critique Nilges' code, for which he was rewarded with being called an
> "idiot", "infantilized", "deskilled" and an "asshole". Descriptions

No, that was for accidentally embarassing me. I apologized to him for
my misapprehension of what was his mistake. In fact, in the case you
mention, I'd immediately corrected my code based on Ben's correction
and credited him: but he doesn't want me to credit him.

> which Nilges insists are not insults, but simply  a measured response
> in his eyes.
> Evidently not only is Nilges' dialect of C unique, so is his English.
>
> On Sat, 20 Mar 2010 19:10:27 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >You're an idiot, Bacarisse. To relax on a 30 minute ferry ride, I get
> >my notebook out and spend a little time documenting and then writing
> >code that even with bugs is better than any of the crap posted here.
> >You find a typo but now that you've been infantilized and deskilled

Taken out of context. Yes, sometimes, he's an idiot when he doesn't
see the forest for the trees, or, like most programmers (who are
idiots in my opinion), thinks grammatical English in comments are
"convoluted".

>
> On Sun, 21 Mar 2010 21:06:07 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >lies. I was trying to CREDIT you, asshole, in a public newsgroup where
> >credit and discredit is seen by current and potential employers and
> >clients.

Yes, asshole, I was trying to credit him.
>
> >The main trouble with many of you is that you literally think that
> >hardware and stupid ideas from the past are more important than
> >decency, self-respect and personal reputation.
>
> On Mon, 22 Mar 2010 01:28:16 -0700 (PDT),spinoza1111
>
>
>
> <spinoza1...@yahoo.com> wrote:
> >> Ben is a knowledgeable contributor to this newsgroup, and most polite
> >> with it. You, like Richard Bos, would do well to try to emulate him
> >> rather than insult him.
>
> >I'm not "insulting" him. Merely using strong language in response to
> >what appeared at the time to be offensive is not "insulting" a person.

Yup. I'm not a prissy little GIRL like so many younger men who won't
use "foul" language but instead prefer on the job backstabbing,
bullying, and personal destruction.

==============================================================================
TOPIC: Containers: The iterator object
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 22 2010 7:12 am
From: Andrew Poelstra

On 2010-03-22, Ian Collins <ian-news@hotmail.com> wrote:
> On 03/22/10 10:44 PM, jacob navia wrote:
>> Ian Collins a écrit :
>>> On 03/22/10 10:19 AM, jacob navia wrote:
>>>> The iterator is still "valid" but will always return NULL. It just
>>>> doesn't matter.
>>>
>>> I though returning NULL indicated that the iterator is at the end of
>>> the container?
>>>
>>
>> Actually it will call the currently defined error function with the
>> error "CONTAINER_ERROR_OBJECT_CHANGED". If that function returns (and
>> doesn't abort the program) the iterator returns NULL.
>
> Then I think that's wrong. It is one reason why I said it would be a
> nightmare defining the operations that do and don't invalidate an iterator.
>

I think that as far as modifying lists while iterators are active
goes, you are simply Not Supposed To Do That. Jacob is trying to
make sure that if you do, something consistent will happen, even
if that's something potentially confusing.

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 2 of 2 ==
Date: Mon, Mar 22 2010 7:46 am
From: Eric Sosman

On 3/22/2010 8:01 AM, jacob navia wrote:
> Eric Sosman a écrit :
>> On 3/21/2010 5:01 PM, Ian Collins wrote:
>>> On 03/22/10 03:07 AM, Eric Sosman wrote:
>>>> [...] Keep a "change counter"
>>>> in the collection, incremented each time something is inserted
>>>> or removed. Copy the counter into the iterator when the iterator
>>>> is created. Each time the iterator is used, compare its count
>>>> to the collection's count; a mismatch means Danger, Will Robinson!
>>>
>>> Potential danger, but in many case the iterator would still be valid.
>>> Attempting to define and support those cases would be a nightmare. For
>>> example the iterator would still be valid after items have been inserted
>>> or removed in front of or behind it.
>>
>> Perhaps I'm over-generalizing, but I assumed the notion of
>> "iterator" was intended to extend to all containers, not just
>> ordered containers. For example, if insertion or deletion causes
>> a hash table to reorganize while an iteration is in progress,
>> things get hairy.
>>
>
> The rule is very easy

... though the implementation may not be.

> If you change the contents of a container, all iterators to it are invalid
> and will call the error routine.

That's the easy part.

> The only changes are allowed through the iterator you are using. You can
> delete
> and replace items, or add before/after if it is a sequential container.
> If you
> do this, any OTHER iterators are invalidatee of course, but not the
> iterator you use
> to do the change.

That's the hard part. FWIW, Java dodges the problem for hash
tables by (1) permitting only deletions during iteration, not
insertions, and (2) re-hashing only when a table grows, not when
items are removed. Thus, an iterator can be sure that the table
will not re-hash itself during iteration. If reorganizations could
occur, keeping the iteration sane would (it seems to me) be a good
deal more difficult.

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

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

== 1 of 1 ==
Date: Mon, Mar 22 2010 7:28 am
From: Tim Rentsch

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

> On 2010-03-06, Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> wrote:
>> It seems worth pointing out that this comment is of the form "I
>> have some private knowledge, not known to the general public, and
>> about which I'm not going to give any real specifics, that makes
>> me think I'm right." It's great if made to win an argument.
>> Not as good if the point is to communicate reasoning and reach
>> shared understanding.
>
> I was responding to the allegation that I hadn't thought about it enough,
> not necessarily to the underlying substance.

Just for the record it wasn't my intention to make such an allegation.
Perhaps a prediction that you would reach a new conclusion upon
consideration of new facts.

> I agree that it's not a persuasive argument that my position is correct;
> it is offered only as an argument that my position is not unconsidered.

My confusion. I never considered your position to be unconsidered;
sorry if it came across otherwise.

>>> Now, maybe that makes gcc "not a good compiler", but it certainly makes gcc
>>> the sort of compiler that customers appear to want, which is one which does
>>> its best to minimize errors rather than accepting a larger number of errors
>>> in order to ensure that they're all of the same sort.
>
>> It's not really possible to give a useful response to this,
>> because there is no knowledge generally publically available
>> on which to base a response. Effectively the statement just
>> stops further communication. Is that what you wanted? Or
>> were you meaning to do something else?
>
> You have a fair point here. I guess, to put it another way: You have
> an argument (and it is a sound one) that we ought to prefer a compiler
> which gives warnings whenever it's not totally sure, rather than risking
> not giving a warning. I personally prefer one which does its best to guess
> right, even if that means it may be wrong in either direction. I don't
> much rely on the warnings (I hardly ever see them anyway, because I'm a
> habitual initializer of variables), but when I do see spurious warnings,
> they annoy me a great deal.

I have to admit I don't like spurious warnings either. However there
are (at least) two different modes for acting on warning messages, and
I think that difference may be relevant here. One mode I might call
"lint like", where the warnings are taken as informational. The other
mode is (for lack of a better term) "-Werror like", where warnings
cause compilation to fail. I almost always use -Werror (and use lint
only rarely). Of course this means the set of warnings reported must
be at least somewhat selective, since there certainly are warning
conditions that are more about style than substance. I find it helps
to have the -Werror warnings that are reported be conservative (ie,
possibly false positives, but never false negatives), for two reasons.
One, if the compiler has a hard time figuring it out, people sometimes
do also, and even if I can see that a warning isn't strictly necessary
I don't want to assume all my co-workers can also (and also vice
versa). Two, like it or not, when routinely using -Werror to identify
and fail on certain warning conditions, people tend not to think so
much about those particular conditions, expecting the compiler to
catch their oversights. So it seems better to have warning conditions
be "hard" rather than "soft", with the understanding that we're
talking about using -Werror and that the set of warnings being tested
is not everything but a specifically chosen set. So at the end of
day I still grumble to myself about spurious warnings, but I think
it's better for overall quality and productivity to suffer these
once in a while to get the benefits of having hard-edged warning
conditions.

>> To get back on track, two things: first, I'm talking about
>> warnings where "optimizations" are based on changing the expressed
>> intent by exercising a complete freedom of choice where undefined
>> behavior is involved; second, warnings about these can be given
>> exactly because the compiler has available _perfect knowledge_
>> about whether the condition in question has occurred -- it's not
>> any kind of heuristic like the case of uninitialized variables.
>
> Ahh! I see. I think we were talking about two separate kinds of cases.
> One is warnings about possibly-uninitialized values, where I favor gcc's
> policy of trying for the most accurate warnings it can, even though this
> means it sometimes omits a warning.

Right, I was talking about a different situation, and that was
probably the most important point of what I was saying.

> I would not object in the least to a warning flag that, say, requests warnings
> whenever gcc optimizes a test out because it's concluded that a pointer is
> dereferenced, and therefore non-null. I would even think it should probably
> be on by default, because honestly, I can't think of a case where I would
> intentionally write code subject to such an optimization.

I probably could construct such cases if I put my mind to it,
perhaps even "natural" ones (I'm thinking macro calls here),
but I agree, nine times out of ten it's just bad thinking.

> Come to think of it, I think I'll go file that as an enhancement request with
> our vendor.
>
> (Actually, I think I can. Imagine a function which has as part of its
> contract that its argument is non-null... Oh, but wait, there'd be no test
> to optimize in that case. Hmm.)
>
>> Is my point a little bit clearer now?
>
> I think so.

It certainly seems so. As predicted, I thought you
would see my point, once you saw my point. :)

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

== 1 of 9 ==
Date: Mon, Mar 22 2010 7:28 am
From: Anand Hariharan

On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
Hobley) wrote:
> How should I test for a null pointer within a C program?
>
> Presumably the following will work:
>
[snip]
>
> if ( !ptr ) { dosomething }
>

My follow-up question to the group is, how do you read the above line
of code in your head (or out loud)?

I find "if not non-null pointer" quite awkward.

- Anand

== 2 of 9 ==
Date: Mon, Mar 22 2010 7:41 am
From: Nick Keighley

On 21 Mar, 17:22, Barry Schwarz <schwa...@dqel.com> wrote:
> On 21 Mar 2010 09:31:10 GMT, Seebs <usenet-nos...@seebs.net> wrote:
> >On 2010-03-21, Mark Hobley <markhob...@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".

which is why I don't use the !ptr form, I find it too error prone...

== 3 of 9 ==
Date: Mon, Mar 22 2010 7:42 am
From: Dr Malcolm McLean

On 22 Mar, 14:28, Anand Hariharan <mailto.anand.hariha...@gmail.com>
wrote:
> On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
>
> Hobley) wrote:
> > How should I test for a null pointer within a C program?
>
> > Presumably the following will work:
>
> [snip]
>
> > if ( !ptr ) { dosomething }
>
> My follow-up question to the group is, how do you read the above line
> of code in your head (or out loud)?
>
> I find "if not non-null pointer" quite awkward.
>
"If pling pointer, do something"

== 4 of 9 ==
Date: Mon, Mar 22 2010 7:46 am
From: Nick Keighley

On 21 Mar, 18:43, Nick <3-nos...@temporary-address.org.uk> wrote:
> Hamiral <hami...@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".

I'm fine with using booleans this way, just not pointers

if (!ptr), doesn't read as "if not pointer". I suppose I could read
it as "if null-pointer"

== 5 of 9 ==
Date: Mon, Mar 22 2010 8:19 am
From: Ben Bacarisse

Anand Hariharan <mailto.anand.hariharan@gmail.com> writes:

> On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
> Hobley) wrote:
>> How should I test for a null pointer within a C program?
>>
>> Presumably the following will work:
>>
> [snip]
>>
>> if ( !ptr ) { dosomething }
>>
>
> My follow-up question to the group is, how do you read the above line
> of code in your head (or out loud)?
>
> I find "if not non-null pointer" quite awkward.

FWIW: "if not ptr" where I usually vocalise "ptr" as "pointer".

--
Ben.

== 6 of 9 ==
Date: Mon, Mar 22 2010 8:20 am
From: spinoza1111

On Mar 22, 11:19 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
> > Hobley) wrote:
> >> How should I test for a null pointer within a C program?
>
> >> Presumably the following will work:
>
> > [snip]
>
> >> if ( !ptr ) { dosomething }
>
> > My follow-up question to the group is, how do you read the above line
> > of code in your head (or out loud)?
>
> > I find "if not non-null pointer" quite awkward.
>
> FWIW: "if not ptr" where I usually vocalise "ptr" as "pointer".

Why not spell it out as I do consistently in my "convoluted" code
after my pre-Szymonyi Hungarian?
>
> --
> Ben.

== 7 of 9 ==
Date: Mon, Mar 22 2010 8:24 am
From: spinoza1111

On Mar 22, 10:28 pm, Anand Hariharan
<mailto.anand.hariha...@gmail.com> wrote:
> On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
>
> Hobley) wrote:
> > How should I test for a null pointer within a C program?
>
> > Presumably the following will work:
>
> [snip]
>
> > if ( !ptr ) { dosomething }
>
> My follow-up question to the group is, how do you read the above line
> of code in your head (or out loud)?
>
> I find "if not non-null pointer" quite awkward.

I would code if (!ptrToString) { ... } or if (!ptrString)...

Rolls off the tongue:

If not pointer to string
Do something
Otherwise, guys,
Do something else

If not pointer string
Don't worry about a goddamn thing
We will do something sensible
Otherwise something which at a minimum is not reprehensible.

Seriously, the usual crap code I see hear is unusable orally in
structured walkthroughs and pair programming.

If p can't you c
Any flies on me

>
> - Anand

== 8 of 9 ==
Date: Mon, Mar 22 2010 8:29 am
From: Keith Thompson

Anand Hariharan <mailto.anand.hariharan@gmail.com> writes:
> On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
> Hobley) wrote:
>> How should I test for a null pointer within a C program?
>>
>> Presumably the following will work:
>>
> [snip]
>>
>> if ( !ptr ) { dosomething }
>
> My follow-up question to the group is, how do you read the above line
> of code in your head (or out loud)?
>
> I find "if not non-null pointer" quite awkward.

I read it as "if not ptr" or "if not pointer". I have to mentally
redefine the usual meaning of "not" for this to make sense. It's not
a real problem, but personally I prefer "if (ptr == NULL)".

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

== 9 of 9 ==
Date: Mon, Mar 22 2010 8:51 am
From: Seebs

On 2010-03-22, Keith Thompson <kst-u@mib.org> wrote:
> I read it as "if not ptr" or "if not pointer". I have to mentally
> redefine the usual meaning of "not" for this to make sense. It's not
> a real problem, but personally I prefer "if (ptr == NULL)".

Oddly, that fits my sense of "not", so it doesn't require redefinition to
me. I don't see a cognitive difference between:
x = count(kitties);
if (x) {
}

and
x = ptr_to_kitties();
if (x) {
}

They're both doing something if there were kitties.

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

==============================================================================
TOPIC: Ask for book for efficient coding in C
http://groups.google.com/group/comp.lang.c/t/1b697accaac68aeb?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 7:48 am
From: Tim Rentsch

websnarf <websnarf@gmail.com> writes:

> On Feb 26, 1:07 pm, Dann Corbit <dcor...@connx.com> wrote:
>> In article <6a50a5e9-62b1-4277-9e72-22ecde876730
>> @q16g2000yqq.googlegroups.com>, christian....@cbau.wanadoo.co.uk says...
>> > The important thing: Measure it. If you are not willing to spend the
>> > time to measure the speed of your code, that on its own proves that
>> > you shouldn't waste your time optimising it.
>>
>> I agree with this wholeheartedly.
>>
>> There is one thing though, and it has to do with initial creation of the
>> code.
>>
>> If you know that a particular function is asymptotically superior and
>> you know that it is possible for the data set to grow, choosing the more
>> efficient algorithm is usually the safer choice. Asymptotically
>> superior algorithms can definitely be inferior with smaller data sets,
>> but they won't go into the crapper when the data blows up into a giant
>> set that you were not expecting.
>>
>> So (IMO) the initial design phase is a good place for some thought in
>> this regard.
>>
>> After the code is written, never try to optimize without measuring
>> first.
>
> I have two main comments on this:
>
> 1) You can *measure* performance before you even write code. [snip]

It's not possible to measure the performance of anything if the thing
to be measured doesn't exist. You can analyze what you expect the
performance might be, or you can measure the performance of something
else, but you can't measure the performance (or anything else) of a
piece of code until the code has been written.

==============================================================================
TOPIC: 16:32 far pointers in OpenWatcom C/C++
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 7:59 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <80otshFelcU2@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:
>On 03/22/10 10:56 PM, Jonathan de Boyne Pollard wrote:
>
>Please stop this asinine cross posting.

(Reading in comp.lang.c, the funniest and most entertaining newsgroup on
the Usenet)

Yes, I was just about to ask where the CLC topicality police were hiding
out and why they were ignoring this thread. I was about to make the
usual comment about the double standard - how only the newbies get
pounded on for being "OT".

Thanks Ian - you've restored my faith in (what passes for ... in CLC)
humanity.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Mar 22 2010 8:06 am
From: Tim Rentsch

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

> On 2 Mar, 23:52, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu>
> wrote:
>>
>> Why not just this:
>>
>> for(i=N-1; i != -1; i--)
>>
>> which works for any integer type, either signed or
>> unsigned, whose conversion rank is at least that of int.
>>
> i is an unsigned type, and we're terminating the loop when it doesn't
> equal -1.
>
> Anyone who doesn't know C like the back of his hand will curse you for
> writing code like that.

They won't curse me, because I don't write such code. Among
other things, it transgresses the warning criteria for comparing
signed and unsigned operands. My point was that it is more
robust, in terms of possible changes in type, to omit the cast
and compare against just -1.

A better way to write the condition is 'i + 1 != 0', which avoids
both the signed/unsigned comparison warning and the above criticism
about loop termination. Furthermore, on writing this for loop as

for(i=N-1; i + 1 != 0; i--)

it is immediately obvious that it could be rewritten as

i = N;
while(--i + 1 != 0)

or more simply just as

i = N;
while(i-- != 0)

which is how it should have been written in the first
place.

== 2 of 3 ==
Date: Mon, Mar 22 2010 8:16 am
From: Tim Rentsch

lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> In article <6da81ea6-c7bc-4e1c-9287-88c1902e1107@q23g2000yqd.googlegroups.com>, Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On 2 Mar, 23:52, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu>
>> wrote:
>>>
>>> Why not just this:
>>>
>>> for(i=N-1; i != -1; i--)
>>>
>>> which works for any integer type, either signed or
>>> unsigned, whose conversion rank is at least that of int.
>>>
>> i is an unsigned type, and we're terminating the loop when it doesn't
>> equal -1.
>>
>> Anyone who doesn't know C like the back of his hand will curse you for
>> writing code like that.
>
> Integer promotions and integer conversions are very important. I think
> with the stream of published security vulnerabilities due to integer
> overflows they should start to become common knowledge (not their
> details, but at least their existence). I agree that a bit more
> verbosity would be helpful, as in "(type)-1".
>
> --o--
>
> Yet another question on integer overflow. This was bugging me for some
> time.
>
> When *converting* an already existing value (ie. the result of an
> evaluated expression) to a signed integer type, so that the value to
> convert is not representable by the target type, the result is
> implementation-defined (in C89), or the result is implementation-defined
> or an implementation-defined signal is raised (in C99).
>
> However, when *computing* such a value by arithmetic operators, if the
> result cannot be produced at all, as represented in the signed integer
> "target type", selected by the individual operators, then the behavior
> is undefined.
>
> Suppose "int" has one sign bit, 31 value bits, no padding bits; and that
> "long" has one sign bit, 63 value bits, no padding bits. Then
>
> int i = (long)INT_MAX + INT_MAX;
>
> initializes "i" to an implementation-defined value (or raises an
> implementation-defined signal, under C99), while
>
> int i = INT_MAX + INT_MAX;
>
> is undefined behavior (in the evaluation of the additive operator).
>
> For unsigned integer types, both categories (ie. conversion and the
> arithmetic operators) define reduction modulo (maxval+1) for such cases.
>
> /* conversion, and suppose no overflow in "long unsigned" */
> unsigned u1 = (long unsigned)UINT_MAX + UINT_MAX;
>
> /* overflow */
> unsigned u2 = UINT_MAX + UINT_MAX;
>
> Both variables shall be initialized to "UINT_MAX - 1u".
>
>
> Is this correct? I was (am) confused about the distinction between
> implementation-defined and undefined behavior in case of the signed
> integer types.

Yes, your analysis is exactly correct as far as I can see,
except that the '/* overflow */' comment is right only
informally, ie, the meaning is a little different from
how the Standard uses the term 'overflow'.

In particular, _computing_ an out-of-range value in a signed
type is undefined behavior, but _converting_ an out-of-range
value to a signed type is implmentation-defined behavior
(or an ID signal as you mention).

I think there also are cases involving converting floating
point values to both signed and unsigned types that are
undefined behavior, but I haven't taken the time to look
these up.

== 3 of 3 ==
Date: Mon, Mar 22 2010 8:23 am
From: Tim Rentsch

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>>> The only plausible scenario I can think of is an implementation
>>> that deliberately restricts the size of an object for some reason.
>>> If some external magic provides the address of a huge object, it's
>>> not clear that a program could even index it (an attempt to do so
>>> presumably would invoke undefined behavior). I suspect we're in
>>> DS9K territory.
>>
>> Not at all. Choosing a 32-bit size_t for 64-bit virtual address
>> space is a perfectly reasonable choice on most home-PC-class
>> machines. Very very few objects will have a size larger than 4 GB;
>> why make every single datum of type size_t pay an extra 4 bytes
>> that will basically never be used?
>
> Ok, not quite DS9K; maybe DS8K?

Perhaps you're thinking of the DS8080.

==============================================================================
TOPIC: Public/private in C
http://groups.google.com/group/comp.lang.c/t/85a22d944f826cec?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 8:28 am
From: ImpalerCore

On Mar 21, 6:20 pm, jacob navia <ja...@jacob.remcomp.fr> wrote:
> As you may have noticed, when I proposed the iterator object I splitted
> the object into a public part (the first 3 fields) an an undisclosed
> part specific to each iterator.
>
> This inheritance implementation looks like this:
>
> In the header file:
>
> typedef struct PublicStruct {
>         // public fields
>
> } Public;
>
> In the implementation file (.c) we do:
>
> typedef struct Inherited {
>         Public p;
>         // follow the private fields
>
> } Private;
>
> The interface for all functions is just the public structure:
>
> void fn1(Public *);
> void fn2(Public *);
>
> The implementation of fn1 however, does this:
>
> void fn1(Public *p) {
>         Private *pri = (Private *)p;
>
>         // Work with the private struct.
>         // It is assumed that the pointer
>         // handed down is actually a private
>         // pointer
>
> }
>
> Obviously this doesn't have any compiler support
> but works quite well in practice. You can add a
> "magic" number somewhere in the private struct
> in the debug version to catch mistakes when passing
> the structures.
>
> Obviously you aren't supposed to copy the public object since you do not
> know what is behind. A way to avoid that would be to add a VLA:
>
> typedef struct PublicStruct {
>         // public fields
>         // ...
>         // private fields follow:
>         char private[];
>
> } Public;
>
> YES I KNOW.
>
> C++/Java/C# do this MUCH better, but they have other drawbacks
> that make a pure C solution MUCH better. Thank you.

Personally I think implementing some public/private separation is
outside the scope of C. Grafting this OO paradigm into C is purely
arbitrary at best, confusing and complex at worst. C wants people to
get their hands dirty, and doesn't do a whole lot to protect them.

Again, you say a pure C solution is MUCH better, but I haven't seen a
really cool use-case that says "Yeah, I want to try it out!". If I
wanted to make something private in C, I'd just give the "private"
members a hideously long name so that most people will just be annoyed/
bored to type it out and use the "public" parts ;)

Best regards,
John D.

==============================================================================
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: Mon, Mar 22 2010 8:31 am
From: Richard Delorme

Le 19/03/2010 18:10, Dag-Erling Smørgrav a écrit :
> Richard Delorme<abulmo@nospam.fr> writes:
>> What is done from a source code file could be done from a library.
>> See my answer to Dag-Erling Smørgrav.
>
> No, no, no, no and no. It would be a paradigm shift for C compilers.
>
> Currently, a C compiler works more or less as follows:
>
> 1. The preprocessor expands macros, resolves conditionals and removes
> comments.
>
> 2. The parser parses the output from the preprocessor and produces some
> sort of intermediate representation.
>
> 3. The optimizer manipulates the intermediate representation to produce
> more effective and / or smaller code.
>
> 4. The code generator translates the intermediate representation to
> assembler code.
>
> 5. The assembler translates the assembler code to machine code and
> produces a binary object that contains code, initialized data, and
> information about symbols that are present in the object or that the
> object references.
>
> 6. The linker combines the binary object(s) with various libraries and
> produces an executable or a library.
>
> No stage in this process has any knowledge about any other stage beyond
> a simple understanding of what sort of output the previous stage
> produces and what sort of input the next one expects, and sometimes not
> even that (the optimizer, for instance, is invisible to the parser and
> the code generator). Many toolchains implement step 1, steps 2 - 4,
> step 5 and step 6 as four different, interchangeable programs which can
> run independently of each other. Some also separate step 2 from steps 3
> and 4.
>
> What you propose turns everything upside-down. While the parser can
> easily include the necessary information in its output, it has no way of
> retrieving that information, unless you teach it everything that the
> linker knows, and then some... it gets even worse for cross-compilers,
> because the object format for the target might be completely different
> from that used on the host. The target might not even *have* an object
> format - on many embedded platforms, the linker outputs a memory image
> which is written directly to the target's SRAM.
>
> And what about preprocessor macros defined in library headers? They are
> needed at the preprocessing stage, but the preprocessor doesn't even
> know that what it's looking at is C (or C++ or ObjC or whatever, since
> most implementations use a single preprocessor for all languages they
> support), so how will it know where to look for them?

Everything is already upside down: Modern C compilers uses precompiled
header and does inter-procedural optimization during the linkage. My
proposal is simply to merge the precompiled header into the library, and
to automatically generate this precompiled header from the function
definitions, object definitions, etc.

--
Richard
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

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

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