twitter: comp.lang.c - 26 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: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Feb 24 2010 4:43 am
From: Ben Bacarisse

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 23 Feb, 20:16, Nick <3-nos...@temporary-address.org.uk> wrote:
<snip>
>> Putting the bug aside, I had experience of people writing C like that
>> around 1990. They'd been on some sort of course in some sort of
>> programming methodology (maybe SSADM, maybe not - it was a long time
>> ago). In this case, they ended up writing something like:
>>
>> a = fgets(buff, SIZE, stdin)
>> while(a) {
>> do_things_with_a;
>> a = fgets(buff, SIZE, stdin);
>>
>> }
>>
>> All perfectly logical, but utterly un-idiomatic and (particularly when
>> things were a bit more complicated) it led you to looking at the two
>> identical lines wondering if they were in any way different.
>
> it's idiomatic in a language that doesn't allow assignment in the
> test. Removing the duplicated line was one reason I liked C!

It may be "idiomatic" but it is not good style in any language. If
you can't put an assignment in the test (because the language does not
allow it) then I think the way to go is an input function:

while (can_get_input(&a))
do_things_with(a);

Is there any language where you are forced to duplicate the input
line?

--
Ben.

== 2 of 7 ==
Date: Wed, Feb 24 2010 4:51 am
From: Willem

Ben Bacarisse wrote:
) It may be "idiomatic" but it is not good style in any language. If
) you can't put an assignment in the test (because the language does not
) allow it) then I think the way to go is an input function:
)
) while (can_get_input(&a))
) do_things_with(a);
)
) Is there any language where you are forced to duplicate the input
) line?

SQL, I think. In cursor fetch loops.

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

== 3 of 7 ==
Date: Wed, Feb 24 2010 5:05 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <0.b03829bbcb6aa0133e99.20100224124328GMT.87zl2yls7j.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>
>> On 23 Feb, 20:16, Nick <3-nos...@temporary-address.org.uk> wrote:
> <snip>
>>> Putting the bug aside, I had experience of people writing C like that
>>> around 1990. They'd been on some sort of course in some sort of
>>> programming methodology (maybe SSADM, maybe not - it was a long time
>>> ago). In this case, they ended up writing something like:
>>>
>>> a = fgets(buff, SIZE, stdin)
>>> while(a) {
>>> do_things_with_a;
>>> a = fgets(buff, SIZE, stdin);
>>>
>>> }
>>>
>>> All perfectly logical, but utterly un-idiomatic and (particularly when
>>> things were a bit more complicated) it led you to looking at the two
>>> identical lines wondering if they were in any way different.
>>
>> it's idiomatic in a language that doesn't allow assignment in the
>> test. Removing the duplicated line was one reason I liked C!
>
> It may be "idiomatic" but it is not good style in any language. If
> you can't put an assignment in the test (because the language does not
> allow it) then I think the way to go is an input function:
>
> while (can_get_input(&a))
> do_things_with(a);

Or we could commit a little bit of style massacre:

for (;;) {
char buf[SIZE];

if (0 == fgets(buf, sizeof buf, stdin)) {
break;
}

/* ... */
}

Cheers,
lacos

== 4 of 7 ==
Date: Wed, Feb 24 2010 5:17 am
From: Willem

Ersek, Laszlo wrote:
) In article <0.b03829bbcb6aa0133e99.20100224124328GMT.87zl2yls7j.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
)> It may be "idiomatic" but it is not good style in any language. If
)> you can't put an assignment in the test (because the language does not
)> allow it) then I think the way to go is an input function:
)>
)> while (can_get_input(&a))
)> do_things_with(a);
)
) Or we could commit a little bit of style massacre:
)
) for (;;) {
) char buf[SIZE];
)
) if (0 == fgets(buf, sizeof buf, stdin)) {
) break;
) }
)
) /* ... */
) }

That's just plain silly; you moved the while() condition into an if()
condition with the exact same semantics.

I think you meant:

for (;;) {
a = fgets(...);
if (a == 0) {
break;
}
...
}

which could be even further massacred to:

do {
a = fgets(...);
if (a) {
...
}
} while(a);

== 5 of 7 ==
Date: Wed, Feb 24 2010 5:36 am
From: Richard Heathfield

Seebs wrote:
> On 2010-02-24, Richard Heathfield <rjh@see.sig.invalid> wrote:
>> spinoza1111 wrote:
>>> At the time the book was written, compiler writers often of their own
>>> volition added "features" such as the assignment of meaning to <>.
>
> Uh, no.
>
>> By the time the third edition of CTCR (the edition on which CTCN was
>> based) was written, the ANSI Standard was already six years old.
>
> Ahh, but the <> was in the 2nd edition -- where it was a plain error, as
> established by the fact that Schildt removed it in the 3rd.

Oh, he meant the "!=" <>, not the #include <>? Oh, that's just plain
daft. The guy's a kook. The 2nd edition post-dates the ANSI C Standard,
and claims to be an ANSI C tutorial, and the "!=" <> is in there.

>> No, in 1995 (when CTCR3 was written), the ANSI C Standard was very
>> widely supported.
>
> Exactly. The example's key error, which had nothing to do with the hilarious
> (but typo-quality) error found in the 2nd edition, but fixed in the 3rd, was
> a total failure to comprehend how sizeof() works.

I didn't realise he'd got around to fixing that one. I don't have a copy
of CTCR3, for obvious reasons.

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

== 6 of 7 ==
Date: Wed, Feb 24 2010 5:41 am
From: Richard Heathfield

Ian Collins wrote:
> Richard Heathfield wrote:
>> spinoza1111 wrote:
>>
>>> and follows the lead of most other
>>> compilers, which don't get "picky" by default.
>>
>> Would that they did. Then the quality of software might improve a bit.
>
> Why should they?

Because in picky mode they often point out real code problems that they
don't point out in non-picky mode. The earlier you discover the bug, the
cheaper it is to fix it.

> If you want to analyse code, use a tool like lint. Let
> the compiler focus on compiling legal code quickly and accurately.

If I were writing (or, still pretty unlikely but rather less unlikely,
specifying) a compiler, I'd want its default setting to be maximally
picky. Anyone who doesn't want that could switch OFF warnings, either
individually or by small inter-related groups.

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

== 7 of 7 ==
Date: Wed, Feb 24 2010 6:13 am
From: Moi

On Wed, 24 Feb 2010 13:17:33 +0000, Willem wrote:

> Ersek, Laszlo wrote:
> ) In article
> <0.b03829bbcb6aa0133e99.20100224124328GMT.87zl2yls7j.fsf@bsb.me.uk>, Ben
> Bacarisse <ben.usenet@bsb.me.uk> writes: )> It may be "idiomatic" but it
> is not good style in any language. If )> you can't put an assignment in
> the test (because the language does not )> allow it) then I think the
> way to go is an input function: )>
> )> while (can_get_input(&a))
> )> do_things_with(a);
> )
> ) Or we could commit a little bit of style massacre: )
> ) for (;;) {
> ) char buf[SIZE];
> )
> ) if (0 == fgets(buf, sizeof buf, stdin)) { ) break;
> ) }
> )
> ) /* ... */
> ) }
>
> That's just plain silly; you moved the while() condition into an if()
> condition with the exact same semantics.
>
> I think you meant:
>
> for (;;) {
> a = fgets(...);
> if (a == 0) {
> break;
> }
> ...
> }
>
>
>
> do {
> a = fgets(...);
> if (a) {
> ...
> }
> } while(a);
>

which could be even further massacred to:

do {
a = fgets(...);
if (a) {
...
}
else continue;
} while(a);

AvK

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

== 1 of 3 ==
Date: Wed, Feb 24 2010 4:46 am
From: spinoza1111

On Feb 23, 10:38 pm, blm...@myrealbox.com <blm...@myrealbox.com>
wrote:
> In article <d520a640-1606-407e-9b7f-b9c75f4d5...@s36g2000prf.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 15, 8:41 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > > "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
>
> > >news:rand-20100215000605@ram.dialup.fu-berlin.de...
>
> [ snip ]
>
> > And note that "using strstr" has its own dangers. IT FINDS OVERLAPPING
> > STRINGS. If you use it to construct a table of replace points you're
> > gonna have an interesting bug-o-rama:
>
> > replace("banana", "ana", "ono")
>
> > IF you restart one position after the find point, and not at its end.
>
> Why would you do that, though? only if you *wanted* to detect
> overlapping strings, and -- if you did detect them, what would
> you do with them? I can't think of any sensible definition of
> "replace" that does anything with overlapping strings [*], so
> when I wrote my first solution to this problem, I of course used
> strstr and of course started scanning for the next match after
> the end of the previous match.
>
> [*] Chris Thomasson's reply to your post points out the ambiguities.
>
> > Moral: don't let the library do your thinking for you.
>
> Mostly I'm replying to this rather old post, though, because it
> seems as good a place as any to attempt a more-or-less formal
> specification of the problem, which I'm not sure we have, and
> which might be interesting. (Apologies if I missed one somewhere.)
>
> Here's my proposed specification, in which "is not a substring of"
> and "concat" have what I hope are obvious meanings, and names
> beginning s_ denote strings:
>
> replace(s_input, s_old, s_new) yields
>
> if s_old is not a substring of s_input
>
> s_input
>
> else
>
> concat(s_input_prefix, s_new, replace(s_input_tail, s_old, s_new))
>
> where s_input_prefix and s_input_tail are such that
>
> s_input = concat(s_input_prefix, s_old, s_input_tail)
>
> and
>
> s_old is not a substring of s_input_prefix
>
> Somewhat more formal than the "scans left to right and ignores
> overlapping strings", though whether it's actually clearer might
> be a matter of opinion.
>
> And then perhaps we could replace the "does not use string.h"
> constraint with something more meaningful [*], though I'm not
> sure what.
>
> [*] My objection to this constraint is that any minimally competent
> programmer should be able to write functions that implement the
> same API, so just avoiding use of the library functions doesn't
> seem to me to make the problem more interesting.
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 2 of 3 ==
Date: Wed, Feb 24 2010 4:57 am
From: spinoza1111

Search me. But that's what the code I was discussing actually did.

> overlapping strings, and -- if you did detect them, what would
> you do with them? I can't think of any sensible definition of
> "replace" that does anything with overlapping strings [*], so

replace(banana, ana, ono) could equal

bonona going left to right without overlap
banono going right to left without overlap
bonono going both ways with overlap

The third case could arise in natural language processing.

Suppose that in some language, the ana sound is transformed into the
ono sound to transform present into past tense (weirder things
happen), and suppose speakers do this to ALL occurences of the three
tones a, voiced n, a. When the sounds are adjacent they are
nonetheless distinct in speech but not in writing.

Now, the response of most garden-variety "break room" programmers is
"that's bullshit, and can never happen". But we know that in
programming, many strange things can happen, and that as Hamlet
admonished Horatio, we must "as a stranger give it welcome". Many more
strange things can happen outside programming, and programmers, even
of the Hooters or break room ilk, better realize this when programming
is used to solve problems.

> when I wrote my first solution to this problem, I of course used
> strstr and of course started scanning for the next match after
> the end of the previous match.
>
> [*] Chris Thomasson's reply to your post points out the ambiguities.
>
> > Moral: don't let the library do your thinking for you.
>
> Mostly I'm replying to this rather old post, though, because it
> seems as good a place as any to attempt a more-or-less formal
> specification of the problem, which I'm not sure we have, and
> which might be interesting. (Apologies if I missed one somewhere.)
>
> Here's my proposed specification, in which "is not a substring of"
> and "concat" have what I hope are obvious meanings, and names
> beginning s_ denote strings:
>
> replace(s_input, s_old, s_new) yields
>
> if s_old is not a substring of s_input
>
> s_input
>
> else
>
> concat(s_input_prefix, s_new, replace(s_input_tail, s_old, s_new))
>
> where s_input_prefix and s_input_tail are such that
>
> s_input = concat(s_input_prefix, s_old, s_input_tail)
>
> and
>
> s_old is not a substring of s_input_prefix

This is fine as long as we understand your concat as NOT specifying
left to right or right to left direction. The bonono problem would
have to be handled by preprocessing (translating banana into banaana,
perhaps using a rule that "vowels" (in the language) can always be
duplicated because their sounds don't break.

>
> Somewhat more formal than the "scans left to right and ignores
> overlapping strings", though whether it's actually clearer might
> be a matter of opinion.
>
> And then perhaps we could replace the "does not use string.h"
> constraint with something more meaningful [*], though I'm not
> sure what.

How about "does not use string.H and gets rid of the Obscene
Excrescence: the use of Nul to terminate a string, thereby creating a
new C that is almost fit for use".

>
> [*] My objection to this constraint is that any minimally competent
> programmer should be able to write functions that implement the
> same API, so just avoiding use of the library functions doesn't
> seem to me to make the problem more interesting.

No. The API locks us into bad thoughts.

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

== 3 of 3 ==
Date: Wed, Feb 24 2010 5:01 am
From: spinoza1111

On Feb 24, 11:25 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-24, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > Race appears to have little or nothing to do with programming ability,
> > but to say that most Indian programmers are dreadful at programming is
> > perfectly accurate - India is not immune from Sturgeon's Law.
>
> People who have dealt with outsourcing are very likely to have encountered
> a disproportionately bad sample of programmers from some other country.
> I have not known anyone who has had particularly good experiences with
> "cheap offshore coders", and I have oodles of horror stories.

So do most incompetent programmers. The reason being that they are not
only bad at coding, they also do a bad job of problem specification,
and as technically educated people, they know nothing of the culture
of the offshore programmers, apart from racist
stereotyping...including the patronizing admiration for cuisine, which
relegates the people of the land, and cultures that are normally far
older than Europe, to a feminized, subordinate and servant role.

>
> On the other hand, I have a largeish number of Chinese coworkers. They're
> nearly all novice-level or newbie programmers, but they're good people to
> work with -- a huge step up from the outsourcing place we used to use.
>
> I think a big part of the problem is that people are carefully set up to
> fail -- I'm a pretty decent programmer by many standards, and I could not

Not by mine.

> produce adequate code from some of the specs I've seen. Giving these
> tasks to novice programmers who have to do a full day's work without any
> chance to ask for clarification or feedback... Well, I can imagine ways
> this could work poorly.
>
> -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!

==============================================================================
TOPIC: Scope of a variable declared in for loop
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Feb 24 2010 4:51 am
From: jacob navia

gwowen a écrit :
> TI's compiler for their Piccolo DSP does not support that extension.
>

The "Piccolo dsp" is not a stand alone processor and must be used with an
ARM7 processor, a product line introduced in 1992, 7 YEARS BEFORE the C
standard was out in 1999. We see here the bad faith of this people when
complaining about C99.

== 2 of 7 ==
Date: Wed, Feb 24 2010 5:17 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <hm2nok$ssa$1@news.eternal-september.org>,
Michael Tsang <miklcct@gmail.com> wrote:
...
>That is, C99 is the ONLY standard NOW. The previous version has been
>replaced by this version. If a C compiler does not fully implement this
>standard, then it is not a fully-compliant C compiler.

ITA (Yes, as others have pointed out, my original post was somewhat
satirical [of the CLC regs])

But the point is that that (what you write above) is *not* the official
dogma of CLC. The official dogma of CLC, as enunciated by leader
Heathfield, is that nothing exists beyond C89. This is further
enunciated by, among others, subordinate Gowen (see his "Green Hills
supports nothing beyond C89" threads).

HTH

== 3 of 7 ==
Date: Wed, Feb 24 2010 5:16 am
From: Rob Kendrick

On Wed, 24 Feb 2010 13:51:44 +0100
jacob navia <jacob@nospam.org> wrote:

> gwowen a écrit :
> > TI's compiler for their Piccolo DSP does not support that extension.
> >
>
> The "Piccolo dsp" is not a stand alone processor and must be used
> with an ARM7 processor, a product line introduced in 1992, 7 YEARS
> BEFORE the C standard was out in 1999. We see here the bad faith of
> this people when complaining about C99.

ARM7 was certainly 1992, but Piccolo? I don't think so. And what is
one meant to use to compile C for running on the DSP part? An ARM
compiler?

== 4 of 7 ==
Date: Wed, Feb 24 2010 5:45 am
From: Richard Heathfield

Michael Tsang wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kenny McCormack wrote:
>
>> In article <ko2e57-q2n.ln1@news.eternal-september.org>,
>> Richard <rgrdev_@gmail.com> wrote:
>>> Mark Bluemel <mark.bluemel@googlemail.com> writes:
>>>
>>>> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>>>>> Hi,
>>>>> A)Is it possible to declare a variable inside for loop like
>>>>> for(int i=100;i>=0;i--);
>>>> Not in C.
>>> Huh? What C do you use?
>>>
>>> Not only can you, its recommended.
>> In the religion of comp.lang.c, nothing exists past C89.
>>
>> Therefore, it (the declarations which are the subject of this thread)
>> does not exist.
>
> C99 is not C?! READ THE STANDARD!

Yeah, I know. C99 is the de jure standard, and C90 is de jure obsolete.
But just about every C compiler vendor supports C90, but only a small
handful support C99. So C90 is the de facto standard.

Code written to either standard is topical here, so it's a rather silly
dispute. The decision about whether to use C90-only features, or
C99-only features, or neither, is a trade-off decision best made by the
development team leader, not by capital letters on Usenet.

--
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 7 ==
Date: Wed, Feb 24 2010 5:51 am
From: Richard Heathfield

jacob navia wrote:
> Keith Thompson a écrit :
>> Michael Tsang <miklcct@gmail.com> writes:
>>> Kenny McCormack wrote:
>> [the usual]
>>> C99 is not C?! READ THE STANDARD!
>>> According to the standard:
>> [snip]
>>
>> Don't worry about what Kenny says. He's lying.
>>
> Don't worry about Thomson, he is just obsolete.
> He thinks anybody that doesn't agree with the C89 clique here
> is lying...

It would be lame to flame you for your spelling error, but it is common
courtesy to get people's names right even if the rest of your spelling
is shot all to pieces.

To call Keith Thompson "obsolete" is to introduce a belligerent tone
into what ought to be a technical issue.

I doubt whether *anyone* here disputes that C99 is the de jure Standard.
Anyone who pretends it's the de facto Standard needs to take a long hard
look out there in the Real World, where only a very small percentage of
C programmers actually use a 100% conforming C99 implementation.

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

== 6 of 7 ==
Date: Wed, Feb 24 2010 5:56 am
From: Nick Keighley

On 24 Feb, 12:16, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > On 23 Feb, 16:00, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> On Feb 23, 3:35 pm, vaysagekv <kvvays...@gmail.com> wrote:
> <snip>
> >> > B)if there is a for loop like below
>
> >> > for(int i=0;int c = getchar();i++);
> <snip>
> >> Also some
> >> people use C++ as what is to all intents and purposes a C compiler
> >> with a few differences,
>
> > I'm not sure what this is supposed to mean. C99 and C++ have identical
> > behaviour as regards defining variables in for loops.
>
> >>one being that C++ always allows variables to
> >> be declared anywhere.
>
> > well, no. C++ doesn't support option B) either.
>
> Sorry but it does. It's off topic so I won't give you all the
> quotations but C++ permits a declaration in the condition part of an
> 'if', 'while', 'for' or 'switch' (but not 'do' of course).

ah, thanks. How recent is that?

== 7 of 7 ==
Date: Wed, Feb 24 2010 6:01 am
From: Malcolm McLean

On Feb 24, 2:20 pm, Richard <rgrd...@gmail.com> wrote:
>
> The main point remains : its a nice construct and recommended. The more
> local a variable declaration the better for all concerned, especially
> when dealing with things like loop variables where the end of the loop
> means the end of our interest in it.
>
The problem is that you run into another issue. There's a limit to the
number of levels a human being can keep in mind at any one time.
I think this is an example of the "rule of three" (three levels of
parentheses, three indirections, three dimensions), though I might be
persuaded that in fact it is the rule of five (five layers in a tree
or graph). Certainly you can't have arbitrary levels of scope.
We've already got global globals and file scope globals. Function
scope locals make three. I don't think we want any more.

==============================================================================
TOPIC: Free shipping Hot sale Air Force one sneakers paypal payment (http://
www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c/t/577dd5c412931382?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 5:11 am
From: yoyotrade

Air Force one sneakers paypal payment
Cheap Wholesale Air Force One Man paypal payment
Cheap Wholesale Air Force One Women paypal payment
Cheap Wholesale Air Force One M&W paypal payment
Cheap Wholesale Air Force one 25 Man paypal payment
Cheap Wholesale Air Force One 25 Women paypal payment
Cheap Wholesale Air Force One Kid paypal payment
Cheap Wholesale Air Force one Mid Man paypal payment
Cheap Wholesale Air Force one Mid Women paypal payment
Cheap Wholesale Air Force one Hight Women paypal payment
website: http://www.vipchinatrade.com

==============================================================================
TOPIC: █๑♥๑█ 2010 Cheap Wholesale ED Hardy Sweater, Lacoste Sweater, GUCCI
Sweater ect at www.rijing-trade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c/t/cb07f902bda09027?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 5:21 am
From: "www.fjrjtrade.com"

█๑♥๑█ 2010 Cheap Wholesale ED Hardy Sweater, Lacoste Sweater, GUCCI
Sweater ect at www.rijing-trade.com <Paypal Payment>

Welcome to website

www.rijing-trade.com

High quality Cheap Wholesale Sweaters

High quality Cheap Wholesale ED Hardy Sweaters

High quality Cheap Wholesale Lacoste Sweaters

High quality Cheap Wholesale Lacoste Sweaters Man

High quality Cheap Wholesale Lacoste Sweaters Women

High quality Cheap Wholesale GUCCI Sweaters

High quality Cheap Wholesale GUCCI Sweaters Man

High quality Cheap Wholesale GUCCI Sweaters Women

High quality Cheap Wholesale Ralph Lauren Sweaters

http://www.rijing-trade.com

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

== 1 of 2 ==
Date: Wed, Feb 24 2010 5:23 am
From: "Ed Vogel"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnhbp74oqx.fsf@nuthaus.mib.org...
> raltbos@xs4all.nl (Richard Bos) writes:
> [...]
>> ...because this is nonsense. There have been _many_ situations in which
>> sizeof(void *) != sizeof (size_t) != sizeof (int).
>
> I don't think I've ever used a system where sizeof(void*) !=
> sizeof(size_t).
>
> That's not to say that such systems don't exist, of course, but on
> most modern systems with a linear monolithic address space, it makes
> sense for void* and size_t to be the same size.
>
I worked on a C compiler for OpenVMS. On that system size_t is
always 32-bits. By default., pointers were 32-bits, but one could
compile
(or use a #pragma) to make the size of pointers 64-bits. In that mode
sizeof(void *) != sizeof(size_t).

Ed Vogel

== 2 of 2 ==
Date: Wed, Feb 24 2010 6:06 am
From: Richard Heathfield

Nick Keighley wrote:
> On 23 Feb, 10:00, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Nick Keighley wrote:
>>> On 22 Feb, 22:29, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>>>> "Richard" <rgrd...@gmail.com> wrote in message
>>>> news:bnga57-5i8.ln1@news.eternal-september.org...
>
>>>>> That doesnt wash with me.
>>>>> Putting the decrement in the body makes it less clear.
>>>>> If a post decrement is too clever for the reader then so is using C.
>>>> Use a debugger.
>>> no, don't
>>> a debugger is not the right tool to learn what C constructs do
>> I'm *reasonably* sure he was joking - yanking Richard NoName
>> MyHammerIsADebuggerAndEveryProblemIsANail Riley's chain a little.
>
>
> I didn't think Bill was that witty.

Neither did I. Hence the **s around "reasonably".

--
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: C99 is widely used!
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 24 2010 5:25 am
From: gwowen

On Feb 24, 12:37 pm, jacob navia <ja...@nospam.org> wrote:
> One of the most often "arguments" against C99 in this group is that
> "There is no embedded system support", etc.
>
> A typical message is this one of "gwowen":
>
> gwowen a crit :
> > On Feb 24, 11:05 am, Richard <rgrd...@gmail.com> wrote:
> >
> > Green Hills compiler 424 for ARM9 does not support that extension.
> > TI's compiler for their Piccolo DSP does not support that extension.
>
> How can this guy tell us that "there is no C99 support" in Green Hills
> compilers?

I didn't, as anyone with even basic reading comprehension will
understand. I said "Green Hills Compiler 424" does not support that
construct. I was very, very specific, and as such I wrote somGreen
Hills Compiler v5 is a considerably more expensive, and a licence for
that is not available to me. I use Green Hills version 424. That's
what I was talking about it, and I couldn't have been more specific if
I'd tried. Would that you used the same accuracy in reading.

> How can this guy tell us that "there is no C99 support" in Green Hills
> compilers?

Please do not put quotes around phrases that are not quotes. It's
extremely dishonest. As is apparent from the text you quoted *I said
no such thing* and I'd appreciate it if you withdrew the insinuation
that I did. Otherwise you'll look like a stubborn fool, rather than
just a fool.

== 2 of 3 ==
Date: Wed, Feb 24 2010 5:35 am
From: gwowen

On Feb 24, 12:37 pm, jacob navia <ja...@nospam.org> wrote:
> > TI's compiler for their Piccolo DSP does not support that extension.
>
> That is a typical post. Well, if you care to investigate those claims
> a bit you find immediately that they are completely WRONG.

Oooh, I like a challenge.

Here's a bit of the TI web page, that I notice you did not comment on:
------------------------------------------------------------------------
http://tiexpressdsp.com/index.php/TI_Compilers_and_Industry_Standards

Question :Does the (current) C/C++ compiler comply to any norm (ISO,
IEEE)?
Answer: All TI compilers support:
* C Standard: ANSI X3.159-1989 (C89), which is the same as ISO/IEC
9899:1990.
* C++ Standard: ISO/IEC 14882:1998

We do not support: C95, C99, C++ 2003, C++ TR1.
Though we do support, as language extensions, some C99 features. Two
examples are the restrict keyword, and the header file stdint.h.
-------------------------------------------------------------------------

So of my two examples I was completely RIGHT on both. Neither of the
compilers I mentioned support the feature I mentioned -- a later
version of one does, but the latest version of the TI compiler still
does not.

Any comment Jake, you crazy bastard?

== 3 of 3 ==
Date: Wed, Feb 24 2010 6:04 am
From: Richard Heathfield

jacob navia wrote:
> One of the most often "arguments" against C99 in this group is that
> "There is no embedded system support", etc.

One of the biggest flaws in your "argument" is that there is some kind
of anti-C99 campaign. There isn't. C99 is the de jure standard. When it
becomes the de facto standard, nobody will be more pleased than me,
especially if it means the end of this stupid subtopic, but in reality
C99 is not yet widely installed. There are, now, 10+ years after C99's
publication, a small handful of conforming compilers, but even now they
don't include Visual Studio in their number, and the installed base of
conforming compilers is a tiny fraction of that for C90.

At least nearly-everybody, and possibly everybody, agrees with you that
C99 is the One and Only C Standard, and that C90 is Legally Dead.
Nevertheless, it is C90 that is doing most of the actual work.

<snip>

--
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: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 5:38 am
From: Richard Heathfield

Nick Keighley wrote:
> On 23 Feb, 14:35, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Nick Keighley wrote:
>
>>> MS are lot better
>>> than they used to be but still a bit "but why would you want to
>>> program anything else?".
>> Not at all like the gcc people, then? :-)
>
> We recommend, rather, that users take advantage of the extensions of
> GNU C and disregard the limitations of other compilers. Aside from
> certain supercomputers and obsolete small machines, there is less
> and less reason ever to use any other C compiler other than for
> bootstrapping GNU CC.
> (Using and Porting GNU CC)

Precisely the quote I had in mind. Perhaps I should have used a bigger
smiley.

--
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: Any exit status without explicitely using return /exit
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 5:56 am
From: Richard Heathfield

Debanjan wrote:
> This actually bugging me from quite sometime now.The question is like
> this : How to set the the exit status of a program to any value
> without explicitly using return/exit in gcc ?

Too easy - use Visual Studio, or Borland, or Watcom, or Digital Mars...

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

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

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

Wednesday, February 24, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts