Next ISO C standard - any features being removed?
Marco
not being universally implemented in most current C compilers and make
them an optional feature or deprecate them.
An example is variable length arrays
Any other items?
Motivation:
I feel that standards should capture reality and also encourage good
and safe programming practices.
I would like to see more compilers move to standard conformance so we
are aren't stuck at C89/90 forever.
A carrot versus a stick approach is best. The compiler must give a
warning for non-conforming new standard Cxx code which is acceptable
C89/90 code.
James Kuyper
> Maybe the ISO needs to reconsider some of the C99 features that are
> not being universally implemented in most current C compilers and make
> them an optional feature or deprecate them.
I think that optional features are, in general, a bad idea for language
standards. The point of a standard is to allow you to write code that
depends upon support for all the features specified by the standard. You
shouldn't have to fill your code with feature-test macros to make use of
those features. Alternatively, you could simply not use the feature -
but it that case, why bother including it in the standard at all.
Yes, we do currently have a few optional features in C; I think they
were a mistake, and I think that it's a good idea to avoid repeating
that mistake.
It's much better for a compiler to be optionally-conforming: the
compiler can have one mode in which it conforms (which need not be, and
usually is not, the default mode), but the user if free to make it
non-conforming by turning off support for a given feature.
> An example is variable length arrays
Variable length arrays (VLAs) are one of the C99 features I'm most
looking forward to making use of, as soon as our contract allows us to
deliver code that requires use of a C99 compiler. I've made use of them
in some of our non-delivered code, and they make working with
multidimensional arrays a lot easier.
VLAs are also one of the more widely implemented features; while gcc's
main remaining areas of non-conformance involve VLAs, it fails to
conform only in some unspecified (as far as I can discover) but
presumably fairly subtle way; the basics of VLAs all seem to be
implemented. You might be able to argue for modification of the standard
VLAs to match common existing practice, but first you'd have identify
what that common existing practice is - do other popular compilers fail
to implement VLAs correctly in precisely the same way that gcc does? I
doubt it.
Therefore, removing VLAs is not really a viable option (and the whole
point of deprecation is to give advance warning of an intention to
remove the feature).
Giacomo Catenazzi
> Marco wrote:
>> Maybe the ISO needs to reconsider some of the C99 features that are
>> not being universally implemented in most current C compilers and make
>> them an optional feature or deprecate them.
>
> I think that optional features are, in general, a bad idea for language
> standards. The point of a standard is to allow you to write code that
> depends upon support for all the features specified by the standard. You
> shouldn't have to fill your code with feature-test macros to make use of
> those features. Alternatively, you could simply not use the feature -
> but it that case, why bother including it in the standard at all.
>
> Yes, we do currently have a few optional features in C; I think they
> were a mistake, and I think that it's a good idea to avoid repeating
> that mistake.
>
> It's much better for a compiler to be optionally-conforming: the
> compiler can have one mode in which it conforms (which need not be, and
> usually is not, the default mode), but the user if free to make it
> non-conforming by turning off support for a given feature.
I don't agree.
C is an "universal language", and nearly all CPU could run C programs
most efficiently, but for few features of standard.
I think this give C an inevitable disadvantages: the standard is
in many part to permissive/weak (which is IMO non-optimal).
E.g. take floating point, math library and complex numbers:
For C programmers the standard C means nearly nothing: they must
rely on quality of implementation (which is not standardized
in any other ISO standard, AFAIK).
IMHO the VLA is analogue.
I don't expect preprocessor tests, but a programmer that
look for "universality" will not use "deep" floats and any
VLA (they will be probably slow on some CPU).
OTOH most C programmers expects a modern CPU, and they will require
a compiler that provides standard C1x + standard VLA (and maybe standard
full-float).
I think that we could have the two targets: "universality" and
"expectation quality" only by using more and more the optional features.
ciao
cate
Francis Glassborow
?? Yet you want optional features.
>
> E.g. take floating point, math library and complex numbers:
> For C programmers the standard C means nearly nothing: they must
> rely on quality of implementation (which is not standardized
> in any other ISO standard, AFAIK).
QoI is an issue with every programming language I have ever studied.
>
> IMHO the VLA is analogue.
I am sure that is not what you meant to write but I do not know what you
did.
>
> I don't expect preprocessor tests, but a programmer that
> look for "universality" will not use "deep" floats and any
> VLA (they will be probably slow on some CPU).
> OTOH most C programmers expects a modern CPU, and they will require
> a compiler that provides standard C1x + standard VLA (and maybe standard
> full-float).
>
> I think that we could have the two targets: "universality" and
> "expectation quality" only by using more and more the optional features.
Universality and optional features do not mesh. In addition, what do you
mean by 'full float'? C is widely used for writing code for embedded
systems and has proved to be a wonderfully successful language both for
that and as a destination for translating other computing languages.
That is important because it means that other languages can be quickly
transported to any platforms for which there is a standard C compiler.
Whilst I would not want to use VLAs I think they are fine for C and
implemented existing practice. They formalise much that was being done
already as extensions by various compilers. There is no reason to make
something optional because its implementation will be slow on some
platforms. That might be a reason for not using it in code that was
targeted at those platforms or that needed to be highly portable and
have a good performance.
>
> ciao
> cate
>
--
Note that robinton.demon.co.uk addresses are no longer valid.
jacob navia
> Maybe the ISO needs to reconsider some of the C99 features that are
> not being universally implemented in most current C compilers and make
> them an optional feature or deprecate them.
>
> An example is variable length arrays
>
> Any other items?
>
I do not think that removing complex numbers is a good idea but I
would replace the complex number feature with a feature that allows
users to define their own numbers, i.e. operator overloading.
Right now C has an enormous variety of number types (around 15
last count, maybe much more if you count complex and imaginary in
their 3 sizes each...)
Besides those, we have proposals to use decimal floating point to do exact
calculations in accounting environments, and fixed point "floats" that
would allow to use nteger hardware to do floating point, a feature
needed in some embedded systems.
Many will miss bignums and higher precision floats, 128 bit integers,
and what have you.
This is a needed feature of the language that would have the advantage
of SIMPLIFYING the language, since complex numbers would disappear
as such and be replaced by complex numbers that could be implemented
by the user. A default implementation should be provided, that would
use operator overloading to implement C99 complex types.
I have proposed this since a long time, and the more we advance in time,
the more that this solution makes itself evident. Many lnguages propose
operator overloading, from the venerable FORTRAN to C# C++ and many
others.
I think we should do the same, following C++ as closely as possible.
For an implementation of this ideas see:
lcc-win
Kenneth 'Bessarion' Boyd
> .....
>
> Many lnguages propose
> operator overloading, from the venerable FORTRAN to C# C++ and many
> others.
Which is not, by itself, a rationale either way for or against user
operator overloading in C.
One thing that jumps out at me *repeatedly* (as I take on the
Sisyphean task of writing a C and C++ compiler in parallel from
scratch) is how often C90 and C99 takes the approach whose effort to
write an implementation from scratch is minimal. It looks like C is
optimized for getting to a self-hosting free-standing implementation
with very minimal man-hours of programming. With very few exceptions,
the language features in a free-standing implementation are very
efficient to implement for the expressiveness they provide.
As far as I can tell, (user) operator overloading, like function
overloading, just gets in the way of getting a C language
implementation to the self-hosting point. I'd need convincing to
think that a C1X with operator overloading would be a close relative
of C99.
jacob navia
> On Dec 7, 2:00 pm, jacob navia <ja...@nospam.org> wrote:
>
>> .....
>>
>> Many lnguages propose
>> operator overloading, from the venerable FORTRAN to C# C++ and many
>> others.
>
> Which is not, by itself, a rationale either way for or against user
> operator overloading in C.
>
After snipping away all the other arguments that I wrote in my
message, obviously you are right...
:-)
I repeat them here in case you missed them:
(1) The complex numbers implementation makes thye language heavier.
(2) There are at least two technical reports that I have read in this forum
proposing 2 new kinds of numbers: fixed point and decimal floating point.
(3) The language would be smaller (and easier to implement) if complex
numbers would be replaced by a general language feature that allows
the user to implement ANY kind of numbers.
> One thing that jumps out at me *repeatedly* (as I take on the
> Sisyphean task of writing a C and C++ compiler in parallel from
> scratch)
More about your project later...
> is how often C90 and C99 takes the approach whose effort to
> write an implementation from scratch is minimal. It looks like C is
> optimized for getting to a self-hosting free-standing implementation
> with very minimal man-hours of programming. With very few exceptions,
> the language features in a free-standing implementation are very
> efficient to implement for the expressiveness they provide.
>
> As far as I can tell, (user) operator overloading, like function
> overloading, just gets in the way of getting a C language
> implementation to the self-hosting point. I'd need convincing to
> think that a C1X with operator overloading would be a close relative
> of C99.
If you mean by self hosting an implementation that compiles itself,
lcc-win compiles itself. The code of the operator overloading part
in my compiler is around 2000 lines of code. That is quite small
and is very easy to implement.
Since you say yoy are writing a compiler I will explain it in more
detail:
The entry points are obvious. "Subclass" the errors that you issue
when an operator is used with a user defined structure.
MyStruct a,b,c;
// ...
c=a+b;
Now, you issue a syntax error. Before issuing the syntax error, test if
the operator has been overloaded. If yes, call the appropiate function.
Very easy.
The syntax I use is:
Result_Type operator+(Type1 argument1, Type2 argument2);
I am considering using
Result_Type operator+(Type1 argument1, Type2 argument2) = SomeFn;
To specify that SomeFn (already defined) would be the new operator.
Instead of writing
ResultType operator+(Type1 arg1,Type2 arg2)
{
return SomeFn(arg1,arg2);
}
The above syntax would allow to specify it immediately.
----------------------------------------------------------------
It is nice to try to implement a compiler from scratch but
why not use the work done by other people already?
It would be interesting to know more about your project
jacob
jacob at jacob dot remcomp dot fr
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd a écrit :
>
> > On Dec 7, 2:00 pm, jacob navia <ja...@nospam.org> wrote:
>
> >> .....
>
> >> Many lnguages propose
> >> operator overloading, from the venerable FORTRAN to C# C++ and many
> >> others.
>
> > Which is not, by itself, a rationale either way for or against user
> > operator overloading in C.
>
> After snipping away all the other arguments that I wrote in my
> message, obviously you are right...
>
> :-)
>
> I repeat them here in case you missed them:
>
> (1) The complex numbers implementation makes thye language heavier.
> (2) There are at least two technical reports that I have read in this forum
> proposing 2 new kinds of numbers: fixed point and decimal floating point.
Ok. It is particularly noxious that not all published ABIs consider
complex numbers and their naively equivalent structs the same for
parameter-passing purposes, but that is not a C standard issue.
> (3) The language would be smaller (and easier to implement) if complex
> numbers would be replaced by a general language feature that allows
> the user to implement ANY kind of numbers.
Hmm....ok, reasonable wish. It would be very nice if the C standards
required provided some way of exactly reporting the format of its
integer and floating point types in-language. (I'm already hitting
some problems here -- it would be very nice to know exactly how many
padding bits are in an int, for instance. I probably can extract that
much at compile-time with a little help from a configuration program,
but *where* the padding bits are if present is another question
entirely.)
And of course, that general language feature would need some kind of
operator overloading. That's an interesting tradeoff to consider.
> ....
>
> If you mean by self hosting an implementation that compiles itself,
> lcc-win compiles itself.
Yes, that's what I mean by self-hosting.
> The code of the operator overloading part
> in my compiler is around 2000 lines of code. That is quite small
> and is very easy to implement.
Ok. [Eliding explanation...will read it more carefully later.]
> It is nice to try to implement a compiler from scratch but
> why not use the work done by other people already?
To be honest, I haven't played intensively with lcc-win yet so I don't
know how easy it is to bootstrap and test on Windows.
I do not wish to contribute to (open-source) compilers that I cannot
do a native bootstrap and native testsuite of. That rules out GCC
(does not native-bootstrap MingW32 easily -- latest try was GCC 4.3.3,
might be worth retrying if I could take a full day off safely) and
CLang (LLVM builds fine, but not really testable until the DejaGNU
test framework is bypassable.)
> It would be interesting to know more about your project
The project page for Z.C++ is at http://developer.berlios.de/projects/zcplusplus
. It's MIT-licensed (I have no problem if the code is reused even in
closed-source commercial projects). The earliest release that should
have a fully compliant standalone preprocessor (z_cpp), aside from
holes in the standard library, is 0.0.2. As far as actually compiling
programs, it's vaporware at the moment. I'm targeting a late December
2009 release date for Z.C++ 0.0.3 (still vaporware for compiling
programs, but will do very simple parsing). The main new feature of
interest for 0.0.3 will be static assertions from C1X. I had to abort
fully parsing enumerators due to backend architectural issues (and an
unscheduled month-long hiatus in development).
At the moment:
* The preprocessor automatically generates stddef.h, stdint.h, and
limits.h based on what target it is preprocessing for (and has been
doing so since 0.0.1). The target properties are controllable with
command-line options. At such time as float.h and related headers go
in, they too will be automatically generated with target properties
controllable at the command line. My general intent is that cross-
preprocessing and cross-compilation should be easy.
* I also implemented an extension pragma to enforce the undefined
behavior of defining of reserved identifiers as an error. C keywords
use similar machinery, but have to be special-cased as the undefined
behavior only applies if the macro exists at the time a standard
header is included.
* The most severe portability problem it has, is that it requires
MingW32 to build. [I reused a reimplementation of C malloc/realloc/
calloc/free, from a math AI I worked on for a while, that is Windows-
specific.] The deadline for ISO build mode keeps slipping, although I
do make incremental progress towards it with each release.
Marco
>
> > An example is variable length arrays
>
> VLAs are also one of the more widely implemented features; while gcc's
> main remaining areas of non-conformance involve VLAs, it fails to
> conform only in some unspecified (as far as I can discover) but
> presumably fairly subtle way; the basics of VLAs all seem to be
> implemented. You might be able to argue for modification of the standard
> VLAs to match common existing practice, but first you'd have identify
> what that common existing practice is - do other popular compilers fail
> to implement VLAs correctly in precisely the same way that gcc does? I
> doubt it.
How many C compilers for embedded targets implement VLAs? Not many.
Does Microsoft implement it yet? not sure.
I would say 10 years out that it is not meeting the intent of having
a language standard.
I think VLA is featuritis for C. This is a good feature for other
more higher order languages.
If C90 was this poorly adopted and implemented then that standard
would have been meaningless.
Francis Glassborow
> On Dec 6, 7:38 am, James Kuyper <jameskuy...@verizon.net> wrote:
>
>>> An example is variable length arrays
>> VLAs are also one of the more widely implemented features; while gcc's
>> main remaining areas of non-conformance involve VLAs, it fails to
>> conform only in some unspecified (as far as I can discover) but
>> presumably fairly subtle way; the basics of VLAs all seem to be
>> implemented. You might be able to argue for modification of the standard
>> VLAs to match common existing practice, but first you'd have identify
>> what that common existing practice is - do other popular compilers fail
>> to implement VLAs correctly in precisely the same way that gcc does? I
>> doubt it.
>
> How many C compilers for embedded targets implement VLAs? Not many.
> Does Microsoft implement it yet? not sure.
Actually, how many compilers targeting embedded hardware conform to a C
Standard (any one, let alone the latest)
>
> I would say 10 years out that it is not meeting the intent of having
> a language standard.
> I think VLA is featuritis for C. This is a good feature for other
> more higher order languages.
>
> If C90 was this poorly adopted and implemented then that standard
> would have been meaningless.
--
Dag-Erling Smørgrav
> How many C compilers for embedded targets implement VLAs? Not many.
> Does Microsoft implement it yet? not sure.
Microsoft does not implement any part of C99. This is well known to
anyone who has ever tried to write software that will run on both
Windows and *nix, or to port *nix software to Windows. The most
commonly encountered problem is the lack of long long and intN_t, and to
a smaller degree (since they're less commonly used) intmax_t and the new
printf() format specifiers (%z, %j).
Luckily, there are native ports of the GNU compiler collection. There's
no fix for the printf() issue, though.
> I think VLA is featuritis for C. This is a good feature for other
> more higher order languages.
VLAs are a formalization of a trick that was widely used (e.g. in
protocol stacks) for years before C99. The only differences are that
you write a[] instead of a[1] (or a[0] if your compiler supported it),
and that there are (highly sensible) restrictions on what you're allowed
to do with a struct that ends with a VLA.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> Actually, how many compilers targeting embedded hardware conform to a
> C Standard (any one, let alone the latest)
In many if not most cases these days, "compilers targeting embedded
hardware" means "the GNU compiler collection", which admittedly does not
conform to any C standard, but at least it tries.
In non-GCC cases, they might not even try to conform, but they usually
do try not to surprise the users too badly.
Wojtek Lerch
news:868wd9l...@ds4.des.no...
> VLAs are a formalization of a trick that was widely used (e.g. in
> protocol stacks) for years before C99. The only differences are that
> you write a[] instead of a[1] (or a[0] if your compiler supported it),
> and that there are (highly sensible) restrictions on what you're allowed
> to do with a struct that ends with a VLA.
I think you're talking about "flexible array members", not VLAs.
Dag-Erling Smørgrav
> "Dag-Erling Smørgrav" <d...@des.no> writes:
> > VLAs are a formalization of a trick [...]
> I think you're talking about "flexible array members", not VLAs.
Doh!
Flash Gordon
> Francis Glassborow <francis.g...@btinternet.com> writes:
>> Actually, how many compilers targeting embedded hardware conform to a
>> C Standard (any one, let alone the latest)
>
> In many if not most cases these days, "compilers targeting embedded
> hardware" means "the GNU compiler collection", which admittedly does not
> conform to any C standard, but at least it tries.
In conforming more (with -ansi -pedantic) it does conform to the
standard, modulo bugs.
> In non-GCC cases, they might not even try to conform, but they usually
> do try not to surprise the users too badly.
The Texas Instruments C compiler for the TMS320C2x/2xx/5x compiled with
one exception, it did not zero static variables which did not have an
initialiser, but since they provided the source for the startup code
(because you needed to tailor it) this was easy to fix. I believe their
compilers for the TMS320C80 (and yes, I did intend the plural, since the
processor had multiple processor cores one of which was completely
different to the others) also conformed. Admittedly it's a while since
I've used them.
--
Flash Gordon
Dag-Erling Smørgrav
> The Texas Instruments C compiler for the TMS320C2x/2xx/5x [...]
Last time I worked on a TI chip (DaVinci & DaVinci HD) they provided two
compilers, one of which was GCC, and the eval board ran Linux...
Flash Gordon
> Flash Gordon <sm...@spam.causeway.com> writes:
>> The Texas Instruments C compiler for the TMS320C2x/2xx/5x [...]
>
> Last time I worked on a TI chip (DaVinci & DaVinci HD) they provided two
> compilers, one of which was GCC, and the eval board ran Linux...
We did not use an eval board, and we did not use Linux (or any OS
provided by TI), and it was definitely a TI compiler not gcc. Things
could have changed since then, or they could do different things for
different ranges of chips, or they could do Linux/gcc for the Eval
boards and as we did not do the eval board...
Another nice thing was the printed manuals included a copy of K&R2.
--
Flash Gordon