twitter: comp.lang.c - 26 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 9 ==
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

== 2 of 9 ==
Date: Wed, Feb 24 2010 6:34 am
From: spinoza1111

On Feb 24, 9:41 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Ian Collins wrote:
> > Richard Heathfield wrote:
> >>spinoza1111wrote:
>
> >>> 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.

Unless it's not a bug, in which case the picky mode is wasting time.
For example, if it flags unused variables in stubbed code, it's
wasting time.
>
> > 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.

Overcomplicating these levels creates different languages in the last
analysis. The source code is therefore incomplete, since it has to be
accompanied by word to you Mama about what compiler settings it needs.

>
> --
> 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 9 ==
Date: Wed, Feb 24 2010 6:37 am
From: spinoza1111

On Feb 24, 4:46 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 23 Feb, 16:52, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2010-02-23, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <210fec94-aa97-4b77-a239-668539100...@c37g2000prb.googlegroups.com>,
> > >spinoza1111 <spinoza1...@yahoo.com> wrote:
> > >> I'd been laboring under an incorrect presumption, which was that the
> > MS is not famous for great compiler work,
>
> I thought these days they were. Apparently they "eat their own dog
> food".

That is correct. The phrase means "use software we are developing to
develop your software so that we can find as many problems as
possible."

>Though some would argue failure to support C99 is a gaping
> hole.

Microsoft may be aware that C99 is a disaster, since it was staffed by
people without computer science preparation and driven by the greed of
non-Microsoft vendors.
>
> > or for reasonable default options.
>
> which compiler *does* come with reasonable default options!

== 4 of 9 ==
Date: Wed, Feb 24 2010 6:40 am
From: spinoza1111

On Feb 24, 2:25 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
>
> <snip>
>
> > As I have said, I don't know C as well as the regs.
>
> We know.
>
> > I'm just a better
> > programmer by several orders of magnitude.
>
> Ha!
>
> <snip>
>
> > W3 as opposed to W4 is reasonable
>
> But W4 is more reasonable, and far preferable.
>
> > 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.

Wouldn't a picky compiler complain about your use of pointer to void
in your linked list tool? Correct me if I am wrong, but if I'm right
then your trumpeted claim that you want picky by default is
rhodomontade.
>
> --
> 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 9 ==
Date: Wed, Feb 24 2010 6:45 am
From: spinoza1111

On Feb 24, 2:23 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Feb 24, 1:55 am, Seebs <usenet-nos...@seebs.net> wrote:
> <nonsense snipped>
> >> Message-ID: <slrnhftrf0.9ug.usenet-nos...@guild.seebs.net>
>
> >>> 1. Notice many errors described on Usenet.
> >>> 2. Find spectacular examples (e.g., "if (x<>1)") in a coworker's copy..
> >>> 3. Check current ed in bookstore, find many errors remaining.
> >>> 4. Write McGraw Hill to complain.
> >>> 5. Get answer back offering small honorarium for a tech review.
> >>> 6. Send them a note saying that it would cost more than that. (An error
> >>> on my part, because I didn't understand publishing at all.)
> >>> 7. Get a fax from them, containing a forwarded fax from Schildt, containing
> >>> two pages or so of standard quotes and poor arguments defending "void main".
> >>> 8. Decide to just go ahead and write stuff up.
>
> > In other words "everybody be cool this is a robbery".
>
> That doesn't follow at all.

Yes it does. Seebach was engaged in near-extortion.
>
> > At the time the book was written, compiler writers often of their own
> > volition added "features" such as the assignment of meaning to <>.
>
> 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.
>
> > But you didn't know that, did you.
>
> Well, you're wrong, but you didn't know that, did you?
>
> <nonsense snipped>
>
> > I do not know whether at the time Microsoft supported <>.
>
> I do. They did.
>
> > But I do
> > know from working with John Nash at the time that its C compiler at
> > the time handled constant expressions idiomatically, such that his
> > code worked with Borland C and not Microsoft C.
>
> It is far more likely that you just didn't understand how to write the
> code portably.

That wasn't my job, and Nash, although not as *au fait* on the detail
and errors of C as you clowns, was a superior programmer; in the 1950s
he foresaw the need for multiple threads and announced a solid, if
preliminary, solution.

My assignment was in fact to help him get his code working without
freaking him out by bullying him and asking stupid questions, which
the average programming "expert" prefers to do. Which I did.

It was an extraordinarily sensitive assignment because at the time,
many members of the Nobel selection committee were very concerned with
Nash's stability: cf Sylvia Nasar's book. I was selected for this
assignment because unlike some other "experts" on the staff I had
better social skills in addition to knowing C.
>
> > At the time of which
> > we write, the compiler was effectively the standard.
>
> No, in 1995 (when CTCR3 was written), the ANSI C Standard was very
> widely supported.
>
> <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

== 6 of 9 ==
Date: Wed, Feb 24 2010 6:49 am
From: spinoza1111

On Feb 24, 11:07 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Peter Nilsson wrote:
> > Richard Heathfield <r...@see.sig.invalid> wrote:
> >> That's an easy one. It's because he's an idiot.
>
> > Is that considered to constitute a promising technical
> > argument (sic)?
>
> Not in the slightest. :-)

Fuck you, asshole. These newsgroups are not set up so that you and
Seebach can harass and label their contributors. If you can't behave,
leave.

And fuck you very much indeed, for I regard profanity as a far lesser
evil than the deliberate destruction of reputations in which you
engage, while claiming to defend Holy Fucking C, a piece of shit on
its last legs.
>
> --
> 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 9 ==
Date: Wed, Feb 24 2010 7:09 am
From: Rob Kendrick

On Wed, 24 Feb 2010 06:49:08 -0800 (PST)
spinoza1111 <spinoza1111@yahoo.com> wrote:

> On Feb 24, 11:07 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > Peter Nilsson wrote:
> > > Richard Heathfield <r...@see.sig.invalid> wrote:
> > >> That's an easy one. It's because he's an idiot.
> >
> > > Is that considered to constitute a promising technical
> > > argument (sic)?
> >
> > Not in the slightest. :-)
>
> Fuck you, asshole. These newsgroups are not set up so that you and
> Seebach can harass and label their contributors. If you can't behave,
> leave.

But it's clearly OK for you to label contributors.

> And fuck you very much indeed, for I regard profanity as a far lesser
> evil than the deliberate destruction of reputations in which you
> engage, while claiming to defend Holy Fucking C, a piece of shit on
> its last legs.

I think that book reviews are a good way of destroying people's
reputations. Like, say, the reviews for your and Herb's books on
Amazon.

== 8 of 9 ==
Date: Wed, Feb 24 2010 7:33 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnhoa9nd.20oq.willem@snail.stack.nl>, Willem <willem@snail.stack.nl> writes:
> 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;
> }
> ...
> }

Yes, exactly. I was too lazy to say explicitly:

"and any code (eg. the full body of can_get_input(&a)) can be inserted
between the loop body's opening brace and the if statement". The point
was to open up some space between the loop's beginning and the
controlling expression.

Of course my laziness didn't pay off, now that we're having this
sub-conversation.

> which could be even further massacred to:
>
> do {
> a = fgets(...);
> if (a) {
> ...
> }
> } while(a);

This checks "a" twice per iteration.

lacos

== 9 of 9 ==
Date: Wed, Feb 24 2010 7:41 am
From: BruceS

On Feb 24, 8:09 am, Rob Kendrick <n...@rjek.com> wrote:
> On Wed, 24 Feb 2010 06:49:08 -0800 (PST)
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 24, 11:07 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > Peter Nilsson wrote:
> > > > Richard Heathfield <r...@see.sig.invalid> wrote:
> > > >> That's an easy one. It's because he's an idiot.
>
> > > > Is that considered to constitute a promising technical
> > > > argument (sic)?
>
> > > Not in the slightest. :-)
>
> > Fuck you, asshole. These newsgroups are not set up so that you and
> > Seebach can harass and label their contributors. If you can't behave,
> > leave.
>
> But it's clearly OK for you to label contributors.
>
> > And fuck you very much indeed, for I regard profanity as a far lesser
> > evil than the deliberate destruction of reputations in which you
> > engage, while claiming to defend Holy Fucking C, a piece of shit on
> > its last legs.
>
> I think that book reviews are a good way of destroying people's
> reputations. Like, say, the reviews for your and Herb's books on
> Amazon.
>
> B.

Wow! I didn't realize that spinoza1111 had written a book. I guess a
more diligent reading of clc would have revealed that, but I have to
admit to not having nearly enough time for that. Given the quality of
his posts here, both in terms of technical competence and in writing
style (not to mention his quick resort to vulgarity, vitriol, and
petty flames), I'm truly amazed that he's been published. My hat is
off to you, spinoza1111. You've proven by example that *anyone* can
write a book and get it published. You can't imagine how inspiring
that is.

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

== 1 of 1 ==
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: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 2 ==
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.

== 2 of 2 ==
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 8 ==
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.

== 2 of 8 ==
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

== 3 of 8 ==
Date: Wed, Feb 24 2010 6:47 am
From: "bartc"

Richard Heathfield wrote:
> 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,

And of course the best way for that to happen is to deliberately avoid using
C99 features, and recommend others to do the same, which is hardly incentive
for compiler vendors to give C99 compatibility any priority, as there is no
competitive reason to do so.

If no-one should use C99 until every compiler for every platform in the
world can support it 100% (not 99.9%, but 100%) then I just can't see how it
can take off.

--
Bartc

== 4 of 8 ==
Date: Wed, Feb 24 2010 6:55 am
From: Walter Banks

Richard Heathfield wrote:

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

It may be a C90 based compilers with and without C99 extensions.
Most of the C90 based compilers today have a significant amount of C99
as part of the feature set and standard libraries.

In the embedded system world C99 brought a lot of order into "one of"
compiler specific feature sets that existed. A bigger debate is should C
have a feature set core with application area extensions?

Regards,

Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

== 5 of 8 ==
Date: Wed, Feb 24 2010 7:14 am
From: jacob navia

gwowen a écrit :
> 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.
> -------------------------------------------------------------------------
>

That page conerns the TI DSP stuff, that I did not question. You are
just answering to something I did NOT say :-)

With a reason. I spoke about the Green Hills software compilers. You
answer with TI compilers.

> So of my two examples I was completely RIGHT on both.

No. Green Hills upgraded to C99 3 years ago. That you are broke and
can't afford the new version has nothing to do with C99 support.

You can use gcc-1.0, but then, you can't argue that gcc doesn't support
C++ or C99. What counts is the version ABAILABLE. Besides, that version
is already 3 years old. Enough time to upgrade.

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

Ans so what? That is an old small embedded processor that surely
doesn't support the full standard of C89 because the run time must
fit in a very small RAM place. Functions like double arithmetic or long
double are probably absent.

> Any comment Jake, you crazy bastard?

I did NOT insult you. You are the one insulting here because
you have NO ARGUMENTS at all.

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

Walter Banks <walter@bytecraft.com> writes:

>
>
> Richard Heathfield wrote:
>
>> 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.
>
> It may be a C90 based compilers with and without C99 extensions.
> Most of the C90 based compilers today have a significant amount of
> C99 as part of the feature set and standard libraries.
>
> In the embedded system world C99 brought a lot of order into "one
> of" compiler specific feature sets that existed. A bigger debate is
> should C have a feature set core with application area extensions?

It seems to be the way to go for future C standards, if they don't
want to be painted with the C99 brush. Some common subset of C90 and
C99 could serve as the "core" language, and other features specified
as extensions.

This will atleast avoid the black-and-white, binary, impression that
many people seem to have, when considering C99.

== 7 of 8 ==
Date: Wed, Feb 24 2010 7:21 am
From: Walter Banks

santosh wrote:

> Walter Banks <walter@bytecraft.com> writes:
> > In the embedded system world C99 brought a lot of order into "one
> > of" compiler specific feature sets that existed. A bigger debate is
> > should C have a feature set core with application area extensions?
>
> It seems to be the way to go for future C standards, if they don't
> want to be painted with the C99 brush. Some common subset of C90 and
> C99 could serve as the "core" language, and other features specified
> as extensions.
>
> This will atleast avoid the black-and-white, binary, impression that
> many people seem to have, when considering C99.

What features in the core C standards?

What C99 features should be left out?

Regards,

Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

== 8 of 8 ==
Date: Wed, Feb 24 2010 7:31 am
From: gwowen

On Feb 24, 3:14 pm, jacob navia <ja...@nospam.org> wrote:
> gwowen a écrit :
>
>
>
> > 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.
> > -------------------------------------------------------------------------
>
> That page conerns the TI DSP stuff, that I did not question. You are
> just answering to something I did NOT say :-)
>
> With a reason. I spoke about the Green Hills software compilers. You
> answer with TI compilers.
>
> > So of my two examples I was completely RIGHT on both.
>
> No. Green Hills upgraded to C99 3 years ago. That you are broke and
> can't afford the new version has nothing to do with C99 support.
>
> You can use gcc-1.0, but then, you can't argue that gcc doesn't support
> C++ or C99. What counts is the version ABAILABLE. Besides, that version
> is already 3 years old. Enough time to upgrade.
>
> > 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.
>
> Ans so what? That is an old

No it isn't. The Piccolo is barely out of the fab plants. It's low
cost, but its new.

> small embedded processor that surely
> doesn't support the full standard of C89 because the run time must
> fit in a very small RAM place.

Wrong. You can get them with a lot of RAM, and a lot of flash.

> Functions like double arithmetic or long
> double are probably absent.

No. You can look this stuff you know. True, its not as easy as
making stuff up, but you'll find there's a closer correlation to
reality. Those features are slow, and emulated in software by the
runtime library, but they're there.

Allow me to requote TI's specs, since you seemed to overlook them:

****** All TI compilers support: C Standard: ANSI X3.159-1989 (C89)
******

> I did NOT insult you. You are the one insulting here because
> you have NO ARGUMENTS at all.

I made a true claim about Green Hills 4.2.4. This is not true of
Green Hills v5, but it is true of Green Hills 4.2.4 which I, (and I am
sure many other people) still use.

Care to have a wager which is more widely used today: GSH 4.2.4 or lcc-
win, every version other than that supported with MathWorks?

I made a true claim about TI's embedded compiler, which seem to have
chosen to ignore, because it clashes with you prejudices.

You made some untrue claims about my true claims, and then invented
some further claims (which I never made). I would like you to retract
those claims, please.

Here are my claims again:
i) TI's widely used compiler does not support many features of C99.
ii) Green Hills 4.2.4, another compiler used by far more people than
will ever use lcc-win in its entire existence, does not support many
features of C99.

If you can't refute either of those claims -- which is all I've ever
said -- please don't bother replying, you crazy bastard.

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 6:29 am
From: Nick Keighley

On 24 Feb, 13:38, Richard Heathfield <r...@see.sig.invalid> wrote:
> 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.

I was perfectly aware you being ironic. I just hadn't drunk my
telepathy tea so I didn't know exactly which quote you had in mind

==============================================================================
TOPIC: Any exit status without explicitely using return /exit
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 6:39 am
From: Nick Keighley

On 24 Feb, 12:38, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <ln3a0r2eqd....@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
> >jacob navia <ja...@spamsink.net> writes:

> >> Standard C guarantees a return of zero for a main() function that
> >> doesn't explicitly assign a return value.
>
> >By "Standard C", of course, jacob means C99. In C90, which jacob
> >insists on ignoring, the exit status of such a program is undefined.
> >(Yes, C99 superseded C90. Yes, C99 is the one and only official
> >C standard. We know, jacob, we know.)
>
> This last paragraph is very illustrative of the CLC attitude.

no. there is no clc attitude

> Which is "When you say something lacking in precision in any way,

I don't think jacob was lacking in precision. I think he said exactly
what he meant to say. It's hard to imagine he missed mentioning C89 by
mistake as he is currently posting to two different threads arguing
there is some sort of conspiracy to premote C89 and denigrate C99.

> we are
> only too eager to point it out, repeatedly, and to pile on to our hearts
> content. But when we say something a little sloppy, it's OK because we
> run this place. And, further, it is you who are, again, at fault, for
> pointing out our lack of precision."

normally I ignore kenny but he needs refuting from time to time just
in case anyone was taking him seriously

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

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 24 Feb, 12:38, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>> In article <ln3a0r2eqd....@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> wrote:
>> >jacob navia <ja...@spamsink.net> writes:
>
>> >> Standard C guarantees a return of zero for a main() function that
>> >> doesn't explicitly assign a return value.
>>
>> >By "Standard C", of course, jacob means C99. In C90, which jacob
>> >insists on ignoring, the exit status of such a program is undefined.
>> >(Yes, C99 superseded C90. Yes, C99 is the one and only official
>> >C standard. We know, jacob, we know.)
>>
>> This last paragraph is very illustrative of the CLC attitude.
>
> no. there is no clc attitude

You're either blind or in denial. There is a very obvious c.l.c
attitude. I don't believe for one minute that you are unaware of it.

>
>> Which is "When you say something lacking in precision in any way,
>
> I don't think jacob was lacking in precision. I think he said exactly
> what he meant to say. It's hard to imagine he missed mentioning C89 by
> mistake as he is currently posting to two different threads arguing
> there is some sort of conspiracy to premote C89 and denigrate C99.

More reason.

>
>> we are
>> only too eager to point it out, repeatedly, and to pile on to our hearts
>> content. But when we say something a little sloppy, it's OK because we
>> run this place. And, further, it is you who are, again, at fault, for
>> pointing out our lack of precision."
>
> normally I ignore kenny but he needs refuting from time to time just
> in case anyone was taking him seriously

Which of his views do you find need refuting? He's pretty much on the ball
IMO.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

==============================================================================
TOPIC: help: gcc compilation difference
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 6:57 am
From: new

Richard,Keith and all thanks a ton for your replies.
I have one more question.
In the code if I add the following line:
------------------------------------
z = s[p[0]]++; // say z is declared as int
------------------------------------
what would be the value of z and how it is evaluated?

Thanks a lot in advance.

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

new <luvraghu@gmail.com> writes:

> Richard,Keith and all thanks a ton for your replies.
> I have one more question.
> In the code if I add the following line:
> ------------------------------------
> z = s[p[0]]++; // say z is declared as int
> ------------------------------------
> what would be the value of z and how it is evaluated?
>
> Thanks a lot in advance.

Since you don't initialise the s array, it's members could contain
any garbage value, normally the value that was last written to the
memory location. So by extension, we cannot say z contains any useful
value after your assignment. In standard C parlance, it's value is
indeterminate, and reading an indeterminate object, as in the RHS of
your assignment statement, invokes undefined behaviour, again in the
standard's terminology. IOW, it assigns to z, a garbage value at the
very least, and could cause much worse behaviour at worst.

I think others have already explained how the array indexing is
evaluated and it's problems.

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 7:33 am
From: Ertugrul Söylemez

ld <laurent.deniau@gmail.com> wrote:

> > > Nitpick: How is it possible to create an infinite data structure
> > > on a machine with finite resources? (Maybe "unbounded" or
> > > "arbitrarily long" would be a better term?)
> >
> > I think such languages work on a "lazy" principle- they only
> > evaluate the things that are actually needed so if you create a
> > couple of infinite structures you have no problem unless you try to
> > output an infinite result.
>
> You don't have problem either, it just takes an infinite time. This is
> equivalent to an infinite loop which outputs something in C.

Not exactly. Try to translate the following pair of functions to C:

isPrime :: Integral i => i -> Bool
isPrime n = all (\d -> rem n d /= 0) . takeWhile (\d -> d^2 <= n) $ primes

primes :: Integral i => [i]
primes = 2 : filter isPrime [3..]

'primes' is an infinite list of all prime numbers, calculated in a naive
trial division manner, but the trial division uses only prime numbers.
This is where lazy infinite data structures are more powerful than just
infinite loops with finite data structures.

> > So you might write a program that computes a list of all the primes,
> > but you only output the first 1000. The compiler is smart enough not
> > to evaluate all those primes you never look at.
>
> I don't know if the compiler is smart, but it follows the language
> principle which requires an "outermost reduction". C uses an
> "innermost reduction" which evaluate the arguments first then call the
> function. Haskell does the opposite which by definition evaluates only
> the arguments used (when the value is needed).

Note that there are two related, but separate concepts at work here:
Firstly non-strict semantics. This is what you mentioned: Function
arguments are not evaluated before the function is called. But when are
they evaluated then? This is where the lazy evaluation stategy comes
in, the second concept. A computation is carried out as it is demanded.

Greets
Ertugrul

--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/

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

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 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts