What is on topic here

[spinoza1111]

Right.  In some ways it's like c.l.fortran in that occasionally people
really do have to work with something in that awful old fixed-form f77
source.

But they have a big tent philosophy, and it makes it a more interesting
place.  Fortran is freely mixed with Ruby, C, and Matlab.  Richard Maine
always talks about the (Fortran) standard.  As the central figure in
c.l.f., however, he is always willing to talk about all those areas
where the fortran rubber hits the road, *and* no one begrudges others
when they do the same.

I'm not suggesting a blanket detente.  For example, threads in C++  bore
me enough to say "down the hallway, please."

This morning's group of posters have collectively been exercising self-
control and not responding to me. I support this, and I won't enter
this (informal) subthread. I invite constructive and on-topic
criticism and comments on C and its relationship to other topics
including its deficiencies, and I support this unusual level of self-
control.

 

[spinoza1111]

Right.  In some ways it's like c.l.fortran in that occasionally people
really do have to work with something in that awful old fixed-form f77
source.

But they have a big tent philosophy, and it makes it a more interesting
place.  Fortran is freely mixed with Ruby, C, and Matlab.  Richard Maine
always talks about the (Fortran) standard.  As the central figure in
c.l.f., however, he is always willing to talk about all those areas
where the fortran rubber hits the road, *and* no one begrudges others
when they do the same.

I'm not suggesting a blanket detente.  For example, threads in C++  bore
me enough to say "down the hallway, please."

These posters in this discussion are off-topic with respect to Jacob's
thread topic, which is "what is on topic here", nonetheless are
exercising admirable self-control and discussing, if not the thread
topic, the newsgroup topic, and notice how this amnesties them from
any infraction.

In particular, Richard Heathfield is behaving himself in an
unprecedented way.

Keep up the good work, fellas.

 

[frank]

On 24 Jan, 04:52, frank <[email protected]> wrote:

Richard uses C89 as he believes it is more portable than the less
widely implemented C99. I tend agree.

He might have his compiler switches biased toward C90, but his source
listings never fail on me because of language differences between those
standards.

there's a sort of boot strap problem. People use C89 because it's more
portable. Hence implementors feel less pressure to implement C99.
Hence C89 is more portable...

It's 2010; if C99 hasn't taken the world by storm by now it never
will.

I think the fallacy here is thinking that if something doesn't catch on
right away, it doesn't catch on. Peoples' hopes for standards and
compilers are bigger than realities. You might think the situation
sucks for C in particular, but I don't think so.

I've no idea what this is about. Does Jack Klein have some influence
over MS?

He just posted the link and is well known.

 

[Phil Carmody]

Not because it isn't topical, that's for sure. But I didn't think I
could get away with claiming that K&R C is a definition of the
language that is recognised internationally in the same way that ISO C
is.

Absolutely. One is a paedagogical definitive text from a source that
garners respect almost universally, while the other comes from a body
who in places reaches decisions through monopoly-driven ballot-stuffing
sock-puppetry.

;-)

Phil

 

[Nick Keighley]

As a matter of fact... yes, that is one of the things they are working
on.

that's why I suggested it. i'd heard rumours. Hoiw does it match up
with what C++ is doing are have they now just diverged too far?

 

[Nick Keighley]

On 24 Jan, 04:52, frank <[email protected]> wrote:

Richard [Heathfield] uses C89 as he believes it is more portable than the less
widely implemented C99. I tend [to] agree.

He might have his compiler switches biased toward C90, but his source
listings never fail on me because of language differences between those
standards.

so he writes code that will compile on either? The point he doesn't
use C99 features.

I think the fallacy here is thinking that if something doesn't catch on
right away, it doesn't catch on.

the fallacy here, is suggesting that over a decade is "right away".
The standard is supposed to be reviewed with a shorter cycle time than
that.

 Peoples' hopes for standards and
compilers are bigger than realities.  You might think the situation
sucks for C in particular, but I don't think so.

I don't know what this means. I think the effective rejection of C99
is a bit sad but it's happened.


<snip incomprehensible stuff>

 

[Richard Tobin]

Comp.lang.c is for discussion of the C language, including common
implementations and related tools (especially those on unix, where it
originated).

[/QUOTE]

Could you be so kind to define this somewhat more precisely?

I thought it would be obvious that I wasn't proposing that as a real
charter for the newsgroup. Rather I was doing what so many others
have done in recent years, asserting my interests as if they were the
definition of the newsgroup.

I don't see any hope of getting consensus on what comp.lang.c should
be. I generally avoid the topicality discussions, but from time to
time I like to state my preferences to ensure that the argument
doesn't go by default.

-- Richard

 

[Ersek, Laszlo]

one doesn't use C90 features that break under C99

Could you please suggest a summary of those features? (Besides
"restrict".) I guess paragraph 5 of the ISO/IEC 9899:1999 (E) Foreword
could serve as a basis, but if there's anything pre-cooked, I'd like to
start with that.

Yes. I am guessing that the shift from C0x to C1x suggests that they've
dropped a decade either in the hope that C99 will catch on in the
interim, or in the recognition that it won't, so that a big
(decade-long!) re-think is required.

I don't avoid coding for C99 because I "reject" it -- I simply have no
choice than code for C90 if I want my code to compile *wherever* I go
(and I've never even coded for a non-hosted/embedded environment yet).
I've recently got some heat for not using strerror_r() or so --
strerror_r() was standardized in 2003 (2002?) in SUSv3, and I coded for
SUSv2 (first SUS with threads, released in 1998 (1997?)). My decision to
stick to the oldest SUS standard with threads proved justified elsewhere
[0]. What's more, if I wish for a fleeting chance to compile my stuff on
the OpenVMS machine mentioned before, I have to constrain myself to
SUSv1 (released in 1994/1995 I guess).

Isn't there an English term for when the first version is so great that
people mostly see no reason to upgrade afterwards?

Thanks,
lacos

[0] http://lacos.hu/lbzip2-scaling/scaling.html

 

[Nick Keighley]

beware X-posted

Yes. I am guessing that the shift from C0x to C1x suggests that they've
dropped a decade either in the hope that C99 will catch on in the
interim, or in the recognition that it won't, so that a big
(decade-long!) re-think is required.

The scheme people have had a similar blood bath. Scheme is supposed
(so the original schemers thought) to be a very minimalist Lisp
dialect. The C of lisp-like languages...

"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary."

All features had to be accepted by unaminous agreement of the
committee.

Some features never got agreement (a module concept like #include).
"Modern" features didn't get added.

For R6RS (the 6th revision) they dropped the unaminous agreement
clause. The standard exploded. Vast arrays of new libraries appeared.
Many disgruntled implementors swore a might oath; that R6RS would
never darken their doors. Others couldn't have been more pleased.

Now the proposal for R7RS is to split the language into small (for
teaching, embedding, experimenting etc) and large (for those who want
to write applications without having to reimplement the whole of
computer science).

Perhaps C1x should consider this approach.

In a sense, it's a curate's egg - good in parts. The problem is that
different implementors admire different parts.

I never found much that was compelling. bool, the new sprintf and
um...

 

[Nick Keighley]

Isn't there an English term for when the first version is so great that
people mostly see no reason to upgrade afterwards?

If it ain't broke don't fix it.

Better is the ememy of good enough.

Perfection is an insult to the gods (Spanish Proverb)

"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
--C.A.R. Hoare


A designer knows he has achieved perfection
not when there is nothing left to add,
but when there is nothing left to take away.
Antoine de Saint-Exupéry


Fortran is like a shark, very old and effective.
Tor Rustad


C++: "an octopus made by nailing extra legs onto a dog"
-- Steve Taylor, 1998

 

[Flash Gordon]

frank wrote:

Flash, are you involved in the gcc project?

No, all my software writing is commercial. Although I did submit a
bug-report with a patch to binutils on one occasion (it was a problem
building on either SCO or AIC, I can't remember which). They chose to
fix the issue I reported in a different way, not using my patch.

 

[Nick]

I never found much that was compelling [in C99]. bool, the new sprintf and
um...

I like the // comments, although recognise the newsgroup problem.

VLAs are certainly useful - particularly when you want a scratch
workspace. Not essential - most dialects have an alloca or similar, or
you can use malloc/free. But better than the first as it's
"standardised" and better than the second because you don't have to be
as careful(!) and it's freed if you longjmp out.

 

[lawrence.jones]

Aha, is there a way to look at those tokens such that it is readable to
ordinary mortals?

Not as far as the C Standard is concerned. Most compilers have an
option to display it as text (-E and -P are popular) but the text is
usually intended to be valid C program text so it doesn't have explicit
token delimiters and thus cannot be 100% accurate.

 

[Seebs]

VLAs are certainly useful - particularly when you want a scratch
workspace. Not essential - most dialects have an alloca or similar, or
you can use malloc/free. But better than the first as it's
"standardised" and better than the second because you don't have to be
as careful(!) and it's freed if you longjmp out.

The big win for me has been compound literals, actually. I love them.
Very handy, very idiomatic.

-s

 

[Keith Thompson]

I never found much that was compelling [in C99]. bool, the new sprintf and
um...

I like the // comments, although recognise the newsgroup problem.

VLAs are certainly useful - particularly when you want a scratch
workspace. Not essential - most dialects have an alloca or similar, or
you can use malloc/free. But better than the first as it's
"standardised" and better than the second because you don't have to be
as careful(!) and it's freed if you longjmp out.

The problem with VLAs, as opposed to malloc/free, is that you *can't*
be as careful. There's no mechanism for detecting with a VLA is
too big to be allocated; it's just undefined behavior. Of course
the same is true for fixed-size arrays, or for any other object
with automatic storage duration. If you're not careful, though,
a VLA can become arbitrarily large depending on run-time values.
And on many systems, there's less space available for automatic
storage than for allocated storage.

As long as you limit the maximum possible size of a VLA to something
reasonable, though, this shouldn't be too much of an issue.

(Note that alloca() typically has the same problem; the documentation
on at least one system says, "If the allocation causes stack overflow,
program behavior is undefined"). Calling alloca() within a function
argument list can also cause bizarre problems.)

 

[Richard Bos]

Erm, are you sure he's a German?

frank doesn't even know the difference between German and Dutch.
Usually, he doesn't even make sense in English.

Richard

 

[Anand Hariharan]

There are a handful of common examples of things which are currently
generally regarded as being off-topic.  I'll review those.
(...)
8.  make and makefile issues.
(...)

8.  make and makefile issues.

I am a little torn on this, because of course, this is my primary way of using
C, but it's also my primary way of using several other languages.  I would
tend to think that comp.unix.shell or one of the similar groups would be a
better fit.  There's enough differences between make implementations that
a platform-specific group is probably better anyway in most cases.
(...)
Other people have thoughts on this?

Jacob's wording relating to make was "makefile problems related to the
building of a c program". I fully support that.

Header file and source code organisation should be (is?) very much
topical, and 'make' pertaining to C is fundamentally tied to how
source files depend upon one another.

I for one do not know where to ask "How do I setup the makefile to
resolve a cyclic dependency between P.h and Q.h?" or "'make' does not
trigger a build of X.c when I changed file Y.h. How do I determine
what all source file X.c depends upon?", or "make triggers rebuilding
source that is up to date" and so on. Answers to such questions can
come only from experience and most definitely /not/ found in the
standard.

 

[Keith Thompson]

I for one do not know where to ask "How do I setup the makefile to
resolve a cyclic dependency between P.h and Q.h?" or "'make' does not
trigger a build of X.c when I changed file Y.h. How do I determine
what all source file X.c depends upon?", or "make triggers rebuilding
source that is up to date" and so on. Answers to such questions can
come only from experience and most definitely /not/ found in the
standard.

What about comp.unix.programmer? Granted, "make" is not entirely
Unix-specific, but if the answers differ from one OS to another
perhaps a different OS-specific newsgroup would be better.

Many of these questions could be equally applicable to languages
other than C. In my opinion, that should be an indication that
comp.lang.c is not the most effective place to ask them.

Note that this is a least as much about helping questioners find the
best possible answers as it is about maintaining a good signal/noise
ratio here in clc.

 

[Nick]

The big win for me has been compound literals, actually. I love them.
Very handy, very idiomatic.

Good point. I don't use them a lot, but where I do they are great.
Particularly for some of those strange unix functions like setitimer. I
used one to great effect there (I had one parameter that came to my
function, all the rest being pre-defined).

 

[Nick]

I never found much that was compelling [in C99]. bool, the new sprintf and
um...

I like the // comments, although recognise the newsgroup problem.

VLAs are certainly useful - particularly when you want a scratch
workspace. Not essential - most dialects have an alloca or similar, or
you can use malloc/free. But better than the first as it's
"standardised" and better than the second because you don't have to be
as careful(!) and it's freed if you longjmp out.

The problem with VLAs, as opposed to malloc/free, is that you *can't*
be as careful. There's no mechanism for detecting with a VLA is
too big to be allocated; it's just undefined behavior. Of course
the same is true for fixed-size arrays, or for any other object
with automatic storage duration. If you're not careful, though,
a VLA can become arbitrarily large depending on run-time values.
And on many systems, there's less space available for automatic
storage than for allocated storage.

Although, as we've discussed, without doing some system tweaking the
same applies to malloc/free on my machine (although with less painful
problems from a security perspective, of course).

As long as you limit the maximum possible size of a VLA to something
reasonable, though, this shouldn't be too much of an issue.

Yes, although I strongly suspect I'm not as good as I should be there: I
"know" the input I'm making a scratch copy of will be short, but there
may be buggy circumstances when it won't.