Is it too late to fix c99?
Trent Waddington
actually use." - Dennis Ritchie [1]
It's 2002, and c99 still isn't being taken seriously by compiler
developers. The standard is barely implemented on any compiler.
Compiler developers who claim conformance to the c89/90 standard best
go have a look at webstore.ansi.com, you can't buy that standard
anymore. c99 is the C standard, and there isn't a standards compliant
compiler on the planet.
The response from programmers has been mild shock to total outrage.
c99 violates the spirit of C. VLAs don't trust the programmer. The
restrict keyword (although useful for vectorization) prevents the
programmer from doing what needs to be done. Introducing complex and
imaginary numbers is not keeping the language small and simple.
Alternative spellings provide more than one way to do an operation.
The impact on portability that c99 has had (and is having right now)
has not been for any performance purpose.
The X3J11 committee was charged with codifying an existing language,
not designing a new one. Adding extensions to libraries and the
language is what the compiler vendors are supposed to do. The
language should change by programmers deciding what features they are
willing to use (possibly at the expense of portability). When enough
programmers decide a feature is worthwhile, market forces will drive
forward adoption. Just as a number of other compilers support the GNU
and Microsoft extensions, and it works both ways. Microsoft has
specifically stated that Visual C++ will have new features added to it
when they are being used in code that other compilers can build [2].
Only when these extensions become common existing practice, should
they then go to the committee for codification. In fact, that is the
mandate of the committee: "to codify common existing practice" [3].
Declarations. When did this become negotiable? Not too many people
seem to know that c99 makes this legal C:
void somefunc()
{
int a = 5;
printf("can you believe these ");
int j = a + 4;
printf("%d lines are legal C?\n", j);
for (int i = 0; i < a; i++)
printf("stupid\n");
}
least of all the compiler developers. *Who* is responsible for this?
It's not in any compiler I've had the pleasure of using. Perhaps this
is just a blatant attempt to bring those C++-is-a-better-C-than-C
users back into fold.
VLAs are overly complex. They are not common, nor existing, nor in
practice. What _is_ common is alloca(). The big three, Microsoft,
Borland and GNU support it, and ample code use it. Is it
standardized? No. The only reason I have gotten out of anyone for
this is that the standard does not distinguish between stack memory
and heap memory. So what? alloca() is easy to define without doing
that:
#include <stdlib.h>
void *alloca(size_t size);
The alloca function allocates space for an object whose size is
specified by size and whose value is indeterminate. The space is
automatically freed upon return of the calling function.
Now what is so hard about that? c99 could have ended this flame war
[4].
Zero length arrays in structs are not supported. The common existing
practice to access beyond the invariant part of a variable size
structure is to use a zero length array:
struct foo1 {
int nbytes;
char bytes[0];
};
Is this standardized? No. Instead we're told to do this:
struct foo2 {
int nbytes;
char bytes[];
};
Who does that? Not anyone who uses gcc, it doesn't allow it [5].
What does this actually mean anyway? Does sizeof(foo2) == sizeof(int)
== sizeof(foo1)? Seems to me foo2 doesn't have a determinable size, so
how would I go about creating one?
c99 introduces arbitrary indulgences to the C language which are not
in common existing practice, but even when c99 does try to codify
something that is common they miss the ball. snprintf is a common
function. It is worthy of standardization. However c99 states that
this function returns the number of characters (excluding the trailing
'\0') which would have been written to the final string had enough
space been available [6], whereas most common implementations returned
-1 if not enough space was available! As a result any code which was
written as such:
if (snprintf(buf, sizeof(buf), "%s/.configfile", home_dir) == -1) {
/* spit terribly important error message here */
exit(1);
}
will silently break. Avoid "quiet changes." That's what the
committee rationale says! Where's my QUIET CHANGE warning?
One tries to be thankful that c99 is largely being ignored. But
without a valid standard I fear the most portable language ever
created (I'm not talking about Java here) may soon be pushed out of
the limelight. We're heading into C++ territory. I want to be able
to write good portable C code, not wrestle with poorly constructed
compiler documentation and an even more poorly constructed standard
just to figure out what features of the language are valid.
I call upon the committee to conform to the rationale under which it
was formed. Fix the c99 standard so it reflects the will of the
programmers and implement what is common, not invent a new language.
Trent Waddington
Compiler Developer
The above are my own opinions and do not represent the policy of my
current or previous employers.
References
1. Dennis Ritchie: Why I do not like X3J11 type qualifiers
http://www.lysator.liu.se/c/dmr-on-noalias.html
2. An interview with Microsoft's new Visual C++ Architect Stanley
Lippman
http://www.codeproject.com/interview/stanlippman14nov2001.asp?print=true
3. Rationale for American National Standard for Information Systems -
Programming Language - C"
http://www.lysator.liu.se/c/rat/title.html
4. alloca wars David Keppel + complete thread (1988)
http://groups.google.com/groups?hl=en&selm=5422%40june.cs.washington.edu
5. Status of C99 features in GCC
http://gcc.gnu.org/c99status.html
6. ANSI+ISO+IEC+9899-1999.pdf (the C99 standard), I can't link to
this, I've
gotten in trouble before.
Martien Verbruggen
Trent Waddington <q...@rtfm.insomnia.org> wrote:
> "The committee has created an unreal language that no one can or will
> actually use." - Dennis Ritchie [1]
>
> It's 2002, and c99 still isn't being taken seriously by compiler
> developers.
On what do you base this?
> Compiler developers who claim conformance to the c89/90 standard best
> go have a look at webstore.ansi.com, you can't buy that standard
> anymore. c99 is the C standard, and there isn't a standards compliant
> compiler on the planet.
Yes, there is.
Martien
--
|
Martien Verbruggen | Begin at the beginning and go on till you
| come to the end; then stop.
|
Gergo Barany
> [much snippage throughout]
> c99 violates the spirit of C.
According to one school of thought, anyone who invokes the "spirit of
C" instead of real technical arguments has already lost the debate.
> VLAs don't trust the programmer.
Could you explain what you mean by this?
> The
> restrict keyword (although useful for vectorization) prevents the
> programmer from doing what needs to be done.
And this?
> Declarations. When did this become negotiable? Not too many people
> seem to know that c99 makes this legal C:
Are you saying that it's the Standard's fault that many people don't
read it?
> void somefunc()
> {
> int a = 5;
> printf("can you believe these ");
> int j = a + 4;
> printf("%d lines are legal C?\n", j);
> for (int i = 0; i < a; i++)
> printf("stupid\n");
> }
void somefunc()
{
int a = 5;
printf("These ");
{
int j = a + 9;
printf("%d lines have been legal C for a long time.\n", j);
}
{
int i;
for (i = 0; i < a; i++)
printf("syntactic sugar\n");
}
}
> It's not in any compiler I've had the pleasure of using.
GCC 3.0 -Wall -W -ansi -pedantic -std=c99 complains but accepts it.
> VLAs are overly complex. They are not common, nor existing, nor in
> practice.
Afaik, GCC has had them for a long time, even before C99 (but with
somewhat different semantics, I believe).
> What _is_ common is alloca(). The big three, Microsoft,
> Borland and GNU support it, and ample code use it. Is it
> standardized? No.
That is a good point. I would have liked to see it.
> Is this standardized? No. Instead we're told to do this:
>
> struct foo2 {
> int nbytes;
> char bytes[];
> };
>
> Who does that? Not anyone who uses gcc, it doesn't allow it [5].
> [footnote copied here]
> 5. Status of C99 features in GCC
> http://gcc.gnu.org/c99status.html
That page says "flexible array members Done". GCC 3.0 supports them,
too.
> What does this actually mean anyway? Does sizeof(foo2) == sizeof(int)
> == sizeof(foo1)? Seems to me foo2 doesn't have a determinable size, so
> how would I go about creating one?
C99 defines the size.
> c99 introduces arbitrary indulgences to the C language which are not
> in common existing practice, but even when c99 does try to codify
> something that is common they miss the ball. snprintf is a common
> function. It is worthy of standardization. However c99 states that
> this function returns the number of characters (excluding the trailing
> '\0') which would have been written to the final string had enough
> space been available [6], whereas most common implementations returned
> -1 if not enough space was available!
The C99 behavior is superior because it simplifies allocating enough
memory for a second attempt.
> As a result any code which was
> written as such:
>
> if (snprintf(buf, sizeof(buf), "%s/.configfile", home_dir) == -1) {
> /* spit terribly important error message here */
> exit(1);
> }
Any code written like this is crap. Exiting with an undefined
termination status because the user had the audacity to exceed a
limit that is Arbitrary But Large Enough Because I Say So[tm] is
very unprofessional.
> will silently break. Avoid "quiet changes." That's what the
> committee rationale says! Where's my QUIET CHANGE warning?
The Committee did not quietly change the behavior of C89
implementations with this. While this might indeed break code,
that's to be expected if you use nonportable constructs. If you want
to compile your code using C89 + extensions, you'll have to port it
to C99. If not, keep using C89 or a hybrid.
> I call upon the committee to conform to the rationale under which it
> was formed. Fix the c99 standard so it reflects the will of the
> programmers and implement what is common, not invent a new language.
You'll find more Committee members in comp.std.c than in comp.lang.c.
Gergo
--
"... we define the quality factor Q_p as the ratio of the resistance
to the reactance of the inductance at resonance."
-- Allan R. Hambley, "Electrical Engineering: Principles and Applications"
Russ Bobbitt
wrote:
>"The committee has created an unreal language that no one can or will
>actually use." - Dennis Ritchie [1]
Why did you choose to use this as a preface to your diatribe when it
has no relevance to C99?
[snip]
>References
>1. Dennis Ritchie: Why I do not like X3J11 type qualifiers
> http://www.lysator.liu.se/c/dmr-on-noalias.html
[After Dennis Ritchie had written the following critique of type
qualifiers in the draft ANSI standard of January 1988, the bar on
assignments to previously const-qualified lvalues was removed, and
noalias did go.]
Article 7844 of comp.lang.c:
From: d...@alice.UUCP
Newsgroups: comp.lang.c
Subject: noalias comments to X3J11
Message-ID: <77...@alice.UUCP>
Date: 20 Mar 88 08:37:58 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 333
Reproduced below is the long essay I sent as an official comment to
X3J11. It is in two parts; the first points out some problems in the
current definition of `const,' and the second is a diatribe about
`noalias'.
...
Russ
Joona I Palaste
>>"The committee has created an unreal language that no one can or will
>>actually use." - Dennis Ritchie [1]
[snip]
>>References
>>1. Dennis Ritchie: Why I do not like X3J11 type qualifiers
>> http://www.lysator.liu.se/c/dmr-on-noalias.html
> [After Dennis Ritchie had written the following critique of type
> qualifiers in the draft ANSI standard of January 1988, the bar on
> assignments to previously const-qualified lvalues was removed, and
> noalias did go.]
[snip snipped post by DMR]
I have never heard of this "noalias" thingy. What was it supposed to do?
Please provide a detailed description. Was it actually implemented
anywhere?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am looking for myself. Have you seen me somewhere?"
- Anon
P.J. Plauger
> I have never heard of this "noalias" thingy. What was it supposed to do?
> Please provide a detailed description. Was it actually implemented
> anywhere?
It was reborn as restrict in C99, with rather less ambitious semantics.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Joona I Palaste
> "Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message news:a8hr7m$1dk$1...@oravannahka.helsinki.fi...
>> I have never heard of this "noalias" thingy. What was it supposed to do?
>> Please provide a detailed description. Was it actually implemented
>> anywhere?
> It was reborn as restrict in C99, with rather less ambitious semantics.
But could I find the original ambitious semantics anywhere?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"We're women. We've got double standards to live up to."
- Ally McBeal
Reginald Blue
> P.J. Plauger <p...@dinkumware.com> scribbled the following:
> > "Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message
news:a8hr7m$1dk$1...@oravannahka.helsinki.fi...
>
> >> I have never heard of this "noalias" thingy. What was it supposed to
do?
> >> Please provide a detailed description. Was it actually implemented
> >> anywhere?
>
> > It was reborn as restrict in C99, with rather less ambitious semantics.
>
> But could I find the original ambitious semantics anywhere?
This, I think, goes into enough detail to understand what the semantics were
supposed to be:
http://www.lysator.liu.se/c/dmr-on-noalias.html
P.J. Plauger
> >> I have never heard of this "noalias" thingy. What was it supposed to do?
> >> Please provide a detailed description. Was it actually implemented
> >> anywhere?
>
> > It was reborn as restrict in C99, with rather less ambitious semantics.
>
> But could I find the original ambitious semantics anywhere?
From my Standard C column in C Users Journal, May 1988:
Some members of X3J11 are interested in compiling C for computers with
vector processors. Others are interested in aggressive optimizations
that need the same sort of technology that you need to take advantage
of vector processors. FORTRAN has been very successful in this area
because the aliasing rules for that language give the optimizer enough
information to know when it is safe to vectorize. C is not so kind.
Let's say that you want to write a function that adds the N element
vectors A and B to form the vector C. You can easily write the function:
void vadd(const float *A, const float *B,
float *C, int N)
{
while (0 <= --N)
*C++ = *A++ + *B++;
/* OR C[N] = A[N] + B[N]; */
}
Whichever way you write it, you would like a vectorizing
(or aggressively optimizing)
translator to know that it is okay to pickup all the elements of
A and B before any values are stored in C.
Given the rules stated above regarding stores into data objects
and sequence points, this is only safe if C does not overlap
either of the two input vectors.
Otherwise, you cannot advance or retard accesses past sequence points
and be assured of getting the same result as if you honored
all of the sequence points.
(It is okay for the two input vectors to overlap, since they are never
modified.
Any rearrangement of accesses from these vectors should give the same
result.)
What you need is some way to assure the translator that
none of the operands overlap in a dangerous way.
After considerable debate, the Committee decided that this was important
enough to take a rather major step.
At the eleventh hour (almost literally), X3J11 introduced a new type
qualifier to let you specify when a pointer designates a data object
that is in some sense private to that pointer.
The new type qualifier is specified by the new keyword noalias.
You can write it anywhere that you can write the other type
qualifiers that the Committee has introduced, const
and volatile.
In the example above, you would declare the function as:
void vadd(const noalias float *A,
const noalias float *B,
noalias float *C, int N)
The type qualifiers const and volatile tell you
something about the properties of the data object that you reach
via an lvalue.
They certainly affect how you can optimize the use of lvalues,
but in some ways the effect is indirect.
const makes useful promises about data objects.
volatile tells the translator when it cannot optimize.
The type qualifier noalias, on the other hand, tells you more
about how the translator can optimize accesses using a given lvalue
than it tells you about the data object itself.
I like to think of noalias as the 1980's version of the
register storage class.
From a semantic standpoint, all register promises is that
you cannot take the address of a data object declared with that storage
class.
That gives the translator latitude to put it in a fast storage register
from the outset, but it doesn't have to.
Most programmers assume that register is also a strong suggestion
that the data object in question is used often enough to warrant using
up a precious machine register, but that may not be true either.
Modern translators can generally detect whether a data object
with dynamic storage can safely be promoted to a register.
They can also estimate, often better than the programmer, which
data objects warrant being placed in registers and which should
be left on the stack.
The storage class register is in many ways an anachronism.
Nevertheless, it was an important assist in the early days of C,
given the tighter constraints on the size of the first C translators.
I'm sure that the day will come when C translators will be smart
enough to detect when aliasing is likely to occur and when it is safe
to assume that it does not.
Meanwhile, the state of the art of translators is such that the
noalias type qualifier can give just the hint that many
translators need to do a significantly better job of optimizing code.
I should emphasize, by the way, that noalias is still the
subject of intense scrutiny.
As of this writing, the second formal public review period has not
yet ended.
Whether noalias survives with just a few editorial tweaks,
or whether it suffers major surgery, is still unknown.
Many Committee members feel that something of this sort
is needed, so I am expecting that it will survive in some form.
Joona I Palaste
>> >> I have never heard of this "noalias" thingy. What was it supposed to do?
>> >> Please provide a detailed description. Was it actually implemented
>> >> anywhere?
>>
>> > It was reborn as restrict in C99, with rather less ambitious semantics.
>>
>> But could I find the original ambitious semantics anywhere?
> From my Standard C column in C Users Journal, May 1988:
(snip)
So "noalias" was supposed to be a storage class specifier for pointer
types, claiming to the compiler: "The data this pointer points to (now
or in future) will never ever be pointed to by another pointer"? That
could allow some optimisations by the compiler.
Of course, you would have been free to break that promise, but then
again you're also free to try to modify string literals...
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"My absolute aspect is probably..."
- Mato Valtonen
Tony Finch
The reason for this is that C doesn't have any zero-sized objects,
so the GNU C extension for the variable-size struct hack doesn't
fit the language properly.
>c99 introduces arbitrary indulgences to the C language which are not
>in common existing practice, but even when c99 does try to codify
>something that is common they miss the ball. snprintf is a common
>function. It is worthy of standardization. However c99 states that
>this function returns the number of characters (excluding the trailing
>'\0') which would have been written to the final string had enough
>space been available [6], whereas most common implementations returned
>-1 if not enough space was available!
That is incorrect. 4.4BSD and GNU libc have used the same semantics as
C99 since 1991. SUSv2 (1997) doesn't specify it properly, although the
C99 draft was around at the time. SUSv3 follows C99.
Tony.
--
f.anthony.n.finch <d...@dotat.at>
CROMARTY FORTH TYNE: EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6. FAIR. MODERATE
OR POOR.
Dennis Ritchie
>
> "Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message news:a8i0d6$6ha$1...@oravannahka.helsinki.fi...
>
> > >> I have never heard of this "noalias" thingy. What was it supposed to do?
> > >> Please provide a detailed description. Was it actually implemented
> > >> anywhere?
> >
> > > It was reborn as restrict in C99, with rather less ambitious semantics.
> >
> > But could I find the original ambitious semantics anywhere?
>
> From my Standard C column in C Users Journal, May 1988:
which I won't quote. I managed to dredge up a portion of
a draft of the noalias proposal, which I reproduce below.
I also have a mailed proposal from Dave Prosser with a
refined version; I'm not sure which was on ANSI's table.
In this version, I was especially suspicious of the notions
of "handle" and "virtual object."
The proposal was fleshed out somewhat in Prosser's later
suggestion, but in a way that seemed to be digging a hole deeper.
I decided to leave in the original troff markup
for authenticity; it's not hard to read through it.
Dennis
.HU Semantics
.P
The properties associated with qualified types are
meaningful only for expressions that are lvalues.\*F
.P
Each lvalue that is a unary expression with the unary
.Cf *
indirection operator
(either explicitly
or as a result of the array subscript
.Cf []
operator)
contains one or more
.IR handles .
These handles have pointer or array type
and are the smallest expressions contained within the lvalue
(ignoring the left operand of the comma operator,
the operand of the
.Cf sizeof
operator,
all argument expressions,
and all expressions with integral type),
and are associated with the entire object
to which the lvalue refers,
in part or as a whole.
The handles for lvalues with noalias-qualified type are
.IR "noalias handles" .
A handle is distinguished by the spelling of its operands
(ignoring the spelling of any contained argument expressions)
and by the storage duration of its
.IR "handle objects" ,
those objects whose values are accessed to evaluate the handle
(excluding any objects accessed to evaluate
any contained argument expressions).
.P
The
.I "actual object"
of a noalias handle is the entire object of which
a part is designated by the same lvalue
except that its type is the non-noalias-qualified version.
For each distinct noalias handle,
it is unspecified whether the handle is associated with the actual object
or is associated with a
.IR "virtual object" ,
a distinct object with the same size and address as the actual object.
The behavior of a program that depends upon
a specific implementation choice is undefined.
.P
A virtual object,
if and when created,
acquires the last-stored value of the actual object.
A virtual object may be created at any sequence point
within a function for which there exists a sequence point
at which the storage for all handle objects
is guaranteed to be reserved.
A virtual object has a
.IR "pending value"
if it has been modified through use of
its noalias handle and the actual object does not
have the same value.
All virtual objects with pending values for a noalias handle
have their values assigned to their respective actual objects
at the return of a function after whose execution
storage is no longer guaranteed to be reserved
for a handle object of the noalias handle.
.P
If an argument expression is a noalias handle,
or is a noalias handle plus or minus an expression with integral type
(either explicitly
or as a result of combinations of the unary
.Cf &
address operator and the array subscript
.Cf []
operator),
just after the return from the function,
the value stored in the actual object
is assigned to the currently associated virtual object,
if any exists.\*F\
.FS
If the called function has a type that includes a prototype
and the type of the parameter is a pointer to a const- and
noalias-qualified type,
this assignment can be suppressed,
as the called function cannot modify the designated object.
.FE
Furthermore,
if, at the sequence point just before the call to the function,
the noalias handle is currently associated
with a virtual object with a pending value,
its value is assigned to the actual object at that sequence point.
Micah Cowan
> "The committee has created an unreal language that no one can or will
> actually use." - Dennis Ritchie [1]
I'm afraid I must disagree with Mr. Ritchie. I find the majority of
the changes to be quite welcome, and a long time in coming, in fact.
> c99 violates the spirit of C.
Which is?
> VLAs don't trust the programmer.
Please expound. In what way don't they trust the programmer? I find
them convenient, except for how they might leak on longjmp().
> The restrict keyword (although useful for vectorization) prevents the
> programmer from doing what needs to be done.
Which is? ...I don't see how this is so, by a long shot. Rather, it
makes certain guarantees to the compiler (or whatever implementation)
for optimization
> Introducing complex and
> imaginary numbers is not keeping the language small and simple.
When was C small or simple, please? (compared to C++, sure, but...)
Those who find themselves dealing with significant mathemnatic
calculations and modeling will be quite pleased with these changes. I
think the committee may be trying to snag some FORTRAN folks... ;)
> Alternative spellings provide more than one way to do an operation.
Alternative spellings have been around for longer than c99. And since
when has "more than one way" been a *bad* thing?!?!?
> The impact on portability that c99 has had (and is having right now)
> has not been for any performance purpose.
Hm. How about programmer productivity.
>
> The X3J11 committee was charged with codifying an existing language,
> not designing a new one.
Wrong. The committee was charged with keeping C up-to-date and
modern, which is why anyone bothers re-examining standards in the
first place. I have *never* see ISO standardize a language without
significantly changing it. Standardization is simply an opportunity
to keep what works in a language, and change what doesn't, or add what
is lacking.
> Adding extensions to libraries and the
> language is what the compiler vendors are supposed to do.
Huh. That's a rather unusual opinion. Extensions are what compiler
vendors add to their products when they notice a useful feature which
the language lacks. Extensions are a hindrance to portability, so it
is in everybody's interest *not* to leave this up to the compiler
vendors, but rather to standardize on the common extensions. Which is
where a great deal of C99's changes have come from.
> The language should change by programmers deciding what features
> they are willing to use (possibly at the expense of portability).
I don't like loosing portability.
> Declarations. When did this become negotiable? Not too many people
> seem to know that c99 makes this legal C:
>
> void somefunc()
> {
> int a = 5;
> printf("can you believe these ");
> int j = a + 4;
> printf("%d lines are legal C?\n", j);
> for (int i = 0; i < a; i++)
> printf("stupid\n");
> }
Those who know anything at all about C99, know at least the above.
And while I can't say I necessarily like the unrestrained
intermixings, I definitely consider the index declaration in the
for-loop a blessing.
> least of all the compiler developers.
Now you're just being silly.
> VLAs are overly complex.
Nonsense. How could they be simpler?
> They are not common, nor existing, nor in
> practice.
Untrue. GNU had already supported them, though with subtly different
semantics.
> What _is_ common is alloca(). Is it standardized? No. The only
> reason I have gotten out of anyone for this is that the standard
> does not distinguish between stack memory and heap memory. So what?
> alloca() is easy to define without doing that:
>
> #include <stdlib.h>
> void *alloca(size_t size);
What about this makes you think you can define alloca() easily? I
challenge you to actually define it.
...Enough with this. After so many completely meritless statements,
there doesn't seem much point to this. I doubt you'll get much
agreement here. C99 may not be perfect, but it seems less imperfect
than C90, to me. Among my favorite features are complex literals,
VLAs, complex numbers, the expanded math lib, and the inline for-loop
declarations.
Micah
Trent Waddington
> ...Enough with this. After so many completely meritless statements,
> there doesn't seem much point to this. I doubt you'll get much
> agreement here. C99 may not be perfect, but it seems less imperfect
> than C90, to me. Among my favorite features are complex literals,
> VLAs, complex numbers, the expanded math lib, and the inline for-loop
> declarations.
Perhaps if you actually read the references you would know what the
essay was about.
Trent Waddington
dorian
>
> One tries to be thankful that c99 is largely being ignored. But
> without a valid standard I fear the most portable language ever
> created (I'm not talking about Java here) may soon be pushed out of
> the limelight. We're heading into C++ territory. I want to be able
> to write good portable C code, not wrestle with poorly constructed
> compiler documentation and an even more poorly constructed standard
> just to figure out what features of the language are valid.
>
Well c++ is already heading the same way as the dodo.
According to .NET magazine and Microsoft, 60% of all you application
developers are gonna be C# programmers by October 2005! Aren't you
EXCITED!
We are looking at "Widespread .NET adoption". Yea baby!
All this bickering about C and C++ and thier standards is useless.
You WILL be assimilated. And guess who is gonna set the standard for
C#.
hmmm? Microsoft and nobody else but Microsoft. No more of this C and
C++ chaos anymore. no sir. It's "C-Shit" from now on.
(oops i said a no-no didn't I?)
check it out: http://www.fawcette.com/dotnetmag/2001_12/magazine/features/enelson/
chao!
Ioannis Vranos
news:efccbacb.0204...@posting.google.com...
>
> Declarations. When did this become negotiable? Not too many people
> seem to know that c99 makes this legal C:
>
> void somefunc()
> {
> int a = 5;
> printf("can you believe these ");
> int j = a + 4;
> printf("%d lines are legal C?\n", j);
> for (int i = 0; i < a; i++)
> printf("stupid\n");
> }
>
> least of all the compiler developers.
Basically this is the only thing i agree with C99.
> *Who* is responsible for this?
> It's not in any compiler I've had the pleasure of using. Perhaps this
> is just a blatant attempt to bring those C++-is-a-better-C-than-C
> users back into fold.
The above you criticise is the one of the few things i consider as an
improvement of C99.
>
> VLAs are overly complex. They are not common, nor existing, nor in
> practice. What _is_ common is alloca(). The big three, Microsoft,
> Borland and GNU support it, and ample code use it. Is it
> standardized? No. The only reason I have gotten out of anyone for
> this is that the standard does not distinguish between stack memory
> and heap memory. So what? alloca() is easy to define without doing
> that:
>
> #include <stdlib.h>
> void *alloca(size_t size);
>
> The alloca function allocates space for an object whose size is
> specified by size and whose value is indeterminate. The space is
> automatically freed upon return of the calling function.
Now this is lame critique. I do not know alloca() but i guess you imply
garbage collection? And because MS, GNU and Borland support it, it
should become a part of the standard? The standard needs not to adopt
every available "easy" feature but only the can-not-do-without-it ones
(and it did adopt useless things).
> Now what is so hard about that? c99 could have ended this flame war
> [4].
>
> Zero length arrays in structs are not supported. The common existing
> practice to access beyond the invariant part of a variable size
> structure is to use a zero length array:
>
> struct foo1 {
> int nbytes;
> char bytes[0];
> };
>
> Is this standardized? No. Instead we're told to do this:
I did not understand the whole concept. Where would this crap be useful?
If you have allignment isses you can use the style:
struct foo1
{
int nbytes;
int bytes:1;
};
> struct foo2 {
> int nbytes;
> char bytes[];
> };
>
> Who does that? Not anyone who uses gcc, it doesn't allow it [5].
And? GCC will change its behavior. I agree with the noone uses it, i
don't care for your compiler (although i heavily use GCC/MINGW).
> What does this actually mean anyway? Does sizeof(foo2) == sizeof(int)
> == sizeof(foo1)? Seems to me foo2 doesn't have a determinable size, so
> how would I go about creating one?
Yes this is indeed a new mess of C99.
> c99 introduces arbitrary indulgences to the C language which are not
> in common existing practice, but even when c99 does try to codify
> something that is common they miss the ball. snprintf is a common
> function. It is worthy of standardization. However c99 states that
> this function returns the number of characters (excluding the trailing
> '\0') which would have been written to the final string had enough
> space been available [6], whereas most common implementations returned
> -1 if not enough space was available!
Pre-standard common implementation extensions of some compilers don't
matter.
> One tries to be thankful that c99 is largely being ignored. But
> without a valid standard I fear the most portable language ever
> created (I'm not talking about Java here) may soon be pushed out of
> the limelight.
C99 is a permanent destruction of C, i agree. but you base your thoughts
on some compiler versions which is wrong.
> We're heading into C++ territory.
It would be great if we headed to some C++ territory or in parallel to
it (i would like the notion of name spaces for example). But i think we
headed towards Fortran & Basic.
> I want to be able
> to write good portable C code, not wrestle with poorly constructed
> compiler documentation and an even more poorly constructed standard
> just to figure out what features of the language are valid.
>
> I call upon the committee to conform to the rationale under which it
> was formed. Fix the c99 standard so it reflects the will of the
> programmers and implement what is common, not invent a new language.
It can't be fixed. What is done is done, the only thing that can be done
is a future standard to deprecate useless things and introduce other
useful features.
>
> Trent Waddington
> Compiler Developer
I thought you were using Borland's, Microsoft's and GCC.
>
> The above are my own opinions and do not represent the policy of my
> current or previous employers.
>
> References
>
> 1. Dennis Ritchie: Why I do not like X3J11 type qualifiers
> http://www.lysator.liu.se/c/dmr-on-noalias.html
This is for the previous standard!
> 2. An interview with Microsoft's new Visual C++ Architect Stanley
> Lippman
>
http://www.codeproject.com/interview/stanlippman14nov2001.asp?print=true
I do not think MS likes openly standardised languages anyway.
> 3. Rationale for American National Standard for Information Systems -
> Programming Language - C"
> http://www.lysator.liu.se/c/rat/title.html
> 4. alloca wars David Keppel + complete thread (1988)
>
http://groups.google.com/groups?hl=en&selm=5422%40june.cs.washington.edu
Previous standard.
> 5. Status of C99 features in GCC
> http://gcc.gnu.org/c99status.html
They intend high degree of compliance.
--
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys
David Neary
>> #include <stdlib.h>
>> void *alloca(size_t size);
>>
> garbage collection?
No - alloca() is basically a function which allocates memory for
an object on the "stack" rather than the "heap". In other words,
the allocated memory is automatic, and is freed by returning from
the function. Very handy, but non-standard.
Dave.
--
David Neary,
E-Mail: bolsh at gimp dot org
Ioannis Vranos
news:slrnaasbp...@bolsh.wanadoo.fr...
> On Sat, 6 Apr 2002 01:58:10 +0200, Ioannis Vranos said:
> >> #include <stdlib.h>
> >> void *alloca(size_t size);
> >>
> > Now this is lame critique. I do not know alloca() but i guess you
imply
> > garbage collection?
>
> No - alloca() is basically a function which allocates memory for
> an object on the "stack" rather than the "heap". In other words,
> the allocated memory is automatic, and is freed by returning from
> the function. Very handy, but non-standard.
Ok, i can understand its possible (rare) use. It is like C++'s placement
operator new in which you can define where the space is to be allocated
(ANSI C++). But i haven't badly needed it either, but i guess for this
job C99 has VLAs (although the notion is not so flexible as C++'s since
in placement operator new case you can *define* it to allocate memory
from anywhere, anyway lets not compare languages).
Anyway this is not badly needed, as VLAs were not badly needed either
(as far as i have understood the latest can't signal an error condition,
and i do not want to murmur once again. One of the reasons i do not like
Pascal is that it can die so easily and {$i-} {$i+} combination & stuff
can't do much about this. In the contrary one of Cs largest features was
that it was a reliable language and a program couldn't "die" so
easily).
@$*&(*&%^^%!@# anyway.
mike burrell
> Perhaps if you actually read the references you would know what the
> essay was about.
Yes, your reference to a critique of noalias was very useful in your rant
about something which has nothing to do with noalias. Good job.
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN mik...@shaw.ca
X AGAINST HTML MAIL,
/ \ AND NEWS TOO, dammit
Eric G. Miller
>> Zero length arrays in structs are not supported. The common existing
>> practice to access beyond the invariant part of a variable size
>> structure is to use a zero length array:
>>
>> struct foo1 {
>> int nbytes;
>> char bytes[0];
>> };
>>
>> Is this standardized? No. Instead we're told to do this:
>
> I did not understand the whole concept. Where would this crap be useful?
> If you have allignment isses you can use the style:
>
> struct foo1
> {
> int nbytes;
> int bytes:1;
> };
It is not a bit field, it is a variable length struture.
Consider:
struct blob {
size_t length;
unsigned char data[];
};
struct blob *
make_blob (size_t length)
{
struct blob *the_blob = calloc (length + sizeof(struct blob), 1);
if (the_blob != NULL) {
the_blob->length = length;
}
return the_blob;
}
void
destroy_blob (struct blob **the_blob)
{
if (the_blob != NULL && *the_blob != NULL)
{
free (*the_blob);
*the_blob = NULL;
}
}
int
write_blob (FILE *ofp, struct blob *the_blob)
{
if (fwrite (&the_blob->length, sizeof(size_t), 1, ofp)
!= sizeof(size_t))
return -1;
if (fwrite (the_blob->data, 1, the_blob->length, ofp)
!= the_blob->length)
return -1;
return 0;
}
struct blob *
read_blob (FILE *ifp)
{
struct blob *the_blob = NULL;
size_t length;
if (fread (&length, sizeof (size_t), 1, ifp) != sizeof (size_t))
return NULL;
the_blob = make_blob (length);
if (the_blob != NULL)
{
if (fread (the_blob->data, 1, length, ifp) == length)
{
the_blob->length = length;
}
else
{
destroy_blob (&the_blob);
}
}
return the_blob;
}
You've eliminated a malloc and a free, and the data blob knows it's
size. The array doesn't have to be a simple type either, but could
even be an array of structs. If you have to do alot of malloc's,
cutting the number in half can help performance (so could a storage
pool...).
>> struct foo2 {
>> int nbytes;
>> char bytes[];
>> };
>>
>> Who does that? Not anyone who uses gcc, it doesn't allow it [5].
GCC 3.x sure does.
>> What does this actually mean anyway? Does sizeof(foo2) == sizeof(int)
>> == sizeof(foo1)? Seems to me foo2 doesn't have a determinable size, so
>> how would I go about creating one?
Size of all of it's non-variable length elements plus padding (if any).
Doesn't appear to be any different than the zero length version...
>> One tries to be thankful that c99 is largely being ignored. But
>> without a valid standard I fear the most portable language ever
>> created (I'm not talking about Java here) may soon be pushed out of
>> the limelight.
>
> C99 is a permanent destruction of C, i agree. but you base your thoughts
> on some compiler versions which is wrong.
Nonsense.
>> I want to be able
>> to write good portable C code, not wrestle with poorly constructed
>> compiler documentation and an even more poorly constructed standard
>> just to figure out what features of the language are valid.
>>
>> I call upon the committee to conform to the rationale under which it
>> was formed. Fix the c99 standard so it reflects the will of the
>> programmers and implement what is common, not invent a new language.
Well, ten years between major revisions is a pretty long time. And, it'll
still be a few years before one can rely on C99 for portability. C89/90 is
the safest bet when old machines need to be supported.
Ioannis Vranos
news:pan.2002.04.05.23....@jps-nospam.net...
[Useful stuff...]
> >> struct foo2 {
> >> int nbytes;
> >> char bytes[];
> >> };
> >>
> >> Who does that? Not anyone who uses gcc, it doesn't allow it [5].
I didn't say that.
> GCC 3.x sure does.
>
> >> What does this actually mean anyway? Does sizeof(foo2) ==
sizeof(int)
> >> == sizeof(foo1)? Seems to me foo2 doesn't have a determinable size,
so
> >> how would I go about creating one?
Another said that too.
> Size of all of it's non-variable length elements plus padding (if
any).
> Doesn't appear to be any different than the zero length version...
>
> >> I want to be able
> >> to write good portable C code, not wrestle with poorly constructed
> >> compiler documentation and an even more poorly constructed standard
> >> just to figure out what features of the language are valid.
> >>
> >> I call upon the committee to conform to the rationale under which
it
> >> was formed. Fix the c99 standard so it reflects the will of the
> >> programmers and implement what is common, not invent a new
language.
I did not say that.
> Well, ten years between major revisions is a pretty long time. And,
it'll
> still be a few years before one can rely on C99 for portability.
C89/90 is
> the safest bet when old machines need to be supported.
Don't mix other people words.
Trent Waddington
>
> Basically this is the only thing i agree with C99.
>
> improvement of C99.
Why? Declarations mixed into code is a lame C++ practice.
> Now this is lame critique. I do not know alloca() but i guess you imply
> garbage collection? And because MS, GNU and Borland support it, it
> should become a part of the standard? The standard needs not to adopt
> every available "easy" feature but only the can-not-do-without-it ones
> (and it did adopt useless things).
I dont agree with the introduction of VLAs not only because they were
something invented by the committee and not something they took from
common existing practice but also because of the reasons you have
stated here, it's not a necessary part of the language. ie. We didn't
need a language change to get the behaviour of alloca(), we already
had it in most all implementations, so why did the committee invent a
new language instead of standardizing the existing one? I'm
disappointed in the vast number of people who have never read the
committee's charter in the rationale under which it was formed.
> I did not understand the whole concept. Where would this crap be useful?
> If you have allignment isses you can use the style:
>
> struct foo1
> {
> int nbytes;
> int bytes:1;
> };
I think your confusion has been expounded in another reply so I wont
repeat it here, but basically you have a structure which has some
fixed portion and then a variable length portion. I am quite scared
to present this as an option but in another (insane) dialect of C you
might write:
struct foo3
{
int nbytes;
char bytes[nbytes];
};
but this is clearly a Bad Thing and I just hope that no-one ever tries
to implement this.
> And? GCC will change its behavior. I agree with the noone uses it, i
> don't care for your compiler (although i heavily use GCC/MINGW).
And therefore it is not common existing practice and shouldn't be in
the standard.
> Pre-standard common implementation extensions of some compilers don't
> matter.
Yes they do. Read the rationale.
> C99 is a permanent destruction of C, i agree. but you base your thoughts
> on some compiler versions which is wrong.
I base my thoughts on the failure of the committee to codify what is
out there being used right now and playing god with the C language.
> It would be great if we headed to some C++ territory or in parallel to
> it (i would like the notion of name spaces for example). But i think we
> headed towards Fortran & Basic.
I was more refering to widely divergent implementations from the
standard and a very small subset of the language being portable.
> It can't be fixed. What is done is done, the only thing that can be done
> is a future standard to deprecate useless things and introduce other
> useful features.
Abandon the standard. No-one is implementing it anyways. Reform the
committee and codify what is needed. If you wanna make your own
language call it something else (actually I know a number of people
who have argued that is exactly what the committee did -- make a new
language "for embedded systems" and called it c99 -- that arguement is
kind of dead however, now that you cant get c89/90 anymore).
> I thought you were using Borland's, Microsoft's and GCC.
We implement all Microsoft's and GCC's extensions (and command line
switches) and some of Borland's, Watcom's and Metroworks.
> This is for the previous standard!
Where he spells out exactly why noalias is lame and why it must not be
"renamed" into any future standard (aka "restrict"). When our
compilers are all c99 compliant maybe someone will try to unify the
language and the library and his essay will come back to haunt them.
> I do not think MS likes openly standardised languages anyway.
But they will implement features found in other compilers if customers
are using them, which is why the reference is here.
> > 3. Rationale for American National Standard for Information Systems -
> > Programming Language - C"
> > http://www.lysator.liu.se/c/rat/title.html
Read this!
> They intend high degree of compliance.
How many people actually work on GCC? We often wonder.
Trent Waddington
Ioannis Vranos
> "Ioannis Vranos" <noi...@no.spam.hotmail.com> wrote in message
news:<a8la6c$5gk$1...@ulysses.noc.ntua.gr>...
> >
> > Basically this is the only thing i agree with C99.
> >
> > The above you criticise is the one of the few things i consider as
an
> > improvement of C99.
>
> Why? Declarations mixed into code is a lame C++ practice.
It is a useful feature to define everything you need in the place you
need it. Objects having as small scope as possible is the ideal (one
result from that is that we must try avoid using global variables for
example).
Consider the code:
int i, x;
for(i=0; i<1204; i++)
/* stuff here */
/* Many lines */
for(i=25; i>0; i--)
/* stuff here */
/* x=... Lines */
i=x/24;
/* ... */
Now the danger is great if you mix variables for various purposes. If
you want to avoid using some variable for various purposes, then you are
forced to define more variables, that is more lost space.
Consider the code:
for(int i=0; i<1204; i++)
/* stuff here */
/* Many lines */
for(int i=25; i>0; i--)
/* stuff here */
/* Lines */
int result=x/24;
/* ... */
In few words, you must try using object names
> I dont agree with the introduction of VLAs not only because they were
> something invented by the committee and not something they took from
> common existing practice but also because of the reasons you have
> stated here, it's not a necessary part of the language. ie. We didn't
> need a language change to get the behaviour of alloca(), we already
> had it in most all implementations, so why did the committee invent a
> new language instead of standardizing the existing one? I'm
> disappointed in the vast number of people who have never read the
> committee's charter in the rationale under which it was formed.
At first i think we did not need them at all. I would have liked VLAs
if they were stored on the free store.
>
> > I did not understand the whole concept. Where would this crap be
useful?
> > If you have allignment isses you can use the style:
> >
> > struct foo1
> > {
> > int nbytes;
> > int bytes:1;
> > };
>
> I think your confusion has been expounded in another reply so I wont
> repeat it here, but basically you have a structure which has some
> fixed portion and then a variable length portion.
I agree with this. Instead of arrays of undefined size one could place a
pointer.
> I base my thoughts on the failure of the committee to codify what is
> out there being used right now and playing god with the C language.
Actually i believe the committee consists of "next generation"
programmers than those who were in 80's, that is programmers who began
with Basic on some Commodore 64 or Z80 or something and later with
Fortran on some 8086/8088. You know, the notion "what great it is to
have variable sized arrays". In the next 2 decades it will consist from
people who began with XBox. Now you can imagine the future.
> > It can't be fixed. What is done is done, the only thing that can be
done
> > is a future standard to deprecate useless things and introduce other
> > useful features.
>
> Abandon the standard. No-one is implementing it anyways. Reform the
> committee and codify what is needed. If you wanna make your own
> language call it something else (actually I know a number of people
> who have argued that is exactly what the committee did -- make a new
> language "for embedded systems" and called it c99 -- that arguement is
> kind of dead however, now that you cant get c89/90 anymore).
Actually i base my future on C++. If you learn it you will love it. When
i learned C89 for the first time i was a bit against C++ (you know the C
fanatism) but when i started reading it i understood that it is an
extremelly wise language. I am also very confident that BS will patrol
around the future C++ committee holding a wood-stick
in case that something gets out of control (e.g. they will wish to make
C++ convenient for XBOX programming). That is a joke, the meaning is
that i rely on him that he will make the best possible effort to not
leave the language to be destroyed. It is very good that C99 and C++200x
are dintanced about a decade, so only the few C99 useful things will be
adopted.
>
> > I thought you were using Borland's, Microsoft's and GCC.
>
> We implement all Microsoft's and GCC's extensions (and command line
> switches) and some of Borland's, Watcom's and Metroworks.
>
> > This is for the previous standard!
>
> Where he spells out exactly why noalias is lame and why it must not be
> "renamed" into any future standard (aka "restrict"). When our
> compilers are all c99 compliant maybe someone will try to unify the
> language and the library and his essay will come back to haunt them.
Perhaps like "Predator I"? (the movie). :)
> How many people actually work on GCC? We often wonder.
i think it is mentioned to their site. Anyway contributors change all
the time but the basic people which guide the project remain there.
Ioannis Vranos
>
> In few words, you must try using object names
.. in large scopes.
mike burrell
> "Ioannis Vranos" <noi...@no.spam.hotmail.com> wrote in message news:<a8la6c$5gk$1...@ulysses.noc.ntua.gr>...
>>
>> Basically this is the only thing i agree with C99.
>>
>> The above you criticise is the one of the few things i consider as an
>> improvement of C99.
> Why? Declarations mixed into code is a lame C++ practice.
Your thinking it's lame doesn't really matter. With the exception of one,
every C compiler I've used in the past 5 years supported this. And Bjarne
was right when he said that there really is no reason any more for
declarations to be pushed to the top of the scope. It really doesn't make
life any harder or easier for the compiler.
> We didn't
> need a language change to get the behaviour of alloca(), we already
> had it in most all implementations, so why did the committee invent a
> new language instead of standardizing the existing one?
alloca() was not in most all implementations. It is not even in POSIX. It
was in BSD and apparently in Windows, but it's not some great bastion of
portability.
Besides which, VLA's were not designed by committee. VLA's had been
supported by the popular GNU C compiler for quite a while before the
committee borrowed it.
Also, there are differing semantics between VLA's and alloca(), so it's hard
to compare them exactly. VLA's are true automatic memory, and are thus freed
when taken out of scope (like you would expect from an automatic object).
Memory allocated by alloca(), on the other hand, is not freed until the end
of the function, no matter which scope it's called in. There really is no
existing memory allocation in existing C which can describe the semantics of
alloca().
>> C99 is a permanent destruction of C, i agree. but you base your thoughts
>> on some compiler versions which is wrong.
> I base my thoughts on the failure of the committee to codify what is
> out there being used right now and playing god with the C language.
Most of what you say is true, but you've picked some bad examples wrt in-code
declarations and VLA's -- these have been in various implementations for some
time.
>> This is for the previous standard!
> Where he spells out exactly why noalias is lame and why it must not be
> "renamed" into any future standard (aka "restrict"). When our
> compilers are all c99 compliant maybe someone will try to unify the
> language and the library and his essay will come back to haunt them.
restrict is not "aka" noalias. They have differing semantics. Indeed the
things they did to make restrict were seemingly done in direct response to
his criticisms. Every one of the specific problems he raised have been
fixed. This is *not* a renaming.
It's true that dmr does say that the very concept of it is bad, but all
throughout his criticism he offers no actual evidence to back this up. He
only offers criticisms of the specific implementation of noalias (which,
again, have been addressed). He's not God.
You should stick with your "designed by committee" argument, because I still
don't see anything technically wrong with restrict.
Anyway, the reason I like the C99 standard is exactly *because* it
standardises on things which have been around in implementations for years
(in-code declarations, VLA's, named initialisers for aggregates).
There are some more interesting things which really do seem to have come out
of thin air (or so it seems):
- implicit 'return 0', which only applies to main()
- complex literals
- universal characters
And some things which were taken from existing implementations, but don't
follow the syntax of other implementations (and actually contradict existing
implementations in some cases):
- *snprintf()
- zero-length arrays
- inlined functions
- variadic arguments for macros
- __func__
I don't know if these are a case of NIH or just "we'll try to please everyone
by pleasing no one".
Ioannis Vranos
> "Ioannis Vranos" <noi...@no.spam.hotmail.com> wrote in message
> news:a8ndt7$2j4f$1...@ulysses.noc.ntua.gr...
> >
> > In few words, you must try using object names
>
> .. in large scopes.
*($%!@#&^
I meant: In few words, we must try to avoid using object names in large
scopes, or better, we must try define objects in as small scope as
possible.
P.J. Plauger
> Why? Declarations mixed into code is a lame C++ practice.
An assertion without proof. Actually, it lets you keep declarations
much closer to the point of first use, without the artifice of starting
a new block. Requiring all the declarations to come first was a sop to
single-pass compilers, which are largely history by now.
> I dont agree with the introduction of VLAs not only because they were
> something invented by the committee and not something they took from
> common existing practice
``Common'' is a good subjective weasel work, but IIRC *every* addition
made by the C committee -- to K&R C for C89, to C95 (Amendment 1) for C89,
and to C99 for C95 -- had *some* prior art that proved its efficacy and
worth. That's better than some committees we could name.
> but also because of the reasons you have
> stated here, it's not a necessary part of the language. ie. We didn't
> need a language change to get the behaviour of alloca(), we already
> had it in most all implementations,
alloca is rather unstructured compared to VLAs, and solves a slightly
different problem.
> so why did the committee invent a
> new language instead of standardizing the existing one?
We discussed alloca more than once. Despite it's presence in several
implementations, it causes some serious implementation problems that
we didn't want to impose on all comers. More to the point, the
committee did actually consider the matter -- it wasn't just an
oversight.
> I'm
> disappointed in the vast number of people who have never read the
> committee's charter in the rationale under which it was formed.
I've read it. I even helped write it. I don't see where the committee
has abandoned that charter in recent years. (Note that I stopped
attending meetings in late 1996 and am only now resuming attendance.)
> > And? GCC will change its behavior. I agree with the noone uses it, i
> > don't care for your compiler (although i heavily use GCC/MINGW).
>
> And therefore it is not common existing practice and shouldn't be in
> the standard.
So your definition of ``common existing practice'' is what GCC does?
I know of about 100 other C compilers besides GCC. And I know some
pretty uncommon things that are just in GCC.
> > C99 is a permanent destruction of C, i agree. but you base your thoughts
> > on some compiler versions which is wrong.
>
> I base my thoughts on the failure of the committee to codify what is
> out there being used right now and playing god with the C language.
You mean the committee failed to ask your opinion and then slavishly obey
it? You should have gone to the meetings if you hoped to influence the
final result.
> > It would be great if we headed to some C++ territory or in parallel to
> > it (i would like the notion of name spaces for example). But i think we
> > headed towards Fortran & Basic.
>
> I was more refering to widely divergent implementations from the
> standard and a very small subset of the language being portable.
More subjective opinions. I personally have found C to be far and away
the most portable and powerful language available these past several
decades. And I do include Java and C++ in that assessment. That's my
subjective opinion, FWIW.
> > It can't be fixed. What is done is done, the only thing that can be done
> > is a future standard to deprecate useless things and introduce other
> > useful features.
>
> Abandon the standard. No-one is implementing it anyways.
Look around. The EDG front end has supported the full language, and
Dinkumware has supported the full library, for quite some time now.
Thanks to Comeau and other EDG customers, several platforms are now
served with fully conforming C99 implementations. More are in the
pipeline. And we are not the only source of C99 code.
> Reform the
> committee and codify what is needed.
Great! The next meeting is in Curacao week after next. Come on down
and straighten us out. Of course, if you can't find the time and
resources to attend the meetings, you lose a lot of credibility as
a critic and reformer.
> If you wanna make your own
> language call it something else (actually I know a number of people
> who have argued that is exactly what the committee did -- make a new
> language "for embedded systems" and called it c99 --
And yet remarkably, all my conforming C89 code compiles quite nicely
with a C99 compiler. And links with a C99 library.
> that arguement is
> kind of dead however, now that you cant get c89/90 anymore).
Really? Look around. And remember that a conforming C++ implementation
must include C89 + Amendment 1. I don't know of a C++ compiler that
doesn't also include a C compiler these days.
> > This is for the previous standard!
>
> Where he spells out exactly why noalias is lame and why it must not be
> "renamed" into any future standard (aka "restrict").
restrict is by no means a simple renaming of noalias. It helps to know
what you're talking about to make credible criticism.
> When our
> compilers are all c99 compliant maybe someone will try to unify the
> language and the library and his essay will come back to haunt them.
Uh, I think the language and library are already unified. Meanwhile,
the Ritchie quote you took out of context still concerns an issue
that was mooted over a dozen years ago.
> > > 3. Rationale for American National Standard for Information Systems -
> > > Programming Language - C"
> > > http://www.lysator.liu.se/c/rat/title.html
>
> Read this!
Don't have to. I wrote the first draft of it.
Micah Cowan
> "Ioannis Vranos" <noi...@no.spam.hotmail.com> wrote in message news:<a8la6c$5gk$1...@ulysses.noc.ntua.gr>...
> >
> > Basically this is the only thing i agree with C99.
> >
> > The above you criticise is the one of the few things i consider as an
> > improvement of C99.
>
> Why? Declarations mixed into code is a lame C++ practice.
Please start giving reasons, instead of generalizations. Just because
it's from C++ doesn't make it lame (prototypes, for instance...)
Instead of generalizing, list both its faults and its advantages. One
clear advantage that I like, is that it limits the variable's scope
and lifetime. Anything that limits the scope of a variable closer to
the area where you actually intend to use it, is a good thing to me.
Of course, coupond statements do it even better, limiting both the
tail end *and* the start; but too many blocks can hamper readability.
Further, it can be useful sometimes to group variables close to where
they are used, when they are only used for a brief section.
However, one disadvantage is that it can lead to sloppy, poorly
designed writing. But people who write sloppy code tend to find other
avenues of expressing that, anyway :)
> I dont agree with the introduction of VLAs not only because they were
> something invented by the committee and not something they took from
> common existing practice but also because of the reasons you have
> stated here, it's not a necessary part of the language.
There are many things not necessary to the language, but very
helpful. If you want pure simplicity without any convenience, write
in MIX.
I'll say it again: the committee has *never* constrained themselves
to "existing practice" - that's simply not the point of the language
standards committees! As you seem to disagree, I defy you to come up
with an example where IEC/ISO has merely codified a language, and not
significantly altered it.
Case in point: the version of C you're probably used to coding in.
It has prototypes, no? Well, those prototypes didn't exist in C until
ANSI decided to stick them in. I would call that a major, *major*
change. I'll bet that many people complained about these lousy "C++
carryovers" back then, too. Point is, the standard committee, whether
you like it or not, *is* charged with "innovating" the language, not
merely codifying it. They are compelled to reexamine the language
periodically, and write a new standard. If they were only existing to
codify, they would never have written anything after 1990.
> ie. We didn't need a language change to get the behaviour of
> alloca(), we already had it in most all implementations, so why did
> the committee invent a new language instead of standardizing the
> existing one? I'm disappointed in the vast number of people who
> have never read the committee's charter in the rationale under which
> it was formed.
I have read it. I don't see why you think they've failed to follow
it. I have heard you spout various things like VLAs don't "Trust
the programmer" or they haven't kept the language "small and simple",
but you haven't offered any actual evidence to back you up.
> And therefore it is not common existing practice and shouldn't be in
> the standard.
This is again non-sequitur.
> > Pre-standard common implementation extensions of some compilers don't
> > matter.
>
> Yes they do. Read the rationale.
No, they don't. From the rationale
(http://std.dkuug.dk/JTC1/SC22/WG14/www/charter), point number *one*:
1. Existing code is important, existing implementations are not.
> I base my thoughts on the failure of the committee to codify what is
> out there being used right now and playing god with the C language.
Again, they were never supposed to just codify. Go play somewhere
else.
Micah
Mark McIntyre
>Trent Waddington <q...@rtfm.insomnia.org> wrote:
>> "Ioannis Vranos" <noi...@no.spam.hotmail.com> wrote in message news:<a8la6c$5gk$1...@ulysses.noc.ntua.gr>...
>>>
>>> Basically this is the only thing i agree with C99.
>>>
>>> The above you criticise is the one of the few things i consider as an
>>> improvement of C99.
>
>> Why? Declarations mixed into code is a lame C++ practice.
>
>Your thinking it's lame doesn't really matter. With the exception of one,
>every C compiler I've used in the past 5 years supported this. And Bjarne
>was right when he said that there really is no reason any more for
>declarations to be pushed to the top of the scope. It really doesn't make
>life any harder or easier for the compiler.
No, but it sure does make life harder for the maintainer. OK, with
clever clever code editors you can right-click and jump to a
declaration or definition, but imagine trying to read the
printout.....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Ben Pfaff
Ability to declare just before first use often means that you can
easily find the declaration because it's close to where it's
used. I know I much prefer this style for writing code myself.
Another (small) advantage of intermixed statements and
declarations is that you can sometimes declare something `const'
that you otherwise could not (or would have to start a new block
to do so, or do something ugly). e.g.,
int x;
a ();
x = b (); /* x is constant after this point. */
[...]
can be written as
a ();
const int x = b ();
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield
Mark McIntyre
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> On Sat, 06 Apr 2002 18:25:39 GMT, mike burrell <mik...@shaw.ca> wrote:
>>
>> >Trent Waddington <q...@rtfm.insomnia.org> wrote:
>> >> Why? Declarations mixed into code is a lame C++ practice.
>> >
>> >declarations to be pushed to the top of the scope. It really doesn't make
>> >life any harder or easier for the compiler.
>>
>> No, but it sure does make life harder for the maintainer. OK, with
>> clever clever code editors you can right-click and jump to a
>> declaration or definition, but imagine trying to read the
>> printout.....
>
>Ability to declare just before first use often means that you can
>easily find the declaration because it's close to where it's
>used. I know I much prefer this style for writing code myself.
I disagree. IMHO it makes it much /harder/ to find. Its declared close
to where its /first/ used but it may be used time and time again.
Imagine a 1000 line function. In the "old" style, you could virtually
guarantee to find the defn at the start of the current block or at the
start of the fn. In the new style, the declaration could be anywhere
at all in the preceding 999 lines. Arg.
Don't get me wrong, I use both styles as I suspect you do too. But I
find that for production code I and my co-workers can maintain each
other's junk better if we avoid spraying declarations on every other
line...
>Another (small) advantage of intermixed statements and
>declarations is that you can sometimes declare something `const'
>that you otherwise could not (or would have to start a new block
>to do so, or do something ugly). e.g.,
> int x;
> a ();
> x = b (); /* x is constant after this point. */
> [...]
>can be written as
> a ();
> const int x = b ();
>
I confess I almost never use const anyway, so this advantage is lost
on me. I tend to regard variables as, erm, variable. if I want a
constant I create one.....
Mike Wahler
Mark McIntyre <markmc...@spamcop.net> wrote in message
news:r7puauc6dpg4mcbme...@4ax.com...
I find it makes maintenance easier. Often not as
'far' to look for the definition of a referred-to
object. Also, imo limiting scope as much as possible
is a Good Thing(tm)
$.99,
-Mike
Mike Wahler
> On 06 Apr 2002 13:22:10 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>
> >Mark McIntyre <markmc...@spamcop.net> writes:
> >
> >> On Sat, 06 Apr 2002 18:25:39 GMT, mike burrell <mik...@shaw.ca> wrote:
> >>
> >> >Trent Waddington <q...@rtfm.insomnia.org> wrote:
> >> >> Why? Declarations mixed into code is a lame C++ practice.
> >> >
> >> >declarations to be pushed to the top of the scope. It really doesn't
make
> >> >life any harder or easier for the compiler.
> >>
> >> No, but it sure does make life harder for the maintainer. OK, with
> >> clever clever code editors you can right-click and jump to a
> >> declaration or definition, but imagine trying to read the
> >> printout.....
> >
> >Ability to declare just before first use often means that you can
> >easily find the declaration because it's close to where it's
> >used. I know I much prefer this style for writing code myself.
>
> I disagree. IMHO it makes it much /harder/ to find. Its declared close
> to where its /first/ used but it may be used time and time again.
But only in the scope where it's visible. Keep your scopes
small (a good idea anyway) and no problem.
>
> Imagine a 1000 line function.
OK I'm imagining one. First thought: Break it into smaller
functions.
>In the "old" style, you could virtually
> guarantee to find the defn at the start of the current block or at the
> start of the fn. In the new style, the declaration could be anywhere
> at all in the preceding 999 lines. Arg.
Make your scopes smaller.
> Don't get me wrong, I use both styles as I suspect you do too. But I
> find that for production code I and my co-workers can maintain each
> other's junk better if we avoid spraying declarations on every other
> line...
There still must be 'order' to what you're doing. I don't think anyone
advocates abritrarily 'sprinkling' definitions in the middle of
executable code. Write the definition, followed by the code that
uses it. I also like to use blank lines to 'logically' separate
stuff, e.g.:
printf("blah blah\n");
/* etc */
printf("enter text:");
fflush(stdout);
char buffer[SIZE];
fgets(buffer, sizeof buffer, stdin);
size_t textlen = strlen(buffer);
size_t i = 0;
for(i = 0; i < textlen; ++i)
/* do something with 'buffer[i]' */
> >Another (small) advantage of intermixed statements and
> >declarations is that you can sometimes declare something `const'
> >that you otherwise could not (or would have to start a new block
> >to do so, or do something ugly). e.g.,
> > int x;
> > a ();
> > x = b (); /* x is constant after this point. */
> > [...]
> >can be written as
> > a ();
> > const int x = b ();
> >
>
> I confess I almost never use const anyway,
IMO too many C and C++ coders do not use const when they should. :-)
>so this advantage is lost
> on me. I tend to regard variables as, erm, variable.
But C does not define 'variable'. It defines 'object', which
might or might not have a 'constant' attribute ('cv-qualifier').
>if I want a
> constant I create one.....
Sure, like this:
const int MAX_ITEMS = 42;
IMO this is far superior to using a macro.
-Mike
Mike Wahler
committee's charter in the rationale under which it was formed.
[snip]
(Re: Variable length arrays)
>
> At first i think we did not need them at all. I would have liked VLAs
> if they were stored on the free store.
Can't you do this?
int n = 42;
int (*array)[n] = malloc(n * sizeof *array);
/* etc */
free(array);
[snip]
-Mike
Ben Pfaff
> On 06 Apr 2002 13:22:10 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>
[...on intermixing statements and declarations...]
> >Ability to declare just before first use often means that you can
> >easily find the declaration because it's close to where it's
> >used. I know I much prefer this style for writing code myself.
>
> I disagree. IMHO it makes it much /harder/ to find. Its declared close
> to where its /first/ used but it may be used time and time again.
>
> Imagine a 1000 line function.
Do I have to? The only reason for a 1000-line function is to
hold a single large switch statement.
> In the "old" style, you could virtually
> guarantee to find the defn at the start of the current block or at the
> start of the fn. In the new style, the declaration could be anywhere
> at all in the preceding 999 lines. Arg.
This is true. Why would you have a 1000-line function? You will
have trouble because of many things other than just placement of
declarations, especially if you try debugging from hard copy.
> Don't get me wrong, I use both styles as I suspect you do too.
I do in C++ and Java but not in C for now. I still write C code
for compatibility with C90 compilers.
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro
Eric G. Miller
> "Eric G. Miller" <eg...@jps-nospam.net> wrote in message
> news:pan.2002.04.05.23....@jps-nospam.net...
>> In <a8la6c$5gk$1...@ulysses.noc.ntua.gr>, Ioannis Vranos wrote:
>>
>
> [Useful stuff...]
>
>
>
>> >> struct foo2 {
>> >> int nbytes;
>> >> char bytes[];
>> >> };
>> >>
>> >> Who does that? Not anyone who uses gcc, it doesn't allow it [5].
>
> I didn't say that.
I accidentally snipped Trent's attribution, but the quoting should've been
clear, since everything Trent wrote had an extra '>'.
mike burrell
> Mark McIntyre <markmc...@spamcop.net> wrote in message
> news:ultuau0acr12c6j5m...@4ax.com...
>> constant I create one.....
> Sure, like this:
> const int MAX_ITEMS = 42;
> IMO this is far superior to using a macro.
Are you coming from C++? C has different semantics from C++ wrt the 'const'
keyword. In C++, I believe that 'const' actually means 'constant'?
In C, however, there are no constants (unfortunately). 'const' means
'read-only', not 'constant'. You'd be better off defining your MAX_ITEMS as
a macro if you're coding in C.
Mark McIntyre
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> On 06 Apr 2002 13:22:10 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>>
>> In the "old" style, you could virtually
>> guarantee to find the defn at the start of the current block or at the
>> start of the fn. In the new style, the declaration could be anywhere
>> at all in the preceding 999 lines. Arg.
>
>This is true. Why would you have a 1000-line function?
Because thats whats called for. Why would you use printf? or doubles?
>You will
>have trouble because of many things other than just placement of
>declarations, especially if you try debugging from hard copy.
Sure. sometimes thats what you have to do.
Ben Pfaff
> On 06 Apr 2002 15:09:15 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>
> >Mark McIntyre <markmc...@spamcop.net> writes:
> >
> >> On 06 Apr 2002 13:22:10 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
> >>
> >> In the "old" style, you could virtually
> >> guarantee to find the defn at the start of the current block or at the
> >> start of the fn. In the new style, the declaration could be anywhere
> >> at all in the preceding 999 lines. Arg.
> >
> >This is true. Why would you have a 1000-line function?
>
> Because thats whats called for.
Funny that I never seem to run into these situations.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield
MShe...@compuserve.com
wrote:
[snip]
>Why? Declarations mixed into code is a lame C++ practice.
[snip]
First, declarations *are* code. Second, C has supported block scope
for ages. Third, putting declaration immediately before first use
reduces both the scope and the lifetime of variables, generally
considered a Good Thing. Fourth, other languages supported this
practice before C++ existed.
Heck, even *I* know that, and the regular posters here would consider
me unbearably lame as a C programmer.
--
Mike Sherrill
Information Management Systems
Trent Waddington
> Of course, coupond statements do it even better, limiting both the
> tail end *and* the start; but too many blocks can hamper readability.
That is why it is lame, you already know, dont act dumb. If you have
too many blocks put some of them in a new function.
> I'll say it again: the committee has *never* constrained themselves
> to "existing practice" - that's simply not the point of the language
> standards committees! As you seem to disagree, I defy you to come up
> with an example where IEC/ISO has merely codified a language, and not
> significantly altered it.
>
> [irrational arguement removed]
>
> I have read it. I don't see why you think they've failed to follow
> it. I have heard you spout various things like VLAs don't "Trust
> the programmer" or they haven't kept the language "small and simple",
> but you haven't offered any actual evidence to back you up.
Go and read it again. In particular read the entirety of section 1.1
"Purpose" and the first paragraph of section 1.2 "Scope":
This Rationale focuses primarily on additions, clarifications, and
changes made to the language as described in the Base Documents (see
§1.5). It is not a rationale for the C language as a whole: __the
Committee was charged with codifying an existing language, not
designing a new one.__ No attempt is made in this Rationale to defend
the pre-existing syntax of the language, such as the syntax of
declarations or the binding of operators. [emphasis added].
So it is not a question of how the committee has "constrained" itself
in the past. It is a question of what _right_ the committee has to
hack and slash at the C language.
> No, they don't. From the rationale
> (http://std.dkuug.dk/JTC1/SC22/WG14/www/charter), point number *one*:
>
> 1. Existing code is important, existing implementations are not.
And tell me, what is the existing code going to be based upon?
> Again, they were never supposed to just codify. Go play somewhere
> else.
See above.
Trent Waddington
those who know me have no need of my name
>There are some more interesting things which really do seem to have come out
>of thin air (or so it seems):
>- universal characters
this is just an extension of work started long ago, which resulted in the
first of the `wide character' support in amr1. consider what is needed to
provide a "string constant" in a program that intends to use wchar_t.
without L"" you have to use a (static but non-const) buffer and swprintf --
ungainly at best, and near impossible if the string contains multi-lingual
text.
--
bringing you boring signatures for 17 years
Dan Pop
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> On Sat, 06 Apr 2002 18:25:39 GMT, mike burrell <mik...@shaw.ca> wrote:
>>
>> >Trent Waddington <q...@rtfm.insomnia.org> wrote:
>> >> Why? Declarations mixed into code is a lame C++ practice.
>> >
>> >Your thinking it's lame doesn't really matter. With the exception of one,
>> >every C compiler I've used in the past 5 years supported this. And Bjarne
>> >was right when he said that there really is no reason any more for
>> >declarations to be pushed to the top of the scope. It really doesn't make
>> >life any harder or easier for the compiler.
>>
>> No, but it sure does make life harder for the maintainer. OK, with
>> clever clever code editors you can right-click and jump to a
>> declaration or definition, but imagine trying to read the
>> printout.....
>
>Ability to declare just before first use often means that you can
>easily find the declaration because it's close to where it's
>used.
It's close to where it's *first* used! If you're looking at its third
usage and want to see its exact declaration, it's much easier to find
it at the beginning of the function than close to its first usage (since
there is no easy way to figure out where the latter might be).
>I know I much prefer this style for writing code myself.
I don't, with the exception of for loop counters declared in the for
statement, which are not affected by the above mentioned problem.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> On 06 Apr 2002 15:09:15 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>>
>> >Mark McIntyre <markmc...@spamcop.net> writes:
>> >
>> >> On 06 Apr 2002 13:22:10 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>> >>
>> >> In the "old" style, you could virtually
>> >> guarantee to find the defn at the start of the current block or at the
>> >> start of the fn. In the new style, the declaration could be anywhere
>> >> at all in the preceding 999 lines. Arg.
>> >
>> >This is true. Why would you have a 1000-line function?
>>
>> Because thats whats called for.
>
>Funny that I never seem to run into these situations.
One day, you might have to maintain code written by other people.
Among plenty of other nasty things, you will encounter monster functions.
Richard Bos
> Mark McIntyre <markmc...@spamcop.net> writes:
>
> > No, but it sure does make life harder for the maintainer. OK, with
> > clever clever code editors you can right-click and jump to a
> > declaration or definition, but imagine trying to read the
> > printout.....
>
> Ability to declare just before first use often means that you can
> easily find the declaration because it's close to where it's
> used.
That's in theory. In practice, IMO it doesn't usually work that way.
With all declarations at the top of the function, you always know where
to look. With declarations spread out through the function, you have to
look everywhere, because most variables aren't exactly used for five
lines only, and not everybody has your idea of what is an elegant
declaration order. But de gustibus, &c.
Richard
Dave
>>"renamed" into any future standard (aka "restrict"). When our
>>compilers are all c99 compliant maybe someone will try to unify the
>>language and the library and his essay will come back to haunt them.
>
> restrict is not "aka" noalias. They have differing semantics. Indeed the
> things they did to make restrict were seemingly done in direct response to
> his criticisms. Every one of the specific problems he raised have been
> fixed. This is *not* a renaming.
I can sort of understand his [Trent] reasoning with restrict : He is
attempting to say that he feels that the compiler should be able to do
the job that the programmer is performing - alias analysis. However,
for the compiler to perform inter-procedural alias analysis, including
within libraries and across multiple files, seems an insurmountable
problem and one which I believe is perfectly valid to ask the programmer
to help with.
I for one have written code where I know that I am limiting the pointers
to non-aliased arguments, and being able to specify this to the compiler
can generate greatly improved code without the need for the compiler to
perform a vast amount of work just to avoid a little programmer
understanding of how they are using their own pointers.
David Gardner
Ben Pfaff
> In <876633n...@pfaff.Stanford.EDU> Ben Pfaff <b...@cs.stanford.edu> writes:
>
> >Mark McIntyre <markmc...@spamcop.net> writes:
> >
> >> On 06 Apr 2002 15:09:15 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
> >>
> >> >Mark McIntyre <markmc...@spamcop.net> writes:
> >> >
> >> >This is true. Why would you have a 1000-line function?
> >>
> >> Because thats whats called for.
> >
> >Funny that I never seem to run into these situations.
>
> One day, you might have to maintain code written by other people.
These days I spend more time working on code originally written
by others than on my own. A lot of this code is in Java, which
allows declarations intermixed with statements, but this problem
is not one I've run into.
> Among plenty of other nasty things, you will encounter monster functions.
Me and my text editor's "search" function are good friends,
thanks.
Mark McIntyre
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> On 06 Apr 2002 15:09:15 -0800, Ben Pfaff <b...@cs.stanford.edu> wrote:
>>
>> >This is true. Why would you have a 1000-line function?
>>
>> Because thats whats called for.
>
>Funny that I never seem to run into these situations.
Lucky you. First commercial project I worked on had one function that
ran to about 2000 lines. Part of a highly successful million-dollar
financial package.
It cried out to be rewritten and split. But performance was optimised
in that format - the overhead of calling functions was too great given
the quantity of data that would have to be exchanged and the way the
big fn itself was used, and and globals were out for various good
reasons.
Mark McIntyre
>Dan...@ifh.de (Dan Pop) writes:
>
>
>> Among plenty of other nasty things, you will encounter monster functions.
>
>Me and my text editor's "search" function are good friends,
>thanks.
And a lot of patience. The monster fn I encountered had some variables
which got used hundreds of times. Plus the OPs had a tendency to reuse
variable names and fn names
int somefn(somelonglist of params)
{
int somevar;
// 2000 lines of code using somevar every 20 or so
}
int somefn2(samelonglist of params)
{
int somevar;
// 2000 lines of code using somevar every 20 or so
CBFalconer
> Ben Pfaff <b...@cs.stanford.edu> wrote:
> >Dan...@ifh.de (Dan Pop) writes:
> >
> >> Among plenty of other nasty things, you will encounter monster
> >>functions.
> >
> >Me and my text editor's "search" function are good friends,
> >thanks.
>
> And a lot of patience. The monster fn I encountered had some
> variables which got used hundreds of times. Plus the OPs had a
> tendency to reuse variable names and fn names
>
> int somefn(somelonglist of params)
> {
> int somevar;
>
> // 2000 lines of code using somevar every 20 or so
> }
>
> int somefn2(samelonglist of params)
> {
> int somevar;
> // 2000 lines of code using somevar every 20 or so
> }
So you do whatever is needed to mark the block holding somefn2,
and issue whatever editor command changes "somevar" into
"someothervar". After a few sessions like this you do an XREF.
You can go a long way without changing anything in the program to
convert it into some semblance of legibility.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
> Ben Pfaff <b...@cs.stanford.edu> wrote:
> >Mark McIntyre <markmc...@spamcop.net> writes:
> >> Ben Pfaff <b...@cs.stanford.edu> wrote:
> >>
> >> >This is true. Why would you have a 1000-line function?
> >>
> >> Because thats whats called for.
> >
> >Funny that I never seem to run into these situations.
>
> Lucky you. First commercial project I worked on had one function that
> ran to about 2000 lines. Part of a highly successful million-dollar
> financial package.
>
> It cried out to be rewritten and split. But performance was optimised
> in that format - the overhead of calling functions was too great given
> the quantity of data that would have to be exchanged and the way the
> big fn itself was used, and and globals were out for various good
> reasons.
I don't believe it, unless you are trying to convert every line
into a function. Start with the innermost loop of a nested loop.
Look for similar groupings - dumb programmers love to copy chunks
of working code verbatim. IIRC Cobol even has a construct to
automate this silly practice, much like massive misuse of a C
macro.
Richard Heathfield
>
> Mark McIntyre wrote:
> > Ben Pfaff <b...@cs.stanford.edu> wrote:
> > >Mark McIntyre <markmc...@spamcop.net> writes:
> > >> Ben Pfaff <b...@cs.stanford.edu> wrote:
> > >>
> > >> >This is true. Why would you have a 1000-line function?
> > >>
> > >> Because thats whats called for.
> > >
> > >Funny that I never seem to run into these situations.
> >
> > Lucky you. First commercial project I worked on had one function that
> > ran to about 2000 lines. Part of a highly successful million-dollar
> > financial package.
> >
> > It cried out to be rewritten and split. But performance was optimised
> > in that format - the overhead of calling functions was too great given
> > the quantity of data that would have to be exchanged and the way the
> > big fn itself was used, and and globals were out for various good
> > reasons.
>
> I don't believe it,
I half-believe it. Three reasonable possibilities exist:
(1) Mark is telling a lie.
(2) Mark is mistaken.
(3) Mark is correct.
I disregard (1) as being implausible, based on Mark's posting history.
I am tempted by (2), because none of us is perfect, and because it's
easy to forget what we didn't know. Mark is almost certainly talking
about something that happened a decade or more ago ("First commercial
project I worked on"), when he knew a lot less about C than he does now,
and he may have been overly influenced by the statements of his
co-workers about the importance of leaving this routine alone, and
overly gullible about the reasons for it. It is sometimes difficult to
overcome one's recollections of such matters even with improved
technical knowledge and hindsight.
Of course, (3) remains a possibility. But of course, if the function was
so close to being unusable on performance grounds that it /had/ to
remain 2000 lines long to reduce function call overhead, it *still*
needed re-writing.
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Dan Pop
>Dan...@ifh.de (Dan Pop) writes:
>
>> Among plenty of other nasty things, you will encounter monster functions.
>
>Me and my text editor's "search" function are good friends,
>thanks.
If the variable's name is short enough (e.g. one letter), your friend
isn't likely to be able to provide much help.
Mark McIntyre
wrote:
>So you do whatever is needed to mark the block holding somefn2,
>and issue whatever editor command changes "somevar" into
>"someothervar". After a few sessions like this you do an XREF.
>You can go a long way without changing anything in the program to
>convert it into some semblance of legibility.
Remind me how you do this under Netware 2.11.
(sorry, I forgot to mention the context)
Mark McIntyre
<bin...@eton.powernet.co.uk> wrote:
>CBFalconer wrote:
>>
>>
>> I don't believe it,
>
>I half-believe it. Three reasonable possibilities exist:
>
>(1) Mark is telling a lie.
>(2) Mark is mistaken.
>(3) Mark is correct.
The fn was one to calculate interest rate derivaties yield curves
using a bunch of quite complex maths models and display them on
screen, based on data extracted from a nonrelational database. It
contained a mixture of the maths, routines to access the database (a
pre-sql system), and routines to write to the screen using something
called PANEL, a kind of DOS windowing system. The app ran under DOS
protected mode using Watcom C and MSC 5.1, and occasionally popped
back into real mode to access the dongle and to draw graphics. This
made visual debugging impossible and so we used the good old printf
method (somewhat systemised by a bunch of NDEBUGgable macros).
Everything was horribly intertwined with everything else, block scope
variables masking other variables, duplicate variable names used in
adjacent blocks, blocks which were nearly identical to other blocks
etc ec etc.
Absolutely. This fn needed a total rewrite. It had grown up over
several years and was horrible. However it was also one of the most
frequently accessed fns, and every attempt to rewrite it resulted in a
massive,slow mess, because to get data from real to protected mode, or
to out of the db, or into panel, required buckets of extra variables
for every new fn call.
In the end the company "solved" the problem by migrating to Windows
and rewriting from scratch.
Richard Bos
> On Tue, 09 Apr 2002 00:47:52 GMT, CBFalconer <cbfal...@yahoo.com>
> wrote:
>
> >So you do whatever is needed to mark the block holding somefn2,
> >and issue whatever editor command changes "somevar" into
> >"someothervar". After a few sessions like this you do an XREF.
> >You can go a long way without changing anything in the program to
> >convert it into some semblance of legibility.
>
> Remind me how you do this under Netware 2.11.
Non sequitur - Netware is a networking OS, not a source code editor.
Richard
Mark McIntyre
No, not a NS. The challenge is to find a non-freeware* editor
compatible with a Netware2.11 network that can do that. **
* because commercial companies rarely allow the use of freeware.
** I guess we could have used wordstar.....
Wayne W. Cheng
>The response from programmers has been mild shock to total outrage.
>c99 violates the spirit of C. VLAs don't trust the programmer. The
>restrict keyword (although useful for vectorization) prevents the
>programmer from doing what needs to be done. Introducing complex and
>imaginary numbers is not keeping the language small and simple.
In my opinion, the C standard committee has followed
its charter and guiding principles for revision of C99 fairly
consistently with one exception. One of its guiding principles
is to "Codify existing practice to address evident deficiencies."
Almost all features in C99, except features
in Annex G of C99, were added carefully with the prior art
and existing implementations. Most of numerical features in C99
including VLAs, complex numbers, and IEEE floating-point arithmetic
were added mainly based on the prior art and existing practice of
Ch (a superset of C interpreter), gcc, and Cray's SCC.
Ch supports most C99 features including VLAs, complex numbers,
IEEE floating-point arithmetics, generic functions,
mixed executable and declaration statements, binary constants,
function name __func__, and even classes in C++ that
the C standard committee once attempted to add in C99.
As I pointed out in my recent article in Dr. Dobb's Journal in March, 2002,
imaginary types in informative Annex G in C99 were added in C99
without an existing practice. More information can be found at
http://www.softintegration.com/docs/whitepaper/
Numerical features in Annex G were pure invention by the committee.
They contradict with conventional mathematics and are dangerous
for applications in engineering and science.
Unfortunately, I was not able to convince the committee to
delete Annex G completely from C99. Fortunately, the informative
Annex G is neither normative nor mandated in C99.
A C99 conforming implementation is not required
to implement it.
Harry H. Cheng
Ch -- a superset of C interpreter
http://www.softintegration.com
Harry H. Cheng
>> nor in practice.
>Afaik, GCC has had them for a long time, even before C99 (but with
>somewhat different semantics, I believe).
Implementation for VLA extensions to C has been done
seven years ago in my eariler development of Ch. I have
published a paper with title "Extending C with Arrays of Variable Length
" in Computer Standards and Interfaces in 1995.
Most of numerical features in C99
including VLAs, complex numbers, and IEEE floating-point arithmetic were
added mainly based on the prior art and
existing practice of Ch (a superset of C interpreter), gcc,
and Cray's SCC.
You can find more at
http://www.softintegration.com/docs/whitepaper/
Ioannis Vranos
news:3CC32DFC...@softintegration.com...
>
>Most of numerical features in C99
> including VLAs, complex numbers, and IEEE floating-point arithmetic
> were added mainly based on the prior art and existing practice of
> Ch (a superset of C interpreter), gcc, and Cray's SCC.
> Ch supports most C99 features including VLAs, complex numbers,
> IEEE floating-point arithmetics, generic functions,
> mixed executable and declaration statements, binary constants,
> function name __func__, and even classes in C++ that
> the C standard committee once attempted to add in C99.
Then the standard should be for Ch, not C. C is not (at least it was not
and should be not) a programming language for numerical computing. C
should be a GENERAL PURPOSE PROGRAMMING LANGUAGE. Everything else could
be solved using system extensions and efficient libraries.
Anyway, now it is too late.
--
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys
Ioannis Vranos
news:3CC330D8...@softintegration.com...
>
> Implementation for VLA extensions to C has been done
> seven years ago in my eariler development of Ch. I have
> published a paper with title "Extending C with Arrays of Variable
Length
> " in Computer Standards and Interfaces in 1995.
>
> Most of numerical features in C99
> including VLAs, complex numbers, and IEEE floating-point arithmetic
were
> added mainly based on the prior art and
> existing practice of Ch (a superset of C interpreter), gcc,
> and Cray's SCC.
>
> You can find more at
> http://www.softintegration.com/docs/whitepaper/
>
>
> Harry H. Cheng
>
> Ch -- a superset of C interpreter
> http://www.softintegration.com
I do not know Ch and it may be great, but C should not be Ch or Java or
Fortran.
Ioannis Vranos
news:a9vklq$1l5o$1...@ulysses.noc.ntua.gr...
> "Wayne W. Cheng" <wch...@softintegration.com> wrote in message
> news:3CC32DFC...@softintegration.com...
> >
> >Most of numerical features in C99
> > including VLAs, complex numbers, and IEEE floating-point arithmetic
> > were added mainly based on the prior art and existing practice of
> > Ch (a superset of C interpreter), gcc, and Cray's SCC.
> > Ch supports most C99 features including VLAs, complex numbers,
> > IEEE floating-point arithmetics, generic functions,
> > mixed executable and declaration statements, binary constants,
> > function name __func__, and even classes in C++ that
> > the C standard committee once attempted to add in C99.
>
> Then the standard should be for Ch, not C. C is not (at least it was
not
> and should be not) a programming language for numerical computing. C
> should be a GENERAL PURPOSE PROGRAMMING LANGUAGE. Everything else
could
> be solved using system extensions and efficient libraries.
Or use some other language which is made specifically for that
purpose.There should be no rush to add some specific non-general-purpose
features in the language.
Harry H. Cheng
Ioannis Vranos wrote:
> "Harry H. Cheng" <harry_...@softintegration.com> wrote in message
> news:3CC330D8...@softintegration.com...
> >
> > Implementation for VLA extensions to C has been done
> > seven years ago in my eariler development of Ch. I have
> > published a paper with title "Extending C with Arrays of Variable
> Length
> > " in Computer Standards and Interfaces in 1995.
> >
> > Most of numerical features in C99
> > including VLAs, complex numbers, and IEEE floating-point arithmetic
> were
> > added mainly based on the prior art and
> > existing practice of Ch (a superset of C interpreter), gcc,
> > and Cray's SCC.
> >
> > You can find more at
> > http://www.softintegration.com/docs/whitepaper/
> >
> >
> > Harry H. Cheng
> >
> > Ch -- a superset of C interpreter
> > http://www.softintegration.com
>
> I do not know Ch and it may be great, but C should not be Ch or Java or
> Fortran.
>
Agreed. gcc is a C compiler for different platforms.
VC++ is a C/C++ compiler for Windows.
SCC is a C compiler for Cray machine.
Ch is an embeddable C interpreter for different platforms.
They use different names and have different extensions to C.
However, they all conform to the ISO C90 standard.
I think they will conform to C99 eventually.
Regards,
Harry H. Cheng