set and reset the least significant bit of a address

[CBFalconer]

Where does it say this is a group for *portable* C programming only.

One does not get that impression from the group name, nor have I
seen anything resembling a Charter that says so.... shouldn't this
be comp.lang.c.portable?

I mean no offense here, but all I've seen is a bunch of "get lost"
messages posted over and over by the same small group of people,
and most often in response to questions the group name would
suggest are completely on-topic. Unlike a lot of other newsgroups
it seems people here play along with this ultra-narrow focus, even
though there really doesn't seem to be a general purpose C
discussion group anywhere on Usenet.

Can someone enlighten me, please?

A fair enough question. The newsgroup existed long before
'charters' were dreamed up. The group needs some limitation as to
subject, and C is a slippery thing, unless we resort to the
published international standards (and even the predecessor of
those, K&R1). By doing this we all know what we are talking about
(at least in theory . The consensus of the users of this group
has been and will be to maintain that narrow focus.

There are usually adequate specialized newsgroups for particular
systems, where the inhabitants do know (and agree about) what the
frogbuster() function does, and more importantly, where answers
that misuse frogbuster will be caught and corrected.

In general, if the system/compiler/hardware matters, it is off
topic here.

 

[jacob navia]

Unlike a lot of other newsgroups it seems people here play along with this
ultra-narrow focus, even though there really doesn't seem to be a general
purpose C discussion group anywhere on Usenet.

There is the minority view. I have received a lot of flames because of
this, but I go on believing that this group should discuss C beyond the
"portable" stuff.

But let's not start again a flame war...

jakob

 

[not]

If you -can- "write down" to a portable version, then the program did
not -require- the extension, and so the extension need not have been
present in the first place. One might as well write in the portable form
except perhaps for some isolated sections in which going with the
more intrinsic form brings sufficient optimization as to be worth the
trouble.

Then where's the progress? If we continue to write for the lowest common
denominator the language remains stagnant in perpetuity.

For example: I've already mentioned I would like to see an implementation
of C with real string variables. If this were done and it proved truly
useful then it should (reasonably) proliferate to other implementations
eventually reaching the point of becoming standard.

This is progress, the language is dynamic, always changing and progressing.
Without this, we end up programming by decade old rules on machines far more
capable than the ones the rules were written for; in effect holding back
progress in the very industry we support. Hardware reaches new generations
in a matter of months, many programming languages are still essentially
where they were in the early 80s. Where software once drove hardware,
demanding progress, we are now approaching a point where the situation is
reversing... hardware is now driving software. It would be a mistake to not
keep up.

Moreover, having worked in Delphi and done a test run with c++ I'm pretty
sure OOP is not the way to do this. It's not better, it's just easier.
Underlying all those fancy visual design tools and object methods is still a
procedural core upon which the CPU itself relies. C still underlies C++,
Pascal still underlies Delphi. That procedural languages are not
progressing in the forefront of programming is, ummm, disappointing.

 

[not]

The consensus of the users of this group
has been and will be to maintain that narrow focus.

Fair enough comment... but upon what basis is it made?

If you are actively rejecting everything except "c89 says..." how do you
know what reader/participant concensus is?


I'm not trying to upset your group. In fact that's the last thing I'd want.
I do however bemoan the lack of any newsgroup where an active discussion
about progressive use of the C language is going on. It seems that
everytime someone asks about anything that's not in the "C bible" (which, in
this group, appears to be a decade old standard) they get flagged for it.
This strikes me as rather anachronistic as it seems to want to hold
conversation to a de facto glass ceiling that hasn't actually existed in
several years.

I don't bemoan the urge for some regulation. It's necessary to keep any
newsgroup from degenerating into simple chaos... but where does one go to
discuss progress in the language?

 

[not]

There is the minority view. I have received a lot of flames because of
this, but I go on believing that this group should discuss C beyond the
"portable" stuff.

But let's not start again a flame war...

Absolutely not. And not my intention.

I'm just trying to understand the strange land I appear to have stumbled
into.

Perhaps it would help to explain my grumble a little more clearly...

For a very long time I was employed in differing aspects of the computer
industry. I've done everything from high-end (at the time) home theater
configurations all the way to interface design and repair (back in the day
when we actually repaired motherboards!). During all this there has always
been a need to occasionally cook up a little code to make things get along.
This has left me in the state of "high level beginner" for software for
quite some time.

As I neared retirement, I wanted out of the heavy lifting and pulling cables
through musty ceiling tiles so I naturally gravitated towards software. I
first grabbed Delphi and started trying to learn it. I hit the wall with
that in about 6 months, I can't even begin to explain how totally
unimpressed I was. I dug out the underlying Pascal and started working in
it. 4 years and a couple of pretty big projects later, a primal flaw in the
implementation exposes itself and I'm in real trouble. I fix the problems
(of course) but now I am thoroughly disgusted with the language...

When I retired, just before Christmas 2004, I went language hunting, looking
to make programming into a hobby to fill my time (and maybe make a couple of
bucks here and there). What I found was unbelievable... No real progress
has been made since I learned Pascal in the early 80s. Yes there's OOP, a
magical way of turning a 200k utility into a 5meg monster. Yes, there's
RAD and Visual tools, but they're mostly about laziness. But in all the art
and science of programming is still today what it was when I wrote my first
version of "Hello World" more than 20 years ago.

I looked at C, C++, D, Delphi (again) and a dozen offshoots of each. Mostly
I was flat out disappointed at the near-total lack of documentation for any
of them. I can get compilers to do almost anything... but I have to figure
out how they work all by myself. One, in particular, was a perfect example:
Smallish download, unzip to install... one file: "mystery.exe"... no
documentation, not even a language definition, just "here's johnny" and I'm
supposed to know what to do with it.

Ok, says I, Usenet has every topic imaginable... lets try that. So I
settles on Pelles C, which is far better documented than most, but I still
need some help getting started... Pelle runs a nice set of forums and he is,
himself, very helpful, but I'm still looking to see discussion and example
that I can't possibly ask him to provide.

Can you imagine my disappointment when I am rebuffed for discussing some of
the better features of Pelle's work? Told, in no uncertain terms, that
"these are not standard features of C and we aren't going to talk to you
about them."... by the very people who seem most in the know...

I recognize your name Jacob, you've written compilers... you're the kind of
person I'd love to discuss C tips and techniques with... but apparently not
here. And since there doesn't seem to be anywhere else, well... it's back
to trying to find a new language.

<sigh>

 

[CBFalconer]

.... snip ...

Moreover, having worked in Delphi and done a test run with c++ I'm
pretty sure OOP is not the way to do this. It's not better, it's
just easier. Underlying all those fancy visual design tools and
object methods is still a procedural core upon which the CPU itself
relies. C still underlies C++, Pascal still underlies Delphi.
That procedural languages are not progressing in the forefront of
programming is, ummm, disappointing.

Let's just take your own example - Pascal and Delphi. While the
Delphi system is much nicer than its competition for many purposes,
it is not portable. This is largely because the underlying
language is not portable. Delphi does not adhere, nor even
implement, the well published Pascal standard (which antedates
Delphi and I believe even Turbo Pascal). The result is that the
system is moribund. People want their systems to port easily to
Linux, Sun, whatever. Code developed for Delphi is useless for an
embedded system running on an ARM. It is restricted to machines
using an x86 processor and running an inferior and insecure
operating system.

This is not the fault of the language Pascal, as standardized in
ISO7185 and ISO10206 (for extended Pascal). The important
difference from C is that the C implementations have adhered to the
C standard, albeit with extensions.

There is no restriction on extensions to either Pascal or C. They
are just not standard. To allow them to be used the complete
_standard_ code to implement them has to be published. If they are
system specific then their characteristics have to be published,
and they will not advance anything on other systems without
re-implementation.

If you want to discuss modifications to the standard, comp.std.c
exists. If you want to discuss things to do with Unix or Posix or
Linux or Windoze, newsgroups with those systems in their names
exist.

If you want an improved string facility, there is no impediment to
designing and publishing one. Just make sure it is implemented in
portable standard C. In at least one such attempt known to me the
portability is highly suspect, because the author is known to make
unwarrented assumptions. However give up the idea of replacing the
existing abilities, because that would break existing code and
render such a standard unacceptable.

An example of extensions is strlcpy and strlcat. These are not my
idea, but I have published an implementation of them, together with
links back to the originators and their rationale. I would like to
see these in the next revision of the standard. Until that happens
they won't be routinely used. See my site, download section, URL
in Organization field of header.

 

[CBFalconer]

.... snip ...

I don't bemoan the urge for some regulation. It's necessary to
keep any newsgroup from degenerating into simple chaos... but
where does one go to discuss progress in the language?

Try comp.std.c.

 

[CBFalconer]

.... snip ...

When I retired, just before Christmas 2004, I went language
hunting, looking to make programming into a hobby to fill my time
(and maybe make a couple of bucks here and there). What I found
was unbelievable... No real progress has been made since I
learned Pascal in the early 80s. Yes there's OOP, a magical way
of turning a 200k utility into a 5meg monster. Yes, there's RAD
and Visual tools, but they're mostly about laziness. But in all
the art and science of programming is still today what it was when
I wrote my first version of "Hello World" more than 20 years ago.

What you learned in the '80s was probably not Pascal, because the
prevalent flavor was Turbo, which doesn't even implement Pascal and
has seriously damaged the language.

You should probably look into Ada. And you should definitely move
this subject, possibly to comp.programming. A query about
topicality is fine, but long winded grousing about the answer will
just get you PLONKED.

I looked at C, C++, D, Delphi (again) and a dozen offshoots of
each. Mostly I was flat out disappointed at the near-total lack of
documentation for any of them. I can get compilers to do almost
anything... but I have to figure out how they work all by myself.
One, in particular, was a perfect example: Smallish download, unzip
to install... one file: "mystery.exe"... no documentation, not even
a language definition, just "here's johnny" and I'm supposed to
know what to do with it.

They have no standard. Look into Ada, it has a well defined
standard. The presence of gcc has taken the profit out of compiler
development, which is both good and bad.

 

[Dan Pop]

Where does it say this is a group for *portable* C programming only.

In the periodically posted "Welcome to comp.lang.c!" article.
This article reflects the quasi-consensus of this newsgroup's regulars.

There are extremely few non-portable C programming issues that aren't
(much) better discussed elsewhere.

Dan

 

[jacob navia]

I find what you say very good. Your viewpoint is almost exactly mine.

jacob

 

[jacob navia]

Standard or not, Delphi was a highly successful programming
language.

If you use windows, Delphi was very portable

 

[Chris Croughton]

|On 16 Mar 2005 11:08:42 GMT, (e-mail address removed)-cnrc.gc.ca (Walter Roberson)
|wrote:

|>If one writes a program that requires the extensions, then the program
|>is only as portable as the compiler is.

|If one writes a program that requires the extensions --> without considering
|portability <-- then the program is only as portable as the compiler is.

|Just because an extension is present in the language, doesn't mean we can't
|"write down" to a platform/compiler that doesn't support the extension.

If you -can- "write down" to a portable version, then the program did
not -require- the extension, and so the extension need not have been
present in the first place.

.... for that program. The existence of the extension may well be
essential for some other program, or for implementing the C libraries
and headers, or for compiler optimisations (like the common use of
builtin intrinsics which the compiler can optimise into fast processor
dependent code).

One might as well write in the portable form except perhaps for some
isolated sections in which going with the more intrinsic form brings
sufficient optimization as to be worth the trouble.

Indeed, and most good programmers automatically encapsulate
system-dependent features into a small area which can easily be
reimplemented if necessary when porting to another system. I generally
program with -ansi -pedantic -W -Wall (or their equivalent) on for as
much of my code as I can, leaving off the pedantic part for a few
modules which have to do system-dependent things (directory searches,
file locking, low level peripheral and display access, etc.).

Chris C

 

[Chris Croughton]

As I neared retirement, I wanted out of the heavy lifting and pulling cables
through musty ceiling tiles so I naturally gravitated towards software. I
first grabbed Delphi and started trying to learn it. I hit the wall with
that in about 6 months, I can't even begin to explain how totally
unimpressed I was. I dug out the underlying Pascal and started working in
it. 4 years and a couple of pretty big projects later, a primal flaw in the
implementation exposes itself and I'm in real trouble. I fix the problems
(of course) but now I am thoroughly disgusted with the language...

Well, Pascal is a very good example of "why not to write extensions".
Pascal as originally designed was a teaching language, and among other
things it specified that all input files were read before the program
was started and all output files were written after it ended. Not
exactly easy to write interactive programs! To start with all the code
was in one source module, as well. So what happened was that each of
the implementors added their own extensions to make it usable, all (of
course) incompatible. So we had Turbo Pascal, MS Pascal, Intel Pascal,
etc., all incompatible unless you wanted to write "Hello World". And
out of that came Delphi, which is only a de facto standard because
virtually all of the other variants died.

When I retired, just before Christmas 2004, I went language hunting, looking
to make programming into a hobby to fill my time (and maybe make a couple of
bucks here and there). What I found was unbelievable... No real progress
has been made since I learned Pascal in the early 80s. Yes there's OOP, a
magical way of turning a 200k utility into a 5meg monster. Yes, there's
RAD and Visual tools, but they're mostly about laziness. But in all the art
and science of programming is still today what it was when I wrote my first
version of "Hello World" more than 20 years ago.

Oh, only 20 years ago. OK, perhaps it hasn't changed so much since
then. Except for what has disappeared (apart from a few diehards):
Algol, Modula (remember when that was going to be the "new Pascal?"),
Coral, COBOL; Fortran is hanging on but is virtually unrecognisable to
someone who learned FORTRAN IV; Ada is used only in obscure bits of the
defence industry. Oh, we've added Java, C++ (although that started
earlier) and C#, which are all very much dialects (from a linguistic
point of view) of C and C With Objects.

But what does that signify? Possibly that language design has gone as
far as it needs to? The emphasis now is on design, data manipulation,
interfaces and communication, rather than on the "nuts and bolts" of
whatever language you use. Look at UML, for instance, that is language
independent, the actual code could be in assembler for all anyone cares
because it's the design which matters.

I looked at C, C++, D, Delphi (again) and a dozen offshoots of each. Mostly
I was flat out disappointed at the near-total lack of documentation for any
of them.

As far as C and C++ are concerned, that's rubbish. There's masses of
documentation. Granted, it doesn't come with the compilers, but that's
because the languages are standardised, you can buy any book on C and it
will describe the same language (OK, avoid Schildt's one and anything
"for dummies"). The same for C++. The standards for both C and C++
cost $18 for the PDF versions.

I can get compilers to do almost anything... but I have to figure
out how they work all by myself. One, in particular, was a perfect example:
Smallish download, unzip to install... one file: "mystery.exe"... no
documentation, not even a language definition, just "here's johnny" and I'm
supposed to know what to do with it.

What language is "mystery.exe" supposed to compile? If you will
download some random stuff off the net, I'm not surprised you can't find
any documentation (I am surprised that it didn't do something nasty like
install a pack of viruses). Try any of the real compilers -- gcc, for
instance, or Borland's (even Microsoft's), they'll tell you how to run
the compiler. Borland and MS even come with help files in their
development environments where you han just hover over (or hit F1 on) a
keyword or function name and get help on it.

Ok, says I, Usenet has every topic imaginable... lets try that. So I
settles on Pelles C, which is far better documented than most, but I still
need some help getting started... Pelle runs a nice set of forums and he is,
himself, very helpful, but I'm still looking to see discussion and example
that I can't possibly ask him to provide.

I've never heard of Pelles C, but apparently it is some other language
"based on C" (like Mr. Navia's one). As people have said, almost all
implementations do contain extensions, but if you want to know about
those you need to look at a specific forum or documentation for that
compiler (if you do info gcc, for instance, one of the sections is about
extension to the language).

Can you imagine my disappointment when I am rebuffed for discussing some of
the better features of Pelle's work? Told, in no uncertain terms, that
"these are not standard features of C and we aren't going to talk to you
about them."... by the very people who seem most in the know...

Because we don't know anything about this Pelle guy or his extensions,
and they aren't relevant to standard C. If we said "oh, that's
wonderful, pity none of us can use it", would that help? We still
couldn't talk about it meaningfully without getting his compiler and
documentation and evaluating it, and few of us have time to do that.

If you want to discuss specific features of his compiler, you know where
his forums are apparently. If you think that they are a worthwhile
thing to add to the language, go to comp.lang.c and try to convince the
people there, that's where future language directions are discussed.

I recognize your name Jacob, you've written compilers... you're the kind of
person I'd love to discuss C tips and techniques with... but apparently not
here. And since there doesn't seem to be anywhere else, well... it's back
to trying to find a new language.

comp.lang.misc
comp.compilers
comp.compilers.lcc (I assume that includes Mr. Navia's one)
comp.std.c (future language directions)

Looking for Pelles C using Google, I see that it's another one based on
LCC as is Mr. Navia's compiler, so that should be on topic on
comp.compilers.lcc as well.

If you want to discuss standard C, however, as it is and not as some
language you might like to use which isn't C, you're welcome to do so
here...

Chris C

 

[Walter Roberson]

:This is progress, the language is dynamic, always changing and progressing.
:Without this, we end up programming by decade old rules on machines far more
:capable than the ones the rules were written for; in effect holding back
rogress in the very industry we support.

That is more or less BS. The last I read, researchers still aren't able
to hold more than 3 quantum transistors stable simultaneously -- so
unless you want to count DNA programming (which does actually work,
if you are willing to get into wetware), then you are still firmly in
the realm of Turing Completeness, which can be summarized as
"Anything that can be computed in one sufficiently powerful logic
system can be computed in any other sufficiently powerful logic system."
"Machines" are NOT "far more capable" than 20 years ago: they are only
far -faster- (and have some interesting extensions to their I/O interfaces.)

:Hardware reaches new generations
:in a matter of months,

*Snort*. Continents reach new positions "in a matter of years".

Read the durned press releases about inventions like new transistors
and computing on amorphous silicon: the usual timeline to take them
out of the lab into *any* product is a minimum of 5 years, and the
usual timeline given before they expected to find their way to
any kind of consumer product is a decade.

It's the old story about the singer that toils in obscurity for
25 years before becoming "an overnight success". What you see is the
Pop Culture of electronics, not the Practice! Practice! Practice!
that proceeds it.


:many programming languages are still essentially
:where they were in the early 80s. Where software once drove hardware,
:demanding progress, we are now approaching a point where the situation is
:reversing... hardware is now driving software. It would be a mistake to not
:keep up.

This is known as "The Software Deficeit". Hardware -is- getting faster
(but with much much higher time latencies than you are observing),
and it is true that software is not keeping pace. This is a signficant
concern to some very bright people and is being actively investigated.

It is, though, not entirely clear to me that the situation is capable
of a meaningful solution. People thought they had the answer with
"4GL", Fourth Generation Programming Languages, which were supposed to be
simple enough thta "even managers" could write code, with all the
details being taken care of by the compiler. The result was, of course,
a lot of very bad code, and and the recognition that large programs
*are* complex and that the best that was really being done was to remove
a constant factor from the complexity analysis, rather than reducing
the inherent complexity.

I have to ask whether you are perhaps expecting too much. In Newton's
time, people were able to create a machine that broke one treelimb
in two pieces over the course of hours -- long enough that one could
be there to catch half of it. After Watt's invention of the steam
engine, and after Ford's essential implimentation of standardized
parts (based upon earlier proposals), we are now at the point that
we have machines that can grind an entire large tree into shavings
within a matter of minutes. Tree-destroying hardware has progressed.
Do you feel significant concern that Evolution hasn't seen fit to
speed up human reactions to the point where we can still catch
half of those output in our bare hands over a matter of minutes?


:Moreover, having worked in Delphi and done a test run with c++ I'm pretty
:sure OOP is not the way to do this. It's not better, it's just easier.
:Underlying all those fancy visual design tools and object methods is still a
rocedural core upon which the CPU itself relies. C still underlies C++,
ascal still underlies Delphi. That procedural languages are not
rogressing in the forefront of programming is, ummm, disappointing.

Well, I can tell you that adding a true String type to C would not have
made any signficant difference towards that end.

Modern procedural languages do not have significantly more expressive
power? That's like saying that Predicate Calculas should be retired
because it hasn't advanced significantly since Goedel's Completeness
Theorem of about 1933. The essential logical elements required for
programming were invented a long time ago, and haven't advanced
signficantly because they were shown to be logically sufficient. It's
like the transition from DFA (Deterministic Finite Automata) to NDFA
(Non-Deterministic Finite Automata) -- it might look wonderful on the
surface, but it turns out only be able to express the same things after
all. For software to "advance" markedly would require that something be
discovered that could not be computed with what we have now -- the
equivilent of finding that we have to go to LALR(1) grammars. Except
that Goedel and Turing and Church-Rosser have shown that there *isn't*
anything like that waiting out there for us, not until we get into
either infinities (traditional computing is not very good at producing
infinite answers in a finite time), or into non-deterministic
computations.


Do you know what the most common solution is for "fixing"
"The Software Deficeit" ? It is producing standardized library
toolkits to act as "building blocks" for programs, so that
people can fit together standardized, debugged, well-understood
tools instead of having to write from scratch so much.
And the odd thing about the mass toolkit/building-block
approach is that it relies *heavily* upon standardization,
upon nailing down every last behaviour and saying "Things will
mean this one thing and this one thing only". Which is the
opposite of what you are advocating -- you want evolution
through the gradual adoption of non-standard components,
whose meaning and API gets defined by historical accident and
historical pressure rather than being rigerously defined by
a group dedicated to producing precise and logically coherent
foundations.

The "evolution and common adoption by the masses" approach has
already been tried: that's a capsule summary of the Microsoft
Windows family of operating systems ("You can't make us publish
API's, that would reduce our capacity to innovate!"). The fobiles
of MS Windows are legendary (but unfortunately, not mythical.)
If the future of computing is more of the same, more of MS Window's
way of operating, then IMHO computing would be in -serious- trouble.

 

[Chris Croughton]

Then where's the progress? If we continue to write for the lowest common
denominator the language remains stagnant in perpetuity.

Well, for a couple of decades. How long has English been effectively
the same? Or French? Or Icelandic? The latter is virtually unchanged
from the Norse spoken by Eric the Red a millenium ago (it's had a few
words added, and a few minor changes, but Eric would still be able to
converse easily with modern inhabitants).

For example: I've already mentioned I would like to see an implementation
of C with real string variables. If this were done and it proved truly
useful then it should (reasonably) proliferate to other implementations
eventually reaching the point of becoming standard.

And the fact that it hasn't caught on should tell you something about
its usefulness as a language structure. Fine, you like strings, use C++
or Java (I do, when I want to do heavy string processing). But C is
used in thousands of applications where string processing is not needed,
or not in that form.

This is progress, the language is dynamic, always changing and progressing.

Always becoming incompatible, so that programs are treated as "write
only".

Without this, we end up programming by decade old rules on machines far more
capable than the ones the rules were written for; in effect holding back
progress in the very industry we support.

What is it holding back? What machine features can not be accessed
using C as it stands?

Hardware reaches new generations in a matter of months,

Only if define a 'generation' as an increment of speed or size. Most of
the really innovative designs (the Transputer, for example) have died
because they were solutions in search of a problem, there was no actual
ned for them.

many programming languages are still essentially
where they were in the early 80s. Where software once drove hardware,
demanding progress, we are now approaching a point where the situation is
reversing... hardware is now driving software. It would be a mistake to not
keep up.

What hardware features are "driving software"? I can't see any which
would need a radical rethink in software design. Indeed, the main
features affecting software are the ones which support the 'sloppy'
programming you dislike -- cheap fast big memory and processors, which
let the software concentrate on design without having to program for the
last byte and microsecond.

Moreover, having worked in Delphi and done a test run with c++ I'm pretty
sure OOP is not the way to do this. It's not better, it's just easier.

Which means, in many cases, that it allows the design to be built
without having to worry about the nitty-gritty of the implementation, by
using standard easily testable building blocks. Like strings. Hold on,
aren't strings one of the things you like?

Underlying all those fancy visual design tools and object methods is still a
procedural core upon which the CPU itself relies.

And while it does, that's what we're stuck with. There hasn't been a
paradigm shift in hardware -- what I'd call a 'generation' -- since the
1960s, the basic principles and operations would be familiar to Turing
(or even Babbage). OK, the speed and size of the hardware would boggle
them (it boggles me on occasion, I grew up when a large mainframe had
64K words of core store and there were only a few of them in the whole
country!), but that's only a matter of scale.

The expected breakthrough hasn't appeared, te hardware is still growing
only quantitavely. That being so, why should software be any different?

C still underlies C++,
Pascal still underlies Delphi. That procedural languages are not
progressing in the forefront of programming is, ummm, disappointing.

I'm disappointed that the promised "neural network" systems seem to have
not gone anywhere. I'm disappointed that cars are still essentially the
same as the Model T (minor user interface changes) and we're still using
fossil fuels for them. I'm disappointed that the politicians are still
behaving like power-crazed brats. I'm disappointed that the space
program hasn't progressed (indeed, has regressed in many ways). I'm
disappointed that we still don't have fusion power.

Life is full of disappointments, I'm afraid...

Chris C

 

[not]

Try comp.std.c.

Ummm... lets see if I'm getting this...

In comp.lang.c one is only allowed to discuss standardized C.
However, in comp.std.c one is only allowed to discuse non-standard C

Isn't that backwards?

 

[not]

In the periodically posted "Welcome to comp.lang.c!" article.
This article reflects the quasi-consensus of this newsgroup's regulars.

Thank you. That's all I wanted to know.

 

[not]

What language is "mystery.exe" supposed to compile?

The name was fictionalized as I'm sure the writer reads these newsgroups.

I'm thinking he'll recognize himself in the description and perhaps consider
typing up a few pages of documentation... I'm not trying to embarrass the
guy.

go to comp.lang.c and try to convince the
people there, that's where future language directions are discussed.

This IS comp.lang.c ...

Looking for Pelles C using Google, I see that it's another one based on
LCC as is Mr. Navia's compiler, so that should be on topic on
comp.compilers.lcc as well.

Apparently not.

If you want to discuss standard C, however, as it is and not as some
language you might like to use which isn't C, you're welcome to do so
here...

Apparently not.

Anyway... thanks for the responses on this.
I guess I'll just take up knitting.

 

[CBFalconer]

Ummm... lets see if I'm getting this...

In comp.lang.c one is only allowed to discuss standardized C.
However, in comp.std.c one is only allowed to discuse non-standard C

Isn't that backwards?

No, they discuss future possible changes to the standard. Here we
use the existing standard. You have no excuse for not knowing what
is and is not on-topic here anymore, so kindly abide by it.

 

[Chris Croughton]

The name was fictionalized as I'm sure the writer reads these newsgroups.

I'm thinking he'll recognize himself in the description and perhaps consider
typing up a few pages of documentation... I'm not trying to embarrass the
guy.

Ah. I've never seen such a compiler.

This IS comp.lang.c ...

Grr, I meant comp.std.c.

Apparently not.

Ah, well, perhaps you need to start another newsgroup.

Apparently not.

Why not? No one is complaining about people willing to discuss standard
portable C that I've seen.

Anyway... thanks for the responses on this.
I guess I'll just take up knitting.

It's not standardised. But it is, usually, portable <g>...

Chris C