twitter: comp.lang.c - 25 new messages in 8 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 5 ==
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

== 2 of 5 ==
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);

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

== 4 of 5 ==
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

== 5 of 5 ==
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: 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: 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 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

== 2 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?

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

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

== 5 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?

== 6 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.

== 7 of 7 ==
Date: Wed, Feb 24 2010 6:15 am
From: santosh

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

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

Isn't it just a special case of block scope, as is function scope
itself?

I agree that it's a nice convenience, but it can be easily done
without. If functions aren't overly long, it's pretty simple to
declare and use a single, or few, counters throughout the function.

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

== 3 of 4 ==
Date: Wed, Feb 24 2010 6:16 am
From: Kelsey Bjarnason

[snips]

On Wed, 24 Feb 2010 01:46:27 -0800, Nick Keighley wrote:

> count = count + 1;
>
> is not obscure code.

When the construct used in virtually every piece of C code one runs
across reads "count++", where "count++" is such a common idiom that
avoiding its use suggests there is some reason (either neophyte status,
or something less obvious) for doing so, then yes, lacking comments
explaining precisely _why_ such a screwball construct is being used, the
result _is_ obscure code.

Without additional explanation (eg "Imported from MatLab, which uses this
sort of construct") there is no readily apparent reason for using such a
construct. If we assume the coder is not a neophyte, it then follows he
is using this screwball notation for a specific purpose, which implies
there is some behaviour involved which shows up in "count = count + 1"
but _does not_ show up in "count++".

Which means now we have do scratch our heads, go running for the standard
(and the compiler documentation), check "count" to see if there's some
special magic associated with it, and try to figure out _what_ the
different behaviour is that's being relied upon.

When the search fails (assuming it does, i.e. we find no special magic)
we're left not with confidence the construct works as we'd expect, but
rather the uneasy feeling it is relying on some bizarre behaviour, quite
possibly of an implementation-specific optimizer, or some equivalent,
which we'll never be able to fully understand, let alone rely upon. The
code, as a result, simply cannot be trusted.

There are languages in which "count = count + 1" are common idiom. To
people used to those languages, such a construct may be clear and
concise. C is not one of those languages.

Indeed, the very fact this has engendered a discussion as involved as
this should be sufficient to show that such constructs are _not_ trusted
by C coders, but _are_ treated as flags suggesting extreme review is
warranted.

== 4 of 4 ==
Date: Wed, Feb 24 2010 6:22 am
From: Malcolm McLean

On Feb 24, 3:23 pm, "Ed Vogel" <edward.vogel@hp_stopping_spam.com>
wrote:
>
> 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).
>
People aren't going to be using 64 bits for long before they start
asking for objects greater than 4GB.
Your compiler is an intermediate step along the way.

==============================================================================
TOPIC: C99 is widely used!
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
==============================================================================

== 1 of 5 ==
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 5 ==
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 5 ==
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

== 4 of 5 ==
Date: Wed, Feb 24 2010 6:17 am
From: Malcolm McLean

On Feb 24, 4:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> C99 is the de jure standard. When it
> becomes the de facto standard, nobody will be more pleased than me,
>
I won't be too happy.
The idea of a fast stack allocator is a good one. But it must be
allowed to fail if the stack is too small. So the sensible
implentation is
void *ptr = salloc(N);
(ptr is null on failure)
rather than
array[N];
(undefined behaviour if N is too large);

Also, some holes in C89 were never addressed.
There's still no way to build a variable argument list at runtime.
There's still no way of creating a user-defined FILE stream.
There's no way of defining the failure behaviour of malloc(), or of
overriding malloc's allocation strategy.

My other nit is that the number of types has grown too large. The
number of interconversions is O(N^2), so a growth from a tiny handful
to a dozen or so is really quite significant.

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

Malcolm McLean wrote:
> On Feb 24, 4:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> C99 is the de jure standard. When it
>> becomes the de facto standard, nobody will be more pleased than me,
>>
> I won't be too happy.
> The idea of a fast stack allocator is a good one. But it must be
> allowed to fail if the stack is too small. So the sensible
> implentation is
> void *ptr = salloc(N);
> (ptr is null on failure)
> rather than
> array[N];
> (undefined behaviour if N is too large);

Yes, but nobody is forcing anyone to /use/ VLAs, are they? What concerns
me is not poor practice, but inconsistency between the real world and
ISO. Poor practice will always be with us, but this continued
discrepancy between de facto and de jure is just darn silly and *could*
be addressed.

<snip>

> My other nit is that the number of types has grown too large. The
> number of interconversions is O(N^2), so a growth from a tiny handful
> to a dozen or so is really quite significant.

I've got all the types I need, thanks, but the existence of others does
not bother me in the slightest.

--
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 - 25 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts