future C standards
Beliavsky
that the C standards committee had decided not to make further
substantial changes to the language. If this is true, is there a
document explaining how this decision was reached? Of course, a future
committee could decide differently.
santosh
I gather from informal sources (i.e., comp.std.c and comp.lang.c) that a
new standard is scheduled for release sometime between 2010 to 2019
inclusive, often nicknamed C1x. See WG14's website for more details.
<http://www.open-std.org/jtc1/sc22/wg14/>
At least one member of the Committee has indicated that C1x is likely to
be _very_ conservative with additions and changes, and that one or more
obscure and ill-implemented features introduced with C99 may be
deprecated or removed.
Douglas A. Gwyn
news:g4j9s2$l5c$1...@registered.motzarella.org...
> I gather from informal sources (i.e., comp.std.c and comp.lang.c) that a
> new standard is scheduled for release sometime between 2010 to 2019
> inclusive, often nicknamed C1x. See WG14's website for more details.
> <http://www.open-std.org/jtc1/sc22/wg14/>
So long as the C language is commercially important, which it is likely
to be for decades to come, maintenance of its standard is important.
WG14 has indeed initiated work toward the next revision of the C
standard, to the extent that it might not process any further DRs
against the 1999 C standard.
> At least one member of the Committee has indicated that C1x is likely to
> be _very_ conservative with additions and changes, and that one or more
> obscure and ill-implemented features introduced with C99 may be
> deprecated or removed.
One never knows for sure until the document is published, but for C1x
the charter calls for ignoring proposals for new features if they aren't
already implemented in at least one significant C compiler.
Note that the gets function was already deprecated by a TC (official
patch) to the 1999 C standard.
I wouldn't mind if <tgmath.h> and the advisory appendix about
imaginary numbers was removed from C1x. (Not complex, which
should remain.)
There is a danger that newcomers to the process might try to change
the C standard so that it fits only the subset of reasonable platforms
that they personally care about, instead of the much larger set that the
C standard has always tried to support. There has been some
discussion of tweaking the C1x charter to state that unnecessary
restrictions on the architecture/platform should be avoided.
jacob navia
> "santosh" <santo...@gmail.com> wrote in message
> news:g4j9s2$l5c$1...@registered.motzarella.org...
>> I gather from informal sources (i.e., comp.std.c and comp.lang.c) that a
>> new standard is scheduled for release sometime between 2010 to 2019
>> inclusive, often nicknamed C1x. See WG14's website for more details.
>> <http://www.open-std.org/jtc1/sc22/wg14/>
>
> So long as the C language is commercially important, which it is likely
> to be for decades to come, maintenance of its standard is important.
>
Maintenance. Never try to develop anything. Just maintenance.
> WG14 has indeed initiated work toward the next revision of the C
> standard, to the extent that it might not process any further DRs
> against the 1999 C standard.
>
>> At least one member of the Committee has indicated that C1x is likely to
>> be _very_ conservative with additions and changes, and that one or more
>> obscure and ill-implemented features introduced with C99 may be
>> deprecated or removed.
>
> One never knows for sure until the document is published, but for C1x
> the charter calls for ignoring proposals for new features if they aren't
> already implemented in at least one significant C compiler.
>
> Note that the gets function was already deprecated by a TC (official
> patch) to the 1999 C standard.
>
> I wouldn't mind if <tgmath.h> and the advisory appendix about
> imaginary numbers was removed from C1x. (Not complex, which
> should remain.)
>
Great proposal. Now the only feeble attempt to genericity in an obvious
way must give way to... what? Should then users write sqrtl sqrtf and
remember each variant?
Anyway I will stop trying to implement the few remaining features
lcc-win is missing from C99 and wait till 2019 or later to see if
I do not waste my time implementing features that will be declared
obsolete.
> There is a danger that newcomers to the process might try to change
> the C standard so that it fits only the subset of reasonable platforms
> that they personally care about, instead of the much larger set that the
> C standard has always tried to support.
Maybe it *could* be interesting to try to get away from defining
C as a crippled language for toasters and obsolete microprocessors...
Leveling everything so that it fits the smallest platform is doing a
great harm to the evolution of the language.
> There has been some
> discussion of tweaking the C1x charter to state that unnecessary
> restrictions on the architecture/platform should be avoided.
>
Unnecessary yes, but it could be that you just consider that
refusing to standardize obvious stuff like directory access for
instance, or other features that are present in MOST platforms
even in modern embedded systems just destroys any evolution of the
language.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Keith Thompson
> Douglas A. Gwyn wrote:
[...]
>> So long as the C language is commercially important, which it is
>> likely to be for decades to come, maintenance of its standard is
>> important.
>
> Maintenance. Never try to develop anything. Just maintenance.
Is it really the standard committee's job to invent new features?
Look at what happened with the C99 standard. After 9 years, it's
still not widely implemented. Even your own lcc-win doesn't fully
implement it, which makes your complaint about the committee not
introducing even more new features difficult to take seriously.
The C89/C90 standard was extraordinarily successful because, for the
most part, it standardized existing practice, made clear choices among
differing implementations (e.g., integer promotion rules), and
introduced just a few new features that turned out (by design and/or
good luck) to be extremely useful (particularly prototypes). And it
filled a large gap, since there wasn't a standard at the time. C99
didn't have that advantage, since it had to compete against the
extremely successful and already implemented C90 standard. C1X will
have to compete against C90 *and* C99, and against the perception
(valid or not) that updating the standard is futile.
In any case, Doug merely said that maintenance is important, which it
most certainly is; would you dispute that?
[...]
>> I wouldn't mind if <tgmath.h> and the advisory appendix about
>> imaginary numbers was removed from C1x. (Not complex, which
>> should remain.)
>
> Great proposal. Now the only feeble attempt to genericity in an obvious
> way must give way to... what? Should then users write sqrtl sqrtf and
> remember each variant?
The problem with <tgmath.h> is it *is* a "feeble attempt". It
introduces genericity for a specific set of mathematical functions,
but it doesn't introduce a mechanism for doing the same thing in user
code. And, as far as I can tell, it's just not all that useful. I
don't do much mathemathical programming, so maybe I'm missing
something, but what's so difficult about writing sqrtf, sqrt, or sqrtl
depending on the type of the argument and result?
Using <tgmath.h>, I can write abs(x) where x is of any of the
floating-point or complex types. For integer types, I have to write
abs, labs, llabs (in <stdlib.h>), or imaxabs (in <inttypes.h>),
depending on the type of the argument (possibly using a conversion or
two, explicit or implicit, if I want to use some other type). Sure,
it would be nice to write abs(x) for any type. Do you have a proposed
mechanism to support this? Do you have a proposal that would allow me
to write my own generic functions? (I know you've advocated operator
overloading; I don't remember whether you also advocated function
overloading.)
One obvious solution is C++-style templates. Do you advocate adding
those to C (and making all the other changes necessary to keep the
language consistent)?
> Anyway I will stop trying to implement the few remaining features
> lcc-win is missing from C99 and wait till 2019 or later to see if
> I do not waste my time implementing features that will be declared
> obsolete.
Ok, so for at least the next 11 years, lcc-win will continue to not
fully support any language standard. That's good to know. (In the
past, you've flamed people who have pointed this out; surprise us and
*respond* to it.)
>> There is a danger that newcomers to the process might try to change
>> the C standard so that it fits only the subset of reasonable platforms
>> that they personally care about, instead of the much larger set that the
>> C standard has always tried to support.
>
> Maybe it *could* be interesting to try to get away from defining
> C as a crippled language for toasters and obsolete microprocessors...
>
> Leveling everything so that it fits the smallest platform is doing a
> great harm to the evolution of the language.
C is used, quite successfully, on small platforms. Do you propose
changing the language so that conforming implementations for small
platforms are impossible?
I do think there are a few things that could be tightened up. Some of
the more exotic characteristics tend to exist only on embedded
systems. Requiring CHAR_BIT==8 for hosted implementations just might
be feasible. It might even be possible to require 2's-complement.
But there's always the risk that, 20 years from now, it might make
perfect sense to build a sign-and-magnitude machine with 16-bit bytes.
The committee has to weigh, not just existing implementations, but
possible future implementations as well.
>> There has been some
>> discussion of tweaking the C1x charter to state that unnecessary
>> restrictions on the architecture/platform should be avoided.
>>
> Unnecessary yes, but it could be that you just consider that
> refusing to standardize obvious stuff like directory access for
> instance, or other features that are present in MOST platforms
> even in modern embedded systems just destroys any evolution of the
> language.
It's easy to say that the language should support directory access.
Defining an API that actually works across all relevant platforms,
providing a set of functionality that's both useful and (nearly)
universally implementable, is much more difficult. David Tribble's
proposal, <http://david.tribble.com/text/c0xdir.html>, might be a good
starting point (I haven't studied it lately).
The committee has a difficult and unenviable task: Create a new C
standard that's more successful than C99 has been. It doesn't matter
how many new and useful features they add if the standard isn't
adopted in the real world. In achieving this goal, they cannot ignore
(as you often do) the reality that a lot of people, perhaps most C
programmers, are satisified with C90. Telling them that they *should*
move on to C99 doesn't do any good; most of them are too busy writing
actual code that actually works.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
santosh
[...]
>>> There is a danger that newcomers to the process might try to change
>>> the C standard so that it fits only the subset of reasonable
>>> platforms that they personally care about, instead of the much
>>> larger set that the C standard has always tried to support.
>>
>> Maybe it *could* be interesting to try to get away from defining
>> C as a crippled language for toasters and obsolete microprocessors...
[...]
> C is used, quite successfully, on small platforms. Do you propose
> changing the language so that conforming implementations for small
> platforms are impossible?
>
> I do think there are a few things that could be tightened up. Some of
> the more exotic characteristics tend to exist only on embedded
> systems. Requiring CHAR_BIT==8 for hosted implementations just might
> be feasible. It might even be possible to require 2's-complement.
> But there's always the risk that, 20 years from now, it might make
> perfect sense to build a sign-and-magnitude machine with 16-bit bytes.
> The committee has to weigh, not just existing implementations, but
> possible future implementations as well.
Is it the case that the Committee is cautious because of the
possibilities of the far future, or because it would break existing
code? If there is a possibility that sometime in future exotic
architectures may once again become mainstream, then why is it that the
people that control other successful PLs are not (apparently) so
worried? Can C embrace all possible future changes, many of which we
might not even be able to guess at now?
>>> There has been some
>>> discussion of tweaking the C1x charter to state that unnecessary
>>> restrictions on the architecture/platform should be avoided.
>>>
>> Unnecessary yes, but it could be that you just consider that
>> refusing to standardize obvious stuff like directory access for
>> instance, or other features that are present in MOST platforms
>> even in modern embedded systems just destroys any evolution of the
>> language.
>
> It's easy to say that the language should support directory access.
> Defining an API that actually works across all relevant platforms,
> providing a set of functionality that's both useful and (nearly)
> universally implementable, is much more difficult. David Tribble's
> proposal, <http://david.tribble.com/text/c0xdir.html>, might be a good
> starting point (I haven't studied it lately).
>
> The committee has a difficult and unenviable task: Create a new C
> standard that's more successful than C99 has been.
That should be easy I suppose.
> It doesn't matter
> how many new and useful features they add if the standard isn't
> adopted in the real world. In achieving this goal, they cannot ignore
> (as you often do) the reality that a lot of people, perhaps most C
> programmers, are satisified with C90.
Though that's exactly what they appear to have done the last time
around.
> Telling them that they *should*
> move on to C99 doesn't do any good; most of them are too busy writing
> actual code that actually works.
Like windows-bound lcc-win code you mean? :-)
Jack Klein
wrote in comp.std.c:
[big snip]
> Unnecessary yes, but it could be that you just consider that
> refusing to standardize obvious stuff like directory access for
> instance, or other features that are present in MOST platforms
> even in modern embedded systems just destroys any evolution of the
> language.
Oh Jacob, there you go again.
Please provide evidence for your assertion that directory access is
present in "MOST", particularly "even in modern embedded systems".
Just once, let's see you back up one of your rants with some
verifiable facts.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
jacob navia
[snip drivel]
>
> In any case, Doug merely said that maintenance is important, which it
> most certainly is; would you dispute that?
>
Mr Gwyn has always had an ultra conservative position here.
He defended for weeks gets() in a heated discussion in
this group.
Happily he did not prevail.
> [...]
>>> I wouldn't mind if <tgmath.h> and the advisory appendix about
>>> imaginary numbers was removed from C1x. (Not complex, which
>>> should remain.)
>> Great proposal. Now the only feeble attempt to genericity in an obvious
>> way must give way to... what? Should then users write sqrtl sqrtf and
>> remember each variant?
>
> The problem with <tgmath.h> is it *is* a "feeble attempt". It
> introduces genericity for a specific set of mathematical functions,
> but it doesn't introduce a mechanism for doing the same thing in user
> code. And, as far as I can tell, it's just not all that useful. I
> don't do much mathemathical programming, so maybe I'm missing
> something, but what's so difficult about writing sqrtf, sqrt, or sqrtl
> depending on the type of the argument and result?
>
> Using <tgmath.h>, I can write abs(x) where x is of any of the
> floating-point or complex types. For integer types, I have to write
> abs, labs, llabs (in <stdlib.h>), or imaxabs (in <inttypes.h>),
> depending on the type of the argument (possibly using a conversion or
> two, explicit or implicit, if I want to use some other type). Sure,
> it would be nice to write abs(x) for any type. Do you have a proposed
> mechanism to support this? Do you have a proposal that would allow me
> to write my own generic functions? (I know you've advocated operator
> overloading; I don't remember whether you also advocated function
> overloading.)
>
lcc-win proposed following syntax (and has been a feature of lcc-win
since at least 5 years)
result_type overloaded function_name(type0 arg0, type1 arg1);
result_type overloaded function_name(type2 arg2, type3 arg3);
Using this feature I implemented all tgmath.h
Note that generic programming is useful for modifying underlying
types easily without changing all the code to reflect this change.
If you have
double x,y,z;
/// skip 8556 lines of code with calls to
// sqrt, floor, etc etc.
Using genericity you can change all that code to
long double x,y,z;
// skip 8556 lines of code that do NOT
// need to be changed.
Compare then with your solution, where the user has to
manually edit 8556 lines without doing a single mistake.
> One obvious solution is C++-style templates. Do you advocate adding
> those to C (and making all the other changes necessary to keep the
> language consistent)?
>
I have published several times in this group my proposals. I have
explained that I do not have the 10 000 euros necessary to convince
the French branch of ISO to carry my proposal.
No templates are necessary, and adding this feature to lcc-win required
approximately 500-1000 lines of code to the compiler.
James Kuyper
> Keith Thompson wrote:
...
>> I do think there are a few things that could be tightened up. Some of
>> the more exotic characteristics tend to exist only on embedded
>> systems. Requiring CHAR_BIT==8 for hosted implementations just might
>> be feasible. It might even be possible to require 2's-complement.
>> But there's always the risk that, 20 years from now, it might make
>> perfect sense to build a sign-and-magnitude machine with 16-bit bytes.
>> The committee has to weigh, not just existing implementations, but
>> possible future implementations as well.
>
> Is it the case that the Committee is cautious because of the
> possibilities of the far future, or because it would break existing
> code? If there is a possibility that sometime in future exotic
If you mean that old architectures that faded away and are now
considered exotic will come back, that's not very likely for any
particular architectural feature (though there's such a large variety of
features that at least one of them probably will be revived, sooner or
later). However, the possibility of new architectures becoming
mainstream that would seem exotic to us now, is pretty close to 100%.
The idea is not to try to predict future architectures, but to avoid
unnecessarily constraining C to be incompatible with them.
> ... then why is it that the
> people that control other successful PLs are not (apparently) so
> worried? ...
Each language has different goals it is designed for; wide-spread
implementability has always been a high priority for C, a consequence of
which has been that standard conforming implementations of C can be, and
are, available on a wider variety of platforms than just about any
other language. Wide-spread implementability is a forward-looking goal,
not just a goal for the present.
> ... Can C embrace all possible future changes, many of which we
> might not even be able to guess at now?
Not with a certainty; but it can certainly avoid unnecessarily
standardizing constraints just because every existing architecture can
live within them.
...
>> The committee has a difficult and unenviable task: Create a new C
>> standard that's more successful than C99 has been.
>
> That should be easy I suppose.
I don't see why; if it's more innovative than C99, it won't be adopted
because it will be too backwards-incompatible. If it's less innovative,
there will be little incentive for implementing it; that's the same
catch-22 that has rendered C99 far less successful than C90.
...
>> Telling them that they *should*
>> move on to C99 doesn't do any good; most of them are too busy writing
>> actual code that actually works.
>
> Like windows-bound lcc-win code you mean? :-)
He did say "actually works". lcc-win fails to conform to any version of
the C standard, which is something that Jacob is free to choose to do.
However, far too many of the ways in which it is non-conforming came as
a complete surprise to him when they were reported - that does not
inspire confidence in the competence of the implementor or the quality
of the implementation.
Francis Glassborow
>
> The problem with <tgmath.h> is it *is* a "feeble attempt". It
> introduces genericity for a specific set of mathematical functions,
> but it doesn't introduce a mechanism for doing the same thing in user
> code. And, as far as I can tell, it's just not all that useful. I
> don't do much mathemathical programming, so maybe I'm missing
> something, but what's so difficult about writing sqrtf, sqrt, or sqrtl
> depending on the type of the argument and result?
Yes, the fundamental problem with tgmath is that it only applies to the
functions provided by the standard library. Without a more general
mechanism available to the user it is almost useless.
>
> Using <tgmath.h>, I can write abs(x) where x is of any of the
> floating-point or complex types. For integer types, I have to write
> abs, labs, llabs (in <stdlib.h>), or imaxabs (in <inttypes.h>),
> depending on the type of the argument (possibly using a conversion or
> two, explicit or implicit, if I want to use some other type). Sure,
> it would be nice to write abs(x) for any type. Do you have a proposed
> mechanism to support this? Do you have a proposal that would allow me
> to write my own generic functions? (I know you've advocated operator
> overloading; I don't remember whether you also advocated function
> overloading.)
Well I have several time suggested a mechanism for overloading that does
not suffer from the problems that C++ function overloading has (name
mangling, and an unknown overload set that can be accidentally added to)
>
> One obvious solution is C++-style templates. Do you advocate adding
> those to C (and making all the other changes necessary to keep the
> language consistent)?
I would be very much against introducing templates to C. They are a
great tool in C++ but they introduce a great deal of complexity and
accidental usage (C++ is introducing 'concepts' to, among other things,
limit that problem). In addition introducing templates without function
overloading seems odd to me.
--
Note that robinton.demon.co.uk addresses are no longer valid.
Francis Glassborow
>
> If you mean that old architectures that faded away and are now
> considered exotic will come back, that's not very likely for any
> particular architectural feature (though there's such a large variety of
> features that at least one of them probably will be revived, sooner or
> later). However, the possibility of new architectures becoming
> mainstream that would seem exotic to us now, is pretty close to 100%.
> The idea is not to try to predict future architectures, but to avoid
> unnecessarily constraining C to be incompatible with them.
>
Well C has one fundamental constraint that might well make it useless on
some potential future architectures. The abstract machine uses binary
for its representation of integer types.
Francis Glassborow
>>
>
> lcc-win proposed following syntax (and has been a feature of lcc-win
> since at least 5 years)
>
> result_type overloaded function_name(type0 arg0, type1 arg1);
> result_type overloaded function_name(type2 arg2, type3 arg3);
>
>
> Using this feature I implemented all tgmath.h
>
>
> Note that generic programming is useful for modifying underlying
> types easily without changing all the code to reflect this change.
>
> If you have
>
> double x,y,z;
>
> /// skip 8556 lines of code with calls to
> // sqrt, floor, etc etc.
>
> Using genericity you can change all that code to
> long double x,y,z;
>
> // skip 8556 lines of code that do NOT
> // need to be changed.
>
>
> Compare then with your solution, where the user has to
> manually edit 8556 lines without doing a single mistake.
>
>
>> One obvious solution is C++-style templates. Do you advocate adding
>> those to C (and making all the other changes necessary to keep the
>> language consistent)?
>>
>
> I have published several times in this group my proposals. I have
> explained that I do not have the 10 000 euros necessary to convince
> the French branch of ISO to carry my proposal.
However the fact that you have implemented it means that there is a C
implementation that has it and that should cross the hurdle about 'no
invention'.
Write up a detailed proposal and then you can see if you can find an
advocate among the various NBs.
jacob navia
> On Sun, 06 Jul 2008 22:33:06 +0200, jacob navia <ja...@nospam.com>
> wrote in comp.std.c:
>
> [big snip]
>
>> Unnecessary yes, but it could be that you just consider that
>> refusing to standardize obvious stuff like directory access for
>> instance, or other features that are present in MOST platforms
>> even in modern embedded systems just destroys any evolution of the
>> language.
>
> Oh Jacob, there you go again.
>
> Please provide evidence for your assertion that directory access is
> present in "MOST", particularly "even in modern embedded systems".
>
> Just once, let's see you back up one of your rants with some
> verifiable facts.
>
MSDOS is an OS used very often in embedded systems.
It has directories since at least 20 years
Linux is used in many embedded systems, specially in systems like
the iphone, and others. It has been ported to consoles like
the play station, and many other hardware.
Linux has directories.
Directories are a normal feature of operating systems since
several decades now.
Obviously all windows+Linux+MacIntosh+Sun workstations do not count
for you. They have directories.
The QNX real time OS features ext2-ext3 or FAT or NTFS file systems
for EPROM embedded file systems.
(http://www.qnx.com/products/neutrino_rtos/fsys.html)
I could go on, but I think it is better that YOU tell us what
significant file system today does NOT have any directories.
jacob navia
> santosh wrote:
>> Keith Thompson wrote:
> ...
>>> most of them are too busy writing
>>> actual code that actually works.
>>
>> Like windows-bound lcc-win code you mean? :-)
>
> He did say "actually works". lcc-win fails to conform to any version of
> the C standard, which is something that Jacob is free to choose to do.
I have been working for YEARS trying to implement all features of the
C99 standard. This HUGE work has never been attempted by a team of
2 people. All other compiler systems have bigger teams than
lcc-win.
Still, we have been able to implement almost ALL of the standard. To
say that lcc-win fails to conform to any version of the C standard
is a gross exaggeration.
lcc-win has recently passed the cap of 1 MILLION downloads. It proves
that C is a language of choice by many people. In educational settings
lcc-win is used in many universities and educational institutions.
lcc-win is not only a compiler. It features a full IDE+debugger and
development environment. That is why, even if it is a priority, there
are still two or three important features missing from C99.
> However, far too many of the ways in which it is non-conforming came as
> a complete surprise to him when they were reported
Yes, incredible. Bugs are a surprise for the developer. That is one
of the drawbacks of developing code. Much easier is to relax and
rant about other people being surprised by their bugs.
- that does not
> inspire confidence in the competence of the implementor
Obviously I should not be surprised at my bugs.
> or the quality of the implementation.
You haven't even used my system. You just complain that is not
perfect. This is possible because I am here to hear your
complaints. Neither GCC nor Microsoft representatives discuss
in this group.
GCC even if it has vastly more resources than lcc-win has never
completed their implementation.
Microsoft flatly refused to implement anything from the C99 standard.
Obviously, lcc-win can be criticized here. It is an easy target.
But GCC or Microsoft?
Silence.
lcc-win is a C compiler that is developed as a C compiler, not as
a C++ compiler that as an afterthought also compiles C89.
Ben Bacarisse
<snip>
> I have published several times in this group my proposals. I have
> explained that I do not have the 10 000 euros necessary to convince
> the French branch of ISO to carry my proposal.
The problem is that you have no formal proposal. The document I have
seen is leaves far too many questions unanswered and is, at least at
first glance, contradictory[1]. Someone has to work out the proposal
in enough detail to explain exactly what the new semantics are and how
the interact with all the other language features. This is a lot of
work, and I doubt anyone will want to do it for you. As it stands, it
can't go anywhere.
[1] For example, section 1.4.3 says that the rules for name resolution
(of overloaded functions) are the same as those for operator
overloading. You state here that you use this for implementing
tgmath.h but your rules are inconsistent with those required by
tgmath.h. Take a call to sin(1): this fails to match any targets at
steps 1 and 2 and matches all of them at step 3. By your rules, this
is an error (there must be only one match). This is only the most
obvious of a large number of unspecified things in the proposal that I
have seen.
--
Ben.
jacob navia
> (of overloaded functions) are the same as those for operator
> overloading. You state here that you use this for implementing
> tgmath.h but your rules are inconsistent with those required by
> tgmath.h. Take a call to sin(1): this fails to match any targets at
> steps 1 and 2 and matches all of them at step 3. By your rules, this
> is an error (there must be only one match). This is only the most
> obvious of a large number of unspecified things in the proposal that I
> have seen.
>
The C99 specifies already the resolution rules. See 7.22.3 of the
C standard
The rules in my document are to be understood as an ADDITION to the
C99 rules OF COURSE!
As I have told you several times, I am not very good at formulating
language laws, and my document is far from perfect. You have refused
any contribution, even if I have invited you several times to help
me with this.
You limit yourself to read my documents and say to the whole world that
they are bad without ever proposing anything, like most people in your
comp.lang.c group.
This objection is obviously wrong.
I repeat:
The C99 standard already specifies the rules for argument resolution in
the case of generic functions that receive standard C types. My proposal
assumes those as a matter of obvious fact!
James Kuyper
> James Kuyper wrote:
...
>> He did say "actually works". lcc-win fails to conform to any version
>> of the C standard, which is something that Jacob is free to choose to do.
>
> I have been working for YEARS trying to implement all features of the
> C99 standard. This HUGE work has never been attempted by a team of
> 2 people. All other compiler systems have bigger teams than
> lcc-win.
>
> Still, we have been able to implement almost ALL of the standard. To
> say that lcc-win fails to conform to any version of the C standard
> is a gross exaggeration.
Conformance is a yes/no question. It's either true or false that lcc-win
does not conform to any standard. It can't be exaggerated or minimized.
If I'd made a comparative statement like "poorly conforms" or "almost
conforms", then exaggeration or minimization could be an issue. Can you
specify any version of the C standard to which lcc-win fully conforms?
I'll grant you, fully conforming implementations of C99 are sufficiently
rare that "nearly conforming" implementations are still to be valued.
But fully conforming implementations of C90 + the 1994 TCs are
commonplace, and almost every C compiler is intended to fully conform
to C90 in some mode. When they fail to conform, it is usually due to
incorrectly implementing the requirements, not a deliberate decision not
to implement them, and not due to ignorance of what those requirements are.
...
>> However, far too many of the ways in which it is non-conforming came
>> as a complete surprise to him when they were reported
>
> Yes, incredible. Bugs are a surprise for the developer. That is one
> of the drawbacks of developing code. Much easier is to relax and
> rant about other people being surprised by their bugs.
No, there's nothing unusual about being surprised by bugs. What is
surprising is that the bugs existed because of a failure to understand
what the correct behavior should be rather than because you failed to
implement a correct understanding of the behavior. The relatively
elementary nature of many of those bugs also tends to reduce my
confidence in the quality of your compiler.
> - that does not
>> inspire confidence in the competence of the implementor
>
> Obviously I should not be surprised at my bugs.
No, you've every right to be surprised by the bugs. It's the
requirements that shouldn't surprise you. As a developer for a C-like
language, failing to implement 'int long' as a legal synonym for "long
int" should be something that only occurs as a result of a deliberate
decision, not ignorance of the fact that the C standard requires it (and
has always done so).
> You haven't even used my system. ...
Well, that's primarily because your system targets a limited market, one
that doesn't include any machine I'm currently programming for. I'd have
to ask my wife's permission to even install your software on the only
machine I have access to which it could run on, and frankly I couldn't
give her any good reason for letting me. It's hard enough getting her
permission to install my legacy M$ games on there. It's supposed to be
exclusively for her e-mail and web-browsing.
> ... You just complain that is not
> perfect. ...
I don't expect any program to be perfect; I have too much personal
experience with software development to expect otherwise. It is
commonplace for there to be obscure circumstances in which a program
fails to implement the required behavior. However, I expect competent
developers to rarely produce bugs due to misunderstanding what the
required behavior is, and to rarely produce bugs that are as elementary
as the ones that have been reported in lcc-win. When I see such things,
they do reduce my desire to even try out the program.
> ... This is possible because I am here to hear your
> complaints. Neither GCC nor Microsoft representatives discuss
> in this group.
I wouldn't know about that; as long as they don't promote their own
software (as would be inappropriate in this newsgroup), I'd have little
or no reason to be aware of whether or not they represented those
organizations. There has been considerable discussion of M$ proposal to
standardize it's supposedly-safer alternatives to standard library
routines. Whether any of those discussing it were M$ representatives I
have no idea; I presume that he majority who disapproved of the idea
probably included few, if any, of their representatives.
> GCC even if it has vastly more resources than lcc-win has never
> completed their implementation.
They've completed their implementation of C90; something lcc-win has not
yet done. They've completed implementation of a large portion of C99,
including a number of features that lcc-win doesn't implement.
> Obviously, lcc-win can be criticized here. It is an easy target.
> But GCC or Microsoft?
>
> Silence.
I would have criticized Microsoft just as harshly, had it been mentioned
in a comparable context. I would have criticized gcc had it been
mentioned, for it's failure to complete implementation of C99. However,
they have implemented C90 fully, and a large fraction of C99, and I not
aware of any other significant problems with gcc, so my criticism would
be substantially less harsh than my criticism of lcc-win.
> lcc-win is a C compiler that is developed as a C compiler, not as
> a C++ compiler that as an afterthought also compiles C89.
It would be nice if it did, at least, actually fully implement C89 (or
preferably C99, if I have to choose one or the other).
James Kuyper
...
> As I have told you several times, I am not very good at formulating
> language laws, and my document is far from perfect. You have refused
> any contribution, even if I have invited you several times to help
> me with this.
You can't expect help from someone who you've failed to convince of the
merits of the proposal. You've got to convince someone who possesses the
skill at writing standardese that you lack. If you can't convince any
such person, as a practical matter you're unlikely to convince a
majority of the committee, either (since most of them possess that skill).
> You limit yourself to read my documents and say to the whole world that
> they are bad without ever proposing anything, like most people in your
> comp.lang.c group.
The only newsgroup that you sent that message to was comp.std.c; was it
intended for comp.lang.c?
It is commonplace for posters on this newsgroup to possess sufficient
knowledge to point out the flaws in a proposal; it's much rarer to
possess sufficient knowledge and imagination to propose a change that's
truly worthy of consideration. The fact that someone doesn't fall into
the second category in no way invalidates the flaws he recognizes
because he is in the first category.
Keith Thompson
> James Kuyper wrote:
>> santosh wrote:
>>> Keith Thompson wrote:
>> ...
>>>> Telling them that they *should* move on to C99 doesn't do any
>>>> good; most of them are too busy writing
>>>> actual code that actually works.
>>>
>>> Like windows-bound lcc-win code you mean? :-)
>> He did say "actually works". lcc-win fails to conform to any version
>> of the C standard, which is something that Jacob is free to choose
>> to do.
>
> I have been working for YEARS trying to implement all features of the
> C99 standard. This HUGE work has never been attempted by a team of
> 2 people. All other compiler systems have bigger teams than
> lcc-win.
>
> Still, we have been able to implement almost ALL of the standard. To
> say that lcc-win fails to conform to any version of the C standard
> is a gross exaggeration.
No, it's a straightforward statement of fact. Perhaps it wouldn't be
remarked upon so much if you didn't tell everyone that they should
abandon C90 and use C99 exclusively.
[...]
> lcc-win is not only a compiler. It features a full IDE+debugger and
> development environment. That is why, even if it is a priority, there
> are still two or three important features missing from C99.
It's understandable if standard conformance isn't your highest
priority. But telling us *why* lcc-win doesn't fully conform to the
standard doesn't refute the statement that it *doesn't* fully conform
to the standard.
>> However, far too many of the ways in which it is non-conforming came
>> as a complete surprise to him when they were reported
>
> Yes, incredible. Bugs are a surprise for the developer. That is one
> of the drawbacks of developing code. Much easier is to relax and
> rant about other people being surprised by their bugs.
Too many of the errors are of the same form: non-standard identifiers
in standard headers, visible in conforming mode. A one-time audit of
your standard headers could correct all such problems.
[...]
> You haven't even used my system. You just complain that is not
> perfect. This is possible because I am here to hear your
> complaints. Neither GCC nor Microsoft representatives discuss
> in this group.
>
> GCC even if it has vastly more resources than lcc-win has never
> completed their implementation.
>
> Microsoft flatly refused to implement anything from the C99 standard.
>
> Obviously, lcc-win can be criticized here. It is an easy target.
> But GCC or Microsoft?
>
> Silence.
So that's three major compilers that, for whatever reason, have not
fully implemented C99 after nine years.
The C99 standard added new features to the language, and those
features have not been widely implemented. It's difficult to avoid
the conclusion that C99 introduced too many new features.
In the late 1980s, the C community was clamoring for a standard, so
they could stop writing quite so many #ifdefs. The C89/C90 standard
met that need. In the late 1990s, I don't recall any such eager
demand for a new standard to replace C90.
Now you advocate adding new features in C1X. Why do you expect the
results to be any different this time?
> lcc-win is a C compiler that is developed as a C compiler, not as
> a C++ compiler that as an afterthought also compiles C89.
gcc's C compiler is older than its C++ compiler, and the front ends
are still separate. I don't know about Microsoft's compiler.
jacob navia
> jacob navia wrote:
>> James Kuyper wrote:
> ...
>>> He did say "actually works". lcc-win fails to conform to any version
>>> of the C standard, which is something that Jacob is free to choose to
>>> do.
>>
>> I have been working for YEARS trying to implement all features of the
>> C99 standard. This HUGE work has never been attempted by a team of
>> 2 people. All other compiler systems have bigger teams than
>> lcc-win.
>>
>> Still, we have been able to implement almost ALL of the standard. To
>> say that lcc-win fails to conform to any version of the C standard
>> is a gross exaggeration.
>
> Conformance is a yes/no question.
Great. So either it is perfect or it not perfect.
The slightest problem, non-implemented feature and there you
go.
By your measure there is at most 1 C++ compiler in the whole world.
(EDG front end)
> It's either true or false that lcc-win
> does not conform to any standard.
False. The 89 standard is supported.
> It can't be exaggerated or minimized.
> If I'd made a comparative statement like "poorly conforms" or "almost
> conforms", then exaggeration or minimization could be an issue. Can you
> specify any version of the C standard to which lcc-win fully conforms?
>
> I'll grant you, fully conforming implementations of C99 are sufficiently
> rare that "nearly conforming" implementations are still to be valued.
> But fully conforming implementations of C90 + the 1994 TCs are
> commonplace, and almost every C compiler is intended to fully conform
> to C90 in some mode. When they fail to conform, it is usually due to
> incorrectly implementing the requirements, not a deliberate decision not
> to implement them, and not due to ignorance of what those requirements are.
>
I will not work trying to take out // comments in some special C89
mode. I will just not do it. You (and the "regulars" of comp.lang.c)
have just a big prejudice against lcc-win. Why?
Obvious. It runs under MS windows, as everybody knows, only MS slaves
use that system (etc etc).
> ...
>>> However, far too many of the ways in which it is non-conforming came
>>> as a complete surprise to him when they were reported
>>
>> Yes, incredible. Bugs are a surprise for the developer. That is one
>> of the drawbacks of developing code. Much easier is to relax and
>> rant about other people being surprised by their bugs.
>
> No, there's nothing unusual about being surprised by bugs. What is
> surprising is that the bugs existed because of a failure to understand
> what the correct behavior should be rather than because you failed to
> implement a correct understanding of the behavior. The relatively
> elementary nature of many of those bugs also tends to reduce my
> confidence in the quality of your compiler.
>
What the hell are you talking about?
What feature is missing?
>> - that does not
>>> inspire confidence in the competence of the implementor
>>
>> Obviously I should not be surprised at my bugs.
>
> No, you've every right to be surprised by the bugs. It's the
> requirements that shouldn't surprise you. As a developer for a C-like
> language, failing to implement 'int long' as a legal synonym for "long
> int" should be something that only occurs as a result of a deliberate
> decision, not ignorance of the fact that the C standard requires it (and
> has always done so).
int long works in lcc-win. Download it and speak later.
It is interesting that an obscure sentence somewhere in the standard
raises so much problems for you.
>
>> You haven't even used my system. ...
>
> Well, that's primarily because your system targets a limited market, one
> that doesn't include any machine I'm currently programming for.
Yes, I only have versions for windows, linux and AIX.
> I'd have
> to ask my wife's permission to even install your software on the only
> machine I have access to which it could run on, and frankly I couldn't
> give her any good reason for letting me.
Yes, yes. If I started ranting like that against unix you would raise
hell of course. Personally, I do not care about you using my
system. But if you do not use it and criticizes it only from
hearsay please verify what you say before OK?
> It's hard enough getting her
> permission to install my legacy M$ games on there. It's supposed to be
> exclusively for her e-mail and web-browsing.
>
Yes. and linux is in use at home as a cheap router, nothing more.
So what?
Should I start ranting against linux or unix in general?
No. My personal use doesn't say anything about how capable is the
system for other uses.
>> ... You just complain that is not
>> perfect. ...
>
> I don't expect any program to be perfect; I have too much personal
> experience with software development to expect otherwise. It is
> commonplace for there to be obscure circumstances in which a program
> fails to implement the required behavior. However, I expect competent
> developers to rarely produce bugs due to misunderstanding what the
> required behavior is, and to rarely produce bugs that are as elementary
> as the ones that have been reported in lcc-win.
Your friends of comp.lang.c, that have started a denigration campaign
against my software, mainly because I have dared to see this language
not as a completely DEAD thing but to propose changes, and implement them.
> When I see such things,
> they do reduce my desire to even try out the program.
>
Just keep it like this.
[resdt of drivel snipped]
Keith Thompson
> James Kuyper wrote:
>> jacob navia wrote:
>>> James Kuyper wrote:
>> ...
>>>> He did say "actually works". lcc-win fails to conform to any
>>>> version of the C standard, which is something that Jacob is free
>>>> to choose to do.
>>>
>>> I have been working for YEARS trying to implement all features of the
>>> C99 standard. This HUGE work has never been attempted by a team of
>>> 2 people. All other compiler systems have bigger teams than
>>> lcc-win.
>>>
>>> Still, we have been able to implement almost ALL of the standard. To
>>> say that lcc-win fails to conform to any version of the C standard
>>> is a gross exaggeration.
>> Conformance is a yes/no question.
>
> Great. So either it is perfect or it not perfect.
> The slightest problem, non-implemented feature and there you
> go.
He was talking about conformance to the standard, not "perfection".
> By your measure there is at most 1 C++ compiler in the whole world.
> (EDG front end)
Well, a front end presumably is not a full compiler. But we're not
talking about a requirement that a compiler must be bug-free. We're
talking about implementing the features of the language.
A number of existing compilers implement all the features of C90.
I'm sure all of them have bugs here and there, and an ultra-strict
interpretation would say that any bug causes a compiler to be
non-conforming. But we're not applying such a strict standard.
gcc is a conforming C90 compiler, ignoring minor bugs.
By the same measure, gcc is not a fully conforming C99
compiler, because there are features it doesn't implement; see
<http://gcc.gnu.org/c99status.html>. (And of course the library
is part of the conformance picture; gcc's library is separate,
lcc-win's is not.)
And by the same measure, lcc-win is not a fully conforming C99
compiler, because there are features that are not
yet implemented. Quoting your own posting in comp.compilers.lcc
some time ago:
| Designated initializers and structure initializers with the
| dot notation are missing.
|
| I am giving priority to the library, that is kind of
| "mostly" finished. I have probably some problems with
| complex numbers, there hasn't been a good testing of that
| part.
|
| Besides the preprocessor is still missing the variable
| arguments feature.
That was nearly 2 years ago; I don't know how much progress you've
made since then.
>> It's either true or false that lcc-win does not conform to any
>> standard.
>
> False. The 89 standard is supported.
Is it? This is the first time I've seen that claim.
A conforming C89/C90 compiler must issue a diagnostic for an attempt
to use a "//" comment (except in obscure cases where "//" can occur in
legal C90 code). A conforming C90 compiler must allow the use of
"restrict" as an identifier. A conforming C90 compiler must allow the
use of C99-specific identifiers, such as "expl", in use code. Does
lcc-win have a documented mode in which it meets these requirements?
Let me be very clear: I'm *not* saying that it should do so. It's
your compiler; what you choose to implement is between you and your
customers. If you choose to ignore C90 and implement most of C99,
with the goal of implementing all of C99, I have no objection to that.
[...]
> I will not work trying to take out // comments in some special C89
> mode. I will just not do it.
Ok, so that answers one of my questons above. Do you still claim that
C89 is fully supported? Or are you making some distinction between
"supported" and "fully supported"?
> Obvious. It runs under MS windows, as everybody knows, only MS slaves
> use that system (etc etc).
Nobody has said that. James was explaining why *he* doesn't use
lcc-win. If there was an attack on Microsoft, I didn't see it.
[snip]
> int long works in lcc-win. Download it and speak later.
What about "long int long"? Perhaps you've fixed that recently.
> It is interesting that an obscure sentence somewhere in the standard
> raises so much problems for you.
It's no more obscure than any other sentence in the compiler. What's
surprising is that it's such a problem for you.
[...]
> Your friends of comp.lang.c, that have started a denigration campaign
> against my software, mainly because I have dared to see this language
> not as a completely DEAD thing but to propose changes, and implement them.
You continue to completely misunderstand our position. I've tried to
explain it to you many times before; I won't do so again now.
Wojtek Lerch
news:g4tbj7$cl9$1...@aioe.org...
> Ben Bacarisse wrote:
>> jacob navia <ja...@nospam.com> writes:
>> [1] For example, section 1.4.3 says that the rules for name resolution
>> (of overloaded functions) are the same as those for operator
>> overloading. You state here that you use this for implementing
>> tgmath.h but your rules are inconsistent with those required by
>> tgmath.h. Take a call to sin(1): this fails to match any targets at
>> steps 1 and 2 and matches all of them at step 3. By your rules, this
>> is an error (there must be only one match). This is only the most
>> obvious of a large number of unspecified things in the proposal that I
>> have seen.
>>
>
> The C99 specifies already the resolution rules. See 7.22.3 of the
> C standard
No, C99 specifies the rules for a fixed list of standard type-generic macros
in <tgmath.h>. Your proposal talks about overloading of user-defined
functions and needs to cover many more possible combinations of argument
types than 7.22.3 needs to deal with.
Of course, it would be nice if your proposed mechanism could be used to
implement the <tgmath.h> semantics, and for that to be possible, the
existing resolution rules would have to logically follow from your rules, or
at least not conflict with them. But that does not make it obvious that
your rules, as you wrote them in your proposal, are not meant to be a
generalization of the existing rules, but a partial specification that is
supposed to be somehow merged with 7.22.3 to produce the complete set of
rules.
> The rules in my document are to be understood as an ADDITION to the
> C99 rules OF COURSE!
There's nothing obvious about that, and it's also not obvious where the
existing rules of 7.22.3 fit into your five-step scheme. (I suspect you
might want them to be applied as an additional step between your steps two
and three, but that's just a guess.)
...
> The C99 standard already specifies the rules for argument resolution in
> the case of generic functions that receive standard C types. My proposal
> assumes those as a matter of obvious fact!
No, the C99 standard specifies the rules for the limited set of type-generic
macros defined in <tgmath.h>. As it happens, all the functions that those
macros map to have only floating-point parameters, and the rules don't have
to deal with functions defined with integer or pointer parameters. It's
absolutely non-obvious that the five-step rules in your proposal were really
meant to be six-step rules with the text of 7.22.3 somehow merged into them.
Another problem I have with your rules is that they never mention any
pointer types. That seems to imply that anything other than an exact match
is not accepted for pointer arguments; but I would expect function
overloading to allow matching a parameter defined as a pointer to a
qualified type with an actual argument that points to a less-qualified type;
I would also expect to be allowed to mix pointers to void with pointers to
other object types. (And what about mixing pointers that are compatible but
different, such as a pointer to an array with a known length and a pointer
to an array with an unspecified length?) I would also expect a rule that
guarantees that NULL will be recognized as a pointer argument, even in the
presence of a function declared with a double parameter. But maybe I'm
expecting more convenience than you had in mind.
Does your implementation accept any pointer types other than an exact match?
Deos it allow passing NULL or 0 to an overloaded function that expects a
pointer? If it does, shouldn't your rules talk about those cases? Or were
you expecting the committee to figure out the exact rules by running your
compiler?
Ben Bacarisse
> Ben Bacarisse wrote:
>> jacob navia <ja...@nospam.com> writes:
>> [1] For example, section 1.4.3 says that the rules for name resolution
>> (of overloaded functions) are the same as those for operator
>> overloading. You state here that you use this for implementing
>> tgmath.h but your rules are inconsistent with those required by
>> tgmath.h. Take a call to sin(1): this fails to match any targets at
>> steps 1 and 2 and matches all of them at step 3. By your rules, this
>> is an error (there must be only one match). This is only the most
>> obvious of a large number of unspecified things in the proposal that I
>> have seen.
>
> The C99 specifies already the resolution rules. See 7.22.3 of the
> C standard
>
> The rules in my document are to be understood as an ADDITION to the
> C99 rules OF COURSE!
Why "of course"? In this thread you proposed overloading as an
alternative way to get the functionality of tgmath.h and now I should
know that the proposal is to be taken as in addition to what you
propose (here) to replace?
Even if I took that as a serious suggestion, 7.22.3 addresses which of
a narrow set of functions (the maths functions, basically) gets called
depending on the types of the arguments. Are you proposing that your
overloading behaves differently if the name of the function is one of
the math function? Alternatively, are you taking 7.22.3 as some sort
of general rule (applying to all generic function)? If so, it leaves
all sort of things unspecified.
> As I have told you several times, I am not very good at formulating
> language laws, and my document is far from perfect. You have refused
> any contribution, even if I have invited you several times to help
> me with this.
If I recall, I said that I doubted you'd welcome my input. I still
believe that to be the case.
> This objection is obviously wrong.
>
> I repeat:
>
> The C99 standard already specifies the rules for argument resolution in
> the case of generic functions that receive standard C types.
It does no such thing. The whole of 7.22 is about a specific set of
named macros (with lots of special cases). You can not be seriously
suggesting that these rules be used for some names and your rules for
others. If, as I think it more likely, you are extending 7.22.3 as a
set of general rules, then you have the problem that it does not say
anything about all sorts of cases you seem to implement
(e.g. pointers).
> My proposal
> assumes those as a matter of obvious fact!
I am living proof that it is not obvious!
--
Ben.
jacob navia
> "jacob navia" <ja...@nospam.com> wrote in message
> news:g4tbj7$cl9$1...@aioe.org...
>> Ben Bacarisse wrote:
>>> jacob navia <ja...@nospam.com> writes:
>>> [1] For example, section 1.4.3 says that the rules for name resolution
>>> (of overloaded functions) are the same as those for operator
>>> overloading. You state here that you use this for implementing
>>> tgmath.h but your rules are inconsistent with those required by
>>> tgmath.h. Take a call to sin(1): this fails to match any targets at
>>> steps 1 and 2 and matches all of them at step 3. By your rules, this
>>> is an error (there must be only one match). This is only the most
>>> obvious of a large number of unspecified things in the proposal that I
>>> have seen.
>>>
>>
>> The C99 specifies already the resolution rules. See 7.22.3 of the
>> C standard
>
> No, C99 specifies the rules for a fixed list of standard type-generic
> macros in <tgmath.h>. Your proposal talks about overloading of
> user-defined functions and needs to cover many more possible
> combinations of argument types than 7.22.3 needs to deal with.
>
Obvious. But the rules of C99 would give a clear answer to many
obscure "limit" problems.
> Of course, it would be nice if your proposed mechanism could be used to
> implement the <tgmath.h> semantics, and for that to be possible, the
> existing resolution rules would have to logically follow from your
> rules, or at least not conflict with them. But that does not make it
> obvious that your rules, as you wrote them in your proposal, are not
> meant to be a generalization of the existing rules, but a partial
> specification that is supposed to be somehow merged with 7.22.3 to
> produce the complete set of rules.
>
Yes, I will rewrite my specs again.
>> The rules in my document are to be understood as an ADDITION to the
>> C99 rules OF COURSE!
>
> There's nothing obvious about that, and it's also not obvious where the
> existing rules of 7.22.3 fit into your five-step scheme. (I suspect you
> might want them to be applied as an additional step between your steps
> two and three, but that's just a guess.)
>
A good guess. I will propose this again.
> ...
>> The C99 standard already specifies the rules for argument resolution in
>> the case of generic functions that receive standard C types. My proposal
>> assumes those as a matter of obvious fact!
>
> No, the C99 standard specifies the rules for the limited set of
> type-generic macros defined in <tgmath.h>. As it happens, all the
> functions that those macros map to have only floating-point parameters,
> and the rules don't have to deal with functions defined with integer or
> pointer parameters. It's absolutely non-obvious that the five-step
> rules in your proposal were really meant to be six-step rules with the
> text of 7.22.3 somehow merged into them.
>
>
> Another problem I have with your rules is that they never mention any
> pointer types. That seems to imply that anything other than an exact
> match is not accepted for pointer arguments; but I would expect function
> overloading to allow matching a parameter defined as a pointer to a
> qualified type with an actual argument that points to a less-qualified
> type;
Mmmm "less qualified" is the key word here. It implies an ascending
order in "qualified"ness. Can you tell me with an example what you mean
here?
My main emphasis in this area is to keep it simple. As simple as
possible, since we can quickly get into C++ with its incomprehensible
rules... And this means that if we have to tread language
transparency against making it easier for some users to type less
we should always follow language simplicity.
> I would also expect to be allowed to mix pointers to void with
> pointers to other object types.
This is problematic because it would introduce a "wild card".
Suppose:
int overloaded fn(double *);
int overloaded fn(long double *);
Now a call appears
void *p;
fn(p);
p would match ANY pointer...
Now, the user can resolve this by typing
fn((double *)p);
and it is NOT a big deal, making the code much clearer, the reader
of the code KNOWS it is calling the first overloaded function.
My nightmare is generating a bad call, i.e. a call that follows
the rules but the user did not intend. That is why we should
strive to keep the rule set as small and clear as possible.
> (And what about mixing pointers that
> are compatible but different, such as a pointer to an array with a known
> length and a pointer to an array with an unspecified length?)
Personally I would be against it. The reason is that the user can
disambiguate things with a cast that forces a choice from the
different possibilities. Yes, it is less "powerful" but it is
clearer.
> I would
> also expect a rule that guarantees that NULL will be recognized as a
> pointer argument, even in the presence of a function declared with a
> double parameter.
If NULL is defined as (void *)0 the cast forces it as a pointer.
Obviously you can't expect that a BARE zero will be used as a
null pointer...
> But maybe I'm expecting more convenience than you had
> in mind.
>
Yes. Convenience is a risky thing here, since it can produce
difficult to read languages like C++. In the context of C,
we should try to make just the MINIMUM set of rules that has
a certain functionality and NOT strive to redo C++, what
would be pointless since that language exists, is available
and can be used if you need more "convenience".
What I like from the C language is its transparency and simplicity.
This makes C easier to learn and write, easier to use as more
complicated languages. I want to add some small features to it
to make it easier to program in C, but surely not producing
anything like C++.
> Does your implementation accept any pointer types other than an exact
> match?
No. I know this may seem like a big limitation, and it is a big
limitation. But I want to avoid any complicated rules. If you
need it, you just add an explicit cast to the call and you are
all set!
Deos it allow passing NULL or 0 to an overloaded function that
> expects a pointer?
As I said above, if NULL is defined as (void *)0 it can be passed
if the function expects a void pointer. Not as a wild card, as
I said above.
But that is my PERSONAL OPINION. Obviously, if you disagree we could
discuss about it, and maybe reach an agreement. I repeat:
The "philosophy" of this proposal is to give the MINIMUM set of
changes that needs to be done to get the job done in a minimalistic
way, i.e. one that offers the bare bones functionality.
I think nothing more is really needed.
> If it does, shouldn't your rules talk about those
> cases? Or were you expecting the committee to figure out the exact
> rules by running your compiler?
>
You are right that pointers are not handled well in my proposal.
Thank you for your contribution, really.
If more people here would help me with the specs we could go a lot
farther than just doing polemics...
Thanks
jacob navia
>> My proposal
>> assumes those as a matter of obvious fact!
>
> I am living proof that it is not obvious!
>
Yes. I will change my proposal to accommodate
that and will post it again here.
Keith Thompson
> Wojtek Lerch wrote:
[...]
>> I would also expect a rule that guarantees that NULL will be
>> recognized as a pointer argument, even in the presence of a function
>> declared with a double parameter.
>
> If NULL is defined as (void *)0 the cast forces it as a pointer.
> Obviously you can't expect that a BARE zero will be used as a
> null pointer...
Obviously I *can* expect that a bare 0 is a null pointer constant, and
is interpreted as an expression of pointer type in most contexts that
require such an expression. The one exception I can think of in C as
it's currently defined is an argument to a variadic function, or to a
function with no visible prototype.
If you're adding another case where 0 can't be used as a null pointer
expression, that's probably ok -- but I don't find it obvious.
I suggest that you assume that nothing you haven't explicitly stated
is "obvious", even if it seems obvious to you.
Wojtek Lerch
> Wojtek Lerch wrote:
>> Another problem I have with your rules is that they never mention any
>> pointer types. That seems to imply that anything other than an exact
>> match is not accepted for pointer arguments; but I would expect function
>> overloading to allow matching a parameter defined as a pointer to a
>> qualified type with an actual argument that points to a less-qualified
>> type;
>
> Mmmm "less qualified" is the key word here. It implies an ascending
> order in "qualified"ness.
A partial order -- the same that applies to assignment and function
arguments in the existing standard. Described more formally in 6.5.16.1#1
for simple assignment:
"both operands are pointers to qualified or unqualified versions of
compatible types, and the type pointed to by the left has all the qualifiers
of the type pointed to by the right"
> Can you tell me with an example what you mean
> here?
void overloaded foo( const char *string );
char *p;
foo( p ); // The type of "p" is NOT "const char*"
In general, I would expect that if a function-call expression is a valid way
to call a regular function with a particular signature, then it should be
considered a possible call to an overloaded function with the same
signature. But from your remark about void pointers I assume that you don't
want to make that promise:
void fun1( void * );
void overloaded fun2( void * );
fun1( "hello" ); // Correct, an implicit conversion occurs
fun2( "hello" ); // Invalid, the type of "hello" is not void*
>> I would also expect to be allowed to mix pointers to void with pointers
>> to other object types.
>
> This is problematic because it would introduce a "wild card".
>
> Suppose:
> int overloaded fn(double *);
> int overloaded fn(long double *);
>
> Now a call appears
> void *p;
>
> fn(p);
>
> p would match ANY pointer...
I thought your rules were that if twoo matches are found, then it's an
error?
>> (And what about mixing pointers that are compatible but different, such
>> as a pointer to an array with a known length and a pointer to an array
>> with an unspecified length?)
>
> Personally I would be against it. The reason is that the user can
> disambiguate things with a cast that forces a choice from the
> different possibilities. Yes, it is less "powerful" but it is
> clearer.
Given that your justification for function overloading is to let programmers
avoid having to remember multiple names for functions that perform similar
operations on different types, I'd say that that gain is completely lost if
programmers will now have to know the exact types of parameters of the
function variant they want to call, and write an explicit cast because the
compiler will not perform the implicit conversions that would normally
happen if the function weren't overloaded. Explicit casts are potentially
much more evil than explicit function names.
>> I would also expect a rule that guarantees that NULL will be recognized
>> as a pointer argument, even in the presence of a function declared with a
>> double parameter.
>
> If NULL is defined as (void *)0 the cast forces it as a pointer.
> Obviously you can't expect that a BARE zero will be used as a
> null pointer...
But does your proposal include adding the requirement to the standard that
the type of NULL must be pointer rather than integer?
>> Does your implementation accept any pointer types other than an exact
>> match?
>
> No. I know this may seem like a big limitation, and it is a big
> limitation.
Yes it definitely is. My personal opinion is that it's big enough to make
your proposal unacceptable.
> But I want to avoid any complicated rules. If you
> need it, you just add an explicit cast to the call and you are
> all set!
Another way to avoid complicated rules is to drop your proposal altogether.
;-)
...
> But that is my PERSONAL OPINION. Obviously, if you disagree we could
> discuss about it, and maybe reach an agreement.
This whole proposal is your personal opinion. We're not designing it
together. We don't need to reach an agreement. At best, I can offer you my
personal opinions to try to change yours. But whatever comes out of it,
your proposal will be signed with your name, not mine.
Wojtek Lerch
news:ln3aml1...@nuthaus.mib.org...
> jacob navia <ja...@nospam.com> writes:
>> Wojtek Lerch wrote:
> [...]
>>> I would also expect a rule that guarantees that NULL will be
>>> recognized as a pointer argument, even in the presence of a function
>>> declared with a double parameter.
>>
>> If NULL is defined as (void *)0 the cast forces it as a pointer.
>> Obviously you can't expect that a BARE zero will be used as a
>> null pointer...
> [...]
>
> Obviously I *can* expect that a bare 0 is a null pointer constant, and
> is interpreted as an expression of pointer type in most contexts that
> require such an expression. The one exception I can think of in C as
> it's currently defined is an argument to a variadic function, or to a
> function with no visible prototype.
Right. A bare 0 is interpreted as a pointer where a pointer is known to be
required. In contexts where an int isn't forbidden by the syntax or a
constraint, a bare zero is interpreted as an int -- even if that causes
undefined behaviour.
> If you're adding another case where 0 can't be used as a null pointer
> expression, that's probably ok -- but I don't find it obvious.
In cases where a bare 0 matches a pointer parameter of one variant of an
overloaded function and a numeric parameter of another, I would find it
acceptable to either declare the call ambiguous and fail, or pick the
variant with a numeric parameter -- provided that in the latter case a new
rule is added to the standard that guarantees that NULL must have a pointer
type.
> I suggest that you assume that nothing you haven't explicitly stated
> is "obvious", even if it seems obvious to you.
That's definitely good advice. :-)
jacob navia
In your example the designer of the overloaded function
specified a void pointer, and NOT a char *. If you make
this (admittedly rather strange) requirement, why should
the compiler tell the overloaded function otherwise?
Note that the example function you propose:
fun1(void *);
will never be able to do ANYTHING with that pointer besides passing it
along to some other function!
Of course there are functions that need a void pointer. free() for
instance. But why overloading them?
Currently in standard C if you define
void fn(void *);
you can pass it ANY pointer, it is generic already. Why would you
need a generic function?
I do not see the practical requirement to have this pointer
promotion. Is there some actual requirement in a specific
real life situation that would require this?
I would be more convinced if I would see a good example
where this is necessary.
>>> I would also expect to be allowed to mix pointers to void with
>>> pointers to other object types.
>>
>> This is problematic because it would introduce a "wild card".
>>
>> Suppose:
>> int overloaded fn(double *);
>> int overloaded fn(long double *);
>>
>> Now a call appears
>> void *p;
>>
>> fn(p);
>>
>> p would match ANY pointer...
>
> I thought your rules were that if twoo matches are found, then it's an
> error?
>
Yes, so the call would never work for all of the rest
of the overloaded functions!
>>> (And what about mixing pointers that are compatible but different,
>>> such as a pointer to an array with a known length and a pointer to an
>>> array with an unspecified length?)
>>
>> Personally I would be against it. The reason is that the user can
>> disambiguate things with a cast that forces a choice from the
>> different possibilities. Yes, it is less "powerful" but it is
>> clearer.
>
> Given that your justification for function overloading is to let
> programmers avoid having to remember multiple names for functions that
> perform similar operations on different types, I'd say that that gain is
> completely lost if programmers will now have to know the exact types of
> parameters of the function variant they want to call, and write an
> explicit cast because the compiler will not perform the implicit
> conversions that would normally happen if the function weren't
> overloaded.
This is absolutely not true. I specified a LOT of conversions,
specially for numbers and actual types!
What I see as problematic is automatic pointer conversion!
> Explicit casts are potentially much more evil than explicit
> function names.
>
Yes, so why use them?
Avoid such ambiguities with a set of overloaded functions
that cover all cases you want to handle in your functions.
>>> I would also expect a rule that guarantees that NULL will be
>>> recognized as a pointer argument, even in the presence of a function
>>> declared with a double parameter.
>>
>> If NULL is defined as (void *)0 the cast forces it as a pointer.
>> Obviously you can't expect that a BARE zero will be used as a
>> null pointer...
>
> But does your proposal include adding the requirement to the standard
> that the type of NULL must be pointer rather than integer?
>
No. Actually, after reading the post of Mr Thomson in this same
thread I think that overloaded function arguments should be just
another case of the variable arguments functions (what argument type
promotions are concerned) and that exactly those rules should apply
to step 2.
>>> Does your implementation accept any pointer types other than an exact
>>> match?
>>
>> No. I know this may seem like a big limitation, and it is a big
>> limitation.
>
> Yes it definitely is. My personal opinion is that it's big enough to
> make your proposal unacceptable.
>
Why?
Unacceptable for what?
I have used it extensively specially for numerical software and
it works like a charm. Many applications are possible. I do not
see why you should be forced to promote pointers.
I see however that some pointer promotions may be useful,
for instance using signed/unsigned char pointers as equivalent.
But it surely should not be the case between signed and unsigned
shorts/ints/longs etc.
Promoting pointers to float into pointers to double would be
a catastrophe...
Can you show me a place where pointer promotion is really needed?
>> But I want to avoid any complicated rules. If you
>> need it, you just add an explicit cast to the call and you are
>> all set!
>
> Another way to avoid complicated rules is to drop your proposal
> altogether. ;-)
>
Well, that is what many people "propose". Let's do nothing because
if we do something to improve the power of expression of the
language it will be bad because it will miss feature XXX that
is present in C++ or whatever other language I like.
I remark that you skip the parts of my message where I gave the
basic philosophy of the proposal and why I do not want pointer
promotion.
> ...
>> But that is my PERSONAL OPINION. Obviously, if you disagree we could
>> discuss about it, and maybe reach an agreement.
>
> This whole proposal is your personal opinion. We're not designing it
> together. We don't need to reach an agreement. At best, I can offer
> you my personal opinions to try to change yours. But whatever comes out
> of it, your proposal will be signed with your name, not mine.
>
Nobody was asking you any signature.
james...@verizon.net
> James Kuyper wrote:
...
>
> Great. So either it is perfect or it not perfect.
No, it either conforms or it does not conform. Perfection involves
many things other than conformance, such as cost, reliability,
performance, maintainability, etc.
> The slightest problem, non-implemented feature and there you
> go.
I would consider an implementation to be reasonably well conforming,
for practical purposes, if all non-conformance consisted of minor
features that malfunction only under obscure circumstances, so long as
none of the non-conformance is deliberate, or due to misunderstanding
the requirements on conforming behavior. lcc-win doesn't qualify even
under this more relaxed criterion.
It's failure to conform to C99 is understandable, given how few other
compilers conform. What is obnoxious is failing to fully conform to
C99 while criticizing the committee for failing to make C99 even more
innovative, which would have made it correspondingly harder to
implement.
lcc-win's failure to conform to C90 consists mainly of the fact that
it supports C99 features that require diagnostic messages if compiled
by a conforming implementation of C90. There's no reason why you have
to conform to C90 in this fashion, it's a perfectly legitimate option
for you to design lcc-win so it does not fully conform to any standard
you don't want it to conform to; but the price you pay for choosing
that option is that you can't claim full conformance to C90.
> False. The 89 standard is supported.
>
>
> > It can't be exaggerated or minimized.
> > If I'd made a comparative statement like "poorly conforms" or "almost
> > conforms", then exaggeration or minimization could be an issue. Can you
> > specify any version of the C standard to which lcc-win fully conforms?
> >
> > I'll grant you, fully conforming implementations of C99 are sufficiently
> > rare that "nearly conforming" implementations are still to be valued.
> > But fully conforming implementations of C90 + the 1994 TCs are
> > commonplace, and almost every C compiler is intended to fully conform
> > to C90 in some mode. When they fail to conform, it is usually due to
> > incorrectly implementing the requirements, not a deliberate decision not
> > to implement them, and not due to ignorance of what those requirements are.
> >
>
> I will not work trying to take out // comments in some special C89
> mode. I will just not do it. You (and the "regulars" of comp.lang.c)
> have just a big prejudice against lcc-win. Why?
Because you discuss lcc-win on a comp.lang.c instead of comp.lang.lcc.
Because you have an attitude toward language standards that is
incompatible with creating the kind of compiler I'd have any interest
in using. Because your statements about what constitutes good and bad
coding practices are in serious conflict with my own understanding of
the issue, such that I would never want to rely upon any code written
by you, using what you consider good coding practice, for anything of
any importance.
> Obvious. It runs under MS windows, as everybody knows, only MS slaves
> use that system (etc etc).
I don't like MS, and I don't like Windows. But there's a lot of people
who've done good programming work despite having to cope with the
defects of that operating system. What I have against you is that your
own words have condemned you as not having the right attitudes to fall
into that category.
...
> > No, there's nothing unusual about being surprised by bugs. What is
> > surprising is that the bugs existed because of a failure to understand
> > what the correct behavior should be rather than because you failed to
> > implement a correct understanding of the behavior. The relatively
> > elementary nature of many of those bugs also tends to reduce my
> > confidence in the quality of your compiler.
> >
>
> What the hell are you talking about?
> What feature is missing?
I didn't say missing, I said incorrectly understood.
...
> int long works in lcc-win. Download it and speak later.
Sorry - I originally wrote "int long long", but decided to shorten
that to "int long", so it would apply equally well to C90 as to C99.
Your own explanation of why lcc-win mishandled "int long long" seemed
to imply that it also mishandled "int long". For the same reason, I
thought you also strongly implied that it mishandled "double long". If
lcc-win has always handled both of those types correctly, then my
criticism is restricted to C99, because lcc-win most definitely did
mishandle "int long long" (I don't know if you've fixed that yet).
> It is interesting that an obscure sentence somewhere in the standard
> raises so much problems for you.
Mainly because that is one of the least obscure statements in the
standard. The fact that you misinterpreted that one implies a
significant probability that you've also misinterpreted one or more of
the more obscure ones.
...
> >> You haven't even used my system. ...
> >
> > Well, that's primarily because your system targets a limited market, one
> > that doesn't include any machine I'm currently programming for.
>
> Yes, I only have versions for windows, linux and AIX.
My apologies; the noxious way in which you respond to polite criticism
on comp.lang.c has given me no incentive to check out the details of
your compiler. I incorrectly concluded that the "win" in lcc-win meant
that it was only available for windows. You've frequently argued that
various things which are not guaranteed to be true by the standard are
in fact true on every platform of importance; since some of those
claims referred to things which are not true on most Linux platforms,
I presumed that you had little or no experience with those platforms,
or at least did not consider them important enough to justify creating
an lcc-win implementation for them. I apologize for making incorrect
assumptions.
I still have insufficient incentive to justify trying it out. The way
you behave in c.l.c is sufficient reason for me to doubt both your
competence, and the quality of your implementation.
...
> No. My personal use doesn't say anything about how capable is the
> system for other uses.
I was merely explaining why I thought I didn't have access to a
suitable platform for testing your software. As it turns out, I was
incorrect.
...
> Your friends of comp.lang.c, that have started a denigration campaign
> against my software, mainly because I have dared to see this language
> not as a completely DEAD thing but to propose changes, and implement them.
There's no way I can be sure of the motives of any one's behavior
except my own (and sometimes even my own motivations are obscure).
However, as far as I can see the denigration you've received has been
fully justified by features of your software and by the way in which
you mishandle criticism.
There's nothing wrong with implementing changes; that is entirely and
properly the way to start the process of making them part of the
standard. However, I'd strongly recommend fully implementing at least
one version of the standard before you start innovating. Until you've
fully implemented a standard, it will be hard for you to fully
comprehend what the implications are of your proposed changes to that
standard.
jacob navia
> jacob navia wrote:
>> James Kuyper wrote:
> ...
>>> Conformance is a yes/no question.
>> Great. So either it is perfect or it not perfect.
>
> No, it either conforms or it does not conform. Perfection involves
> many things other than conformance, such as cost, reliability,
> performance, maintainability, etc.
>
>> The slightest problem, non-implemented feature and there you
>> go.
>
> I would consider an implementation to be reasonably well conforming,
> for practical purposes, if all non-conformance consisted of minor
> features that malfunction only under obscure circumstances, so long as
> none of the non-conformance is deliberate, or due to misunderstanding
> the requirements on conforming behavior. lcc-win doesn't qualify even
> under this more relaxed criterion.
>
> It's failure to conform to C99 is understandable, given how few other
> compilers conform. What is obnoxious is failing to fully conform to
> C99 while criticizing the committee for failing to make C99 even more
> innovative, which would have made it correspondingly harder to
> implement.
>
The contrary is the case. Operator overloading would allow
complex numbers to be eliminated from the language, making
it smaller but more powerful.
Complex numbers within the context of C make all the
trouble of implementing them to go to the compiler and
run time library, what makes the implementation
impossible to modify for the user.
There are some users of complex numbers that prefer accuracy,
others prefer speed, others prefer security under extreme
conditions, checks for overflow, whatever!
Putting complex numbers in the language itself makes the
implementation MUCH more difficult.
> lcc-win's failure to conform to C90 consists mainly of the fact that
> it supports C99 features that require diagnostic messages if compiled
> by a conforming implementation of C90.
Yes. And I will not start working to implement an obsolete standard.
I wrote:
>> I will not work trying to take out // comments in some special C89
>> mode. I will just not do it. You (and the "regulars" of comp.lang.c)
>> have just a big prejudice against lcc-win. Why?
>
You wrote:
> Because you discuss lcc-win on a comp.lang.c instead of comp.lang.lcc.
It is my right to discuss anything I think worthwhile in
comp.lang.c.
> Because you have an attitude toward language standards that is
> incompatible with creating the kind of compiler I'd have any interest
> in using.
Well, then, do not use it! Nobody is forcing you anything!
> Because your statements about what constitutes good and bad
> coding practices are in serious conflict with my own understanding of
> the issue, such that I would never want to rely upon any code written
> by you, using what you consider good coding practice, for anything of
> any importance.
>
???
You disagree with me. It is your right. No reason to get upset
and try to scream HELL HELL when you see anything that I do.
>> Obvious. It runs under MS windows, as everybody knows, only MS slaves
>> use that system (etc etc).
>
> I don't like MS, and I don't like Windows.
It would have been difficult to say otherwise!
> But there's a lot of people
> who've done good programming work despite having to cope with the
> defects of that operating system. What I have against you is that your
> own words have condemned you as not having the right attitudes to fall
> into that category.
>
> ...
>>> No, there's nothing unusual about being surprised by bugs. What is
>>> surprising is that the bugs existed because of a failure to understand
>>> what the correct behavior should be rather than because you failed to
>>> implement a correct understanding of the behavior. The relatively
>>> elementary nature of many of those bugs also tends to reduce my
>>> confidence in the quality of your compiler.
>>>
>> What the hell are you talking about?
>> What feature is missing?
>
> I didn't say missing, I said incorrectly understood.
Look. I am not James Kuyper. I do misunderstand things sometimes.
I even do mistakes (and get surprised when bugs hit me).
You see?
I am just a normal guy, not the most intelligent person in the world.
>
> ...
>> int long works in lcc-win. Download it and speak later.
>
> Sorry - I originally wrote "int long long", but decided to shorten
> that to "int long", so it would apply equally well to C90 as to C99.
> Your own explanation of why lcc-win mishandled "int long long" seemed
> to imply that it also mishandled "int long". For the same reason, I
> thought you also strongly implied that it mishandled "double long". If
> lcc-win has always handled both of those types correctly, then my
> criticism is restricted to C99, because lcc-win most definitely did
> mishandle "int long long" (I don't know if you've fixed that yet).
>
So, you are arguing against my old bugs. GREAT!
[big snip]
>
> I still have insufficient incentive to justify trying it out. The way
> you behave in c.l.c is sufficient reason for me to doubt both your
> competence, and the quality of your implementation.
>
I misbehave in comp.lang.c. For instance when people start insulting
my family members, when insult after insult against me personally
is being published by the same people that belong to your clique.
When articles like
"The problem of jacob"
are published and discussed at length, and a LONG etc.
THEN you say:
*I* misbehave in comp.lang.c.
>
> There's no way I can be sure of the motives of any one's behavior
> except my own (and sometimes even my own motivations are obscure).
> However, as far as I can see the denigration you've received has been
> fully justified by features of your software and by the way in which
> you mishandle criticism.
>
So, proposing operator overloading is a justification for
denigrating someone. GREAT Mr Kuyper.
I think further discussions with you are just useless.
Lets say (politely) that you disagree with me.
Wojtek Lerch
> Wojtek Lerch wrote:
>> "jacob navia" <ja...@nospam.com> wrote in message
>> news:g4tl47$7gu$1...@aioe.org...
>>> Wojtek Lerch wrote:
>>>> Another problem I have with your rules is that they never mention any
>>>> pointer types. That seems to imply that anything other than an exact
>>>> match is not accepted for pointer arguments; but I would expect
>>>> function overloading to allow matching a parameter defined as a pointer
>>>> to a qualified type with an actual argument that points to a
>>>> less-qualified type;
>>> Can you tell me with an example what you mean
>>> here?
>>
>> void overloaded foo( const char *string );
>> char *p;
>> foo( p ); // The type of "p" is NOT "const char*"
Did you forget to comment on this one?
>> In general, I would expect that if a function-call expression is a valid
>> way to call a regular function with a particular signature, then it
>> should be considered a possible call to an overloaded function with the
>> same signature. But from your remark about void pointers I assume that
>> you don't want to make that promise:
>>
>> void fun1( void * );
>> void overloaded fun2( void * );
>>
>> fun1( "hello" ); // Correct, an implicit conversion occurs
>> fun2( "hello" ); // Invalid, the type of "hello" is not void*
>
> In your example the designer of the overloaded function
> specified a void pointer, and NOT a char *. If you make
> this (admittedly rather strange) requirement, why should
> the compiler tell the overloaded function otherwise?
What requirement? That you can pass a char* to a function that takes a
void*? What's so strange about it? C has allowed it since void was
invented.
> Note that the example function you propose:
>
> fun1(void *);
>
> will never be able to do ANYTHING with that pointer besides passing it
> along to some other function!
Why wouldn't it be able to convert it to a different pointer type? And then
maybe do something with the result?
Don't forget this is just an example. Its purpose was not to demonstrate
the usefulness of void pointers. In real life, a function could have more
arguments. And, most likely, a different name.
> Of course there are functions that need a void pointer. free() for
> instance. But why overloading them?
>
> Currently in standard C if you define
>
> void fn(void *);
>
> you can pass it ANY pointer, it is generic already. Why would you
> need a generic function?
It's your claim that generic functions are worth adding to C, not mine. But
imagine a case like this:
void overloaded writedata( struct stream1 *stream, const void *buf, size_t
buflen );
void overloaded writedata( struct stream2 *stream, const void *buf, size_t
buflen );
Does this sound like a potentially legitimate pattern of using overloaded
functions?
>> Given that your justification for function overloading is to let
>> programmers avoid having to remember multiple names for functions that
>> perform similar operations on different types, I'd say that that gain is
>> completely lost if programmers will now have to know the exact types of
>> parameters of the function variant they want to call, and write an
>> explicit cast because the compiler will not perform the implicit
>> conversions that would normally happen if the function weren't
>> overloaded.
>
> This is absolutely not true. I specified a LOT of conversions,
> specially for numbers and actual types!
>
> What I see as problematic is automatic pointer conversion!
>
>> Explicit casts are potentially much more evil than explicit function
>> names.
>>
>
> Yes, so why use them?
Because if you insist on exact matching of pointer types, something as
simple as
void overloaded fun( const char *string );
fun( "Hello" );
doesn't work without an explicit cast (or a temporary variable with the
matching type).
> Avoid such ambiguities with a set of overloaded functions
> that cover all cases you want to handle in your functions.
You mean you want me to have two functions, one that takes a pointer to
const and the other a pointer to non-const? What if the function needs
three pointer parameters -- will I have to write eight identical functions
just to avoid explicit casts?
>>>> Does your implementation accept any pointer types other than an exact
>>>> match?
>>>
>>> No. I know this may seem like a big limitation, and it is a big
>>> limitation.
>>
>> Yes it definitely is. My personal opinion is that it's big enough to
>> make your proposal unacceptable.
>
> Why?
Because it introduces too many restrictions to how an overloaded function
can be called, compared to how an equivalent normal function can be called
today.
> Unacceptable for what?
Unacceptable for adding to the standard. If I were on the committee, I'd
vote against any proposal that introduced similar limitations.
> I have used it extensively specially for numerical software and
> it works like a charm. Many applications are possible. I do not
> see why you should be forced to promote pointers.
>
> I see however that some pointer promotions may be useful,
> for instance using signed/unsigned char pointers as equivalent.
I'm not promoting "pointer promotions", whatever exactly you mean by that;
all I'm saying is that those implicit conversions that already happen in a
call to a normal function should also have a chance of happening in a call
to an overloaded function. My expectation is that a function that is
declared as overloaded but has only one variant should behave identically to
a regular function. There's no need to invent new "pointer promotions" or
introduce an equivalence between signed/unsigned pointers or any other
unnecessary differences between overloaded functions and normal functions.
Differences beteween the behaviour of two kinds of functions should be kept
to a minimum.
> Can you show me a place where pointer promotion is really needed?
I don't know if you consider the implicit pointer conversions that C already
applies to assignment and argument passing to be "really needed"; but in my
personal opinion, they are.
>>> But I want to avoid any complicated rules. If you
>>> need it, you just add an explicit cast to the call and you are
>>> all set!
>>
>> Another way to avoid complicated rules is to drop your proposal
>> altogether. ;-)
>
> Well, that is what many people "propose". Let's do nothing because
> if we do something to improve the power of expression of the
> language it will be bad because it will miss feature XXX that
> is present in C++ or whatever other language I like.
I don't know about anybody who proposes just that; but I do agree that doing
nothing is better than dumping a half-baked, under-specified "proposal" on
the committee and insisting that they write a proper specification for it
and force all compilers to implement it.
> I remark that you skip the parts of my message where I gave the
> basic philosophy of the proposal and why I do not want pointer
> promotion.
I'm still waiting for an explanation of why you don't want let me pass a
char* to a function that takes a const char* -- or did I miss it?
lawrenc...@siemens.com
>
> If you mean that old architectures that faded away and are now
> considered exotic will come back, that's not very likely for any
> particular architectural feature (though there's such a large variety of
> features that at least one of them probably will be revived, sooner or
> later).
Two words: decimal arithmetic.
-- Larry Jones
It's no fun to play games with a poor sport. -- Calvin
jacob navia
>>>> Can you tell me with an example what you mean
>>>> here?
>>>
>>> void overloaded foo( const char *string );
>>> char *p;
>>> foo( p ); // The type of "p" is NOT "const char*"
>
> Did you forget to comment on this one?
>
I did it in another message
[snip]
> It's your claim that generic functions are worth adding to C, not mine.
> But imagine a case like this:
>
> void overloaded writedata( struct stream1 *stream, const void *buf,
> size_t buflen );
> void overloaded writedata( struct stream2 *stream, const void *buf,
> size_t buflen );
>
> Does this sound like a potentially legitimate pattern of using
> overloaded functions?
>
Pressumably, the objective is to write an object into a buffer.
It would be better if we had
void overloaded writedata(struct stream1 *stream, const struct stream1
*buf, size_t buflen );
void overloaded writedata( struct stream2 *stream, const struct stream2
*buf, size_t buflen );
Isn't it?
> I'm not promoting "pointer promotions", whatever exactly you mean by
> that; all I'm saying is that those implicit conversions that already
> happen in a call to a normal function should also have a chance of
> happening in a call to an overloaded function.
You have a point here actually. I will try to figure out the
consequences of doing that.
The problem is to figure out all the consequences of those promotions in
this context.
Wojtek Lerch
> Wojtek Lerch wrote:
>>>>
>>>> void overloaded foo( const char *string );
>>>> char *p;
>>>> foo( p ); // The type of "p" is NOT "const char*"
>>
>> Did you forget to comment on this one?
>
> I did it in another message
The only reply to that message that I can see is the one where you wrote
nothing under the above example, and commented on pointers to void under the
example that followed. Was there another message that I somehow missed?
Would you mind repeating your comment?
> [snip]
>
>> It's your claim that generic functions are worth adding to C, not mine.
>> But imagine a case like this:
>>
>> void overloaded writedata( struct stream1 *stream, const void *buf,
>> size_t buflen );
>> void overloaded writedata( struct stream2 *stream, const void *buf,
>> size_t buflen );
>>
>> Does this sound like a potentially legitimate pattern of using overloaded
>> functions?
>>
>
> Pressumably, the objective is to write an object into a buffer.
No, it's to write a buffer of data to a stream. Something like fwrite() or
the POSIX write(), except the stream is not the standard FILE but a
user-defined type. Imagine, for instance, that they save the data to a text
file, using two different encodings (such as uuencode and base64, for
instance).
>> I'm not promoting "pointer promotions", whatever exactly you mean by
>> that; all I'm saying is that those implicit conversions that already
>> happen in a call to a normal function should also have a chance of
>> happening in a call to an overloaded function.
>
> You have a point here actually. I will try to figure out the consequences
> of doing that.
>
> The problem is to figure out all the consequences of those promotions in
> this context.
Of course, and their interactions with the rules of overload resolution.
That's why those rules are the trieckiest and most important part of any
specification of overloaded functions. Given that you have changed your
mind about those rules at least twice today, I'd say that you still have a
few details to work out.
santosh
>> ...
>>> int long works in lcc-win. Download it and speak later.
>>
>> Sorry - I originally wrote "int long long", but decided to shorten
>> that to "int long", so it would apply equally well to C90 as to C99.
>> Your own explanation of why lcc-win mishandled "int long long" seemed
>> to imply that it also mishandled "int long". For the same reason, I
>> thought you also strongly implied that it mishandled "double long".
>> If lcc-win has always handled both of those types correctly, then my
>> criticism is restricted to C99, because lcc-win most definitely did
>> mishandle "int long long" (I don't know if you've fixed that yet).
>>
>
> So, you are arguing against my old bugs. GREAT!
Perhaps the specific case of int long long has been fixed, but there
still seems to be some problems with other similar declarations.
Consider:
int main(void) {
int long volatile long s = 100;
return 0;
}
lcc-win says:
Error test.c: 13 multiple types in a declaration. Last will be
used: 'long'
1 error, 0 warnings
My copy of lcc-win was downloaded about twenty days ago. Perhaps this
has been fixed by now?
James Kuyper
>> it supports C99 features that require diagnostic messages if compiled
>> by a conforming implementation of C90.
>
> Yes. And I will not start working to implement an obsolete standard.
You've every right to make that decision; but the consequence of that
decision is that you can't claim conformance to that standard.
...
> It is my right to discuss anything I think worthwhile in
> comp.lang.c.
Yes, it's a unmoderated newgroup - you are free to post anything to it
that you want to, and I have the same freedom to despise your lack of
respect for topicality.
>> Because you have an attitude toward language standards that is
>> incompatible with creating the kind of compiler I'd have any interest
>> in using.
>
> Well, then, do not use it! Nobody is forcing you anything!
I don't use it, and I made no claim that anyone was forcing me to use
it. You asked why I disliked lcc-win, and I told you. If you didn't want
to know, you shouldn't have asked.
>> Because your statements about what constitutes good and bad
>> coding practices are in serious conflict with my own understanding of
>> the issue, such that I would never want to rely upon any code written
>> by you, using what you consider good coding practice, for anything of
>> any importance.
>>
>
> ???
> You disagree with me. It is your right. No reason to get upset
> and try to scream HELL HELL when you see anything that I do.
I didn't go scream "HELL HELL" - I think you'll find that I've never
posted any message, to this newsgroup or any other, using that word (or
any other) as a swear word. You asked me the reason for my "prejudice"
against lcc-win, and that "disagreement" is a key part of it.
...
>>>> No, there's nothing unusual about being surprised by bugs. What is
>>>> surprising is that the bugs existed because of a failure to understand
>>>> what the correct behavior should be rather than because you failed to
>>>> implement a correct understanding of the behavior. The relatively
>>>> elementary nature of many of those bugs also tends to reduce my
>>>> confidence in the quality of your compiler.
>>>>
>>> What the hell are you talking about?
>>> What feature is missing?
>>
>> I didn't say missing, I said incorrectly understood.
>
> Look. I am not James Kuyper. I do misunderstand things sometimes.
> I even do mistakes (and get surprised when bugs hit me).
>
> You see?
>
> I am just a normal guy, not the most intelligent person in the world.
I never claimed perfection; I've frequently made mistakes, and the
message you're responding to admits to several of them. You'll find that
this is not a rare thing in my posting history.
I never criticized you for lacking perfection. I criticized you for not
even coming close to perfection, and for failing to graciously accept
the validity of complaints about that lack of perfection.
>>> int long works in lcc-win. Download it and speak later.
>>
>> Sorry - I originally wrote "int long long", but decided to shorten
>> that to "int long", so it would apply equally well to C90 as to C99.
>> Your own explanation of why lcc-win mishandled "int long long" seemed
>> to imply that it also mishandled "int long". For the same reason, I
>> thought you also strongly implied that it mishandled "double long". If
>> lcc-win has always handled both of those types correctly, then my
>> criticism is restricted to C99, because lcc-win most definitely did
>> mishandle "int long long" (I don't know if you've fixed that yet).
>>
>
> So, you are arguing against my old bugs. GREAT!
Old? The messages in which you came to this very newsgroup asking it to
confirm your misunderstanding are only a little over a month old!
But that's besides the point. It isn't the age of the bug that is
relevant. It was the fact that this is merely one of the most recent and
most egregious examples of a habitual pattern of misunderstanding the
standard's requirements. The fact that it is a fairly new bug merely
shows that this pattern continues to this very day.
>> I still have insufficient incentive to justify trying it out. The way
>> you behave in c.l.c is sufficient reason for me to doubt both your
>> competence, and the quality of your implementation.
>>
>
>
> I misbehave in comp.lang.c. For instance when people start insulting
> my family members, when insult after insult against me personally
> is being published by the same people that belong to your clique.
You misbehave by responding to every report of any problem with lcc-win
as if it were a personal attack. Some of them may be, but you show no
sign of discriminating in your responses to them.
I tracked down the most serious charge you've raised about personal
insults - and found that it was due to someone who was unfamiliar with
the existence non-pornographic manga, and therefore misunderstood the
implications of your statement that your daughter made a habit of
visiting manga web-sites. He apologized for his mistake less than a day
after having first been informed of it, which is pretty much
"immediately" by usenet standards. You did not even acknowledge his
apology, much less accept it.
If you're unwilling to even consider the possibility of such ignorance,
you'll never believe his explanation, but it strikes me as quite
plausible. I've known many people with comparable misunderstandings of
things they'd only heard about third hand.
...
> So, proposing operator overloading is a justification for
> denigrating someone. GREAT Mr Kuyper.
If it's a bad proposal, it should be denigrated. If you've a habit of
making bad proposals, your skills as a proposal maker should be
denigrated. I can't see any fault in that.
jacob navia
No, it will be fixed when I have some time.
jacob navia
> Of course, and their interactions with the rules of overload resolution.
> That's why those rules are the trieckiest and most important part of any
> specification of overloaded functions. Given that you have changed your
> mind about those rules at least twice today, I'd say that you still have
> a few details to work out.
>
Look Mr
I haven't changed my mind about anything. You have raised some valid
points and I will consider your viewpoint.
That is an obvious reason to laugh at my proposal, adopt an ironic
tone etc.
This discussion with you then, has no longer any sense.
Jack Klein
wrote in comp.std.c:
> Jack Klein wrote:
> > On Sun, 06 Jul 2008 22:33:06 +0200, jacob navia <ja...@nospam.com>
> > wrote in comp.std.c:
> >
> > [big snip]
> >
> >> Unnecessary yes, but it could be that you just consider that
> >> refusing to standardize obvious stuff like directory access for
> >> instance, or other features that are present in MOST platforms
> >> even in modern embedded systems just destroys any evolution of the
> >> language.
> >
> > Oh Jacob, there you go again.
> >
> > Please provide evidence for your assertion that directory access is
> > present in "MOST", particularly "even in modern embedded systems".
> >
> > Just once, let's see you back up one of your rants with some
> > verifiable facts.
> >
>
> MSDOS is an OS used very often in embedded systems.
> It has directories since at least 20 years
>
> Linux is used in many embedded systems, specially in systems like
> the iphone, and others. It has been ported to consoles like
> the play station, and many other hardware.
>
> Linux has directories.
>
> Directories are a normal feature of operating systems since
> several decades now.
>
> Obviously all windows+Linux+MacIntosh+Sun workstations do not count
> for you. They have directories.
>
> The QNX real time OS features ext2-ext3 or FAT or NTFS file systems
> for EPROM embedded file systems.
> (http://www.qnx.com/products/neutrino_rtos/fsys.html)
>
> I could go on, but I think it is better that YOU tell us what
> significant file system today does NOT have any directories.
You are answering a question I did not ask. My fault, I suppose, I
shouldn't have bothered in the first place.
I asked:
Please provide evidence for your assertion that directory access is
present in "MOST", particularly "even in modern embedded systems".
You replied:
I could go on, but I think it is better that YOU tell us what
significant file system today does NOT have any directories.
Where in my question did you see the phrase "file system", with or
without the adjective "significant"? That phrase did not appear your
post I replied to, and it certainly did not appear in my response.
Your statement was, requoted from above:
> >> Unnecessary yes, but it could be that you just consider that
> >> refusing to standardize obvious stuff like directory access for
> >> instance, or other features that are present in MOST platforms
> >> even in modern embedded systems just destroys any evolution of the
> >> language.
I was not questioning whether or not most file systems supported
directories. I was questioning you assertion that "MOST platforms",
even "modern embedded systems", have directory access.
Since embedded systems do not use file systems at all, they do not
have directory access.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
jacob navia
>
> Since embedded systems do not use file systems at all, they do not
> have directory access.
>
Well, having shown us your great knowledge of embedded systems today,
let's stop this conversation with that statement.
Embedded EPROM file systems are just so universal now, that such a
statement just reflects your real world knowledge.
Of course I can recommend you a site that will tell you all the
different EPROM/DISK/ etc file systems available today for embedded
systems:
Happy hunting!
Ian Collins
> Douglas A. Gwyn wrote:
>
>> There has been some
>> discussion of tweaking the C1x charter to state that unnecessary
>> restrictions on the architecture/platform should be avoided.
>>
> Unnecessary yes, but it could be that you just consider that
> refusing to standardize obvious stuff like directory access for
> instance, or other features that are present in MOST platforms
> even in modern embedded systems just destroys any evolution of the
> language.
>
the case, there are tend to be well established standards (two being
POSIX and the windows API) which extend the C language standard.
Attempting to introduce yet another version is a doomed exercise.
--
Ian Collins.
jacob navia
Why?
The proposal of http://david.tribble.com/text/c0xdir.html
looks quite K to me. What have you against it?
jacob navia
I agree that most 8 bit microprocessors have no file system.
I developed 2 years ago a version of lcc-win for a 16 Bit
DSP. There was no file system. I know that. But tell me:
Do you really propose dropping fopen/fread/fwrite/fclose ???
Those functions have no business in a no file system C implementation.
I think you do not propose that, at least I haven't seen you
proposing that.
It is obvious that a no file system implementation will be one without
all those functions, or all those functions implemented as stubs
that return an error code.
Why can't we standardize a directory accessing API? No file system
implementations will just add several stubs to the fopen/fclose stubs.
Absolutely nothing is lost, no one is harmed, and we have a better
library for the MANY people that use modern file systems today.
You yourself acknowledge that your last implementations used a
file system, and I bet than in 2019, when the next standard is
due, nobody will ever use a processor with less than 1GB of EPROM
and a super multi tasking OS!
Thanks for your attention
Wojtek Lerch
news:kbl974pu8ouicb5hc...@4ax.com...
>
> Warning, this is mostly anecdotal and off-topic and anecdotal, ...
Indeed. This argument originally was about requiring support for
directories in *hosted* implementations of C. A lot of the embedded systems
you're describing are too small to even have a conforming freestanding
implementation of C99.
Ian Collins
> Ian Collins wrote:
>> jacob navia wrote:
>>> Douglas A. Gwyn wrote:
>>>
>>>> There has been some
>>>> discussion of tweaking the C1x charter to state that unnecessary
>>>> restrictions on the architecture/platform should be avoided.
>>>>
>>> Unnecessary yes, but it could be that you just consider that
>>> refusing to standardize obvious stuff like directory access for
>>> instance, or other features that are present in MOST platforms
>>> even in modern embedded systems just destroys any evolution of the
>>> language.
>>>
>> That (present in MOST platforms) is part of the problem. Where that is
>> the case, there are tend to be well established standards (two being
>> POSIX and the windows API) which extend the C language standard.
>>
>> Attempting to introduce yet another version is a doomed exercise.
>>
>
> Why?
>
> The proposal of http://david.tribble.com/text/c0xdir.html
> looks quite K to me. What have you against it?
>
using the POSIX API would use the functions is another question. I
guess the point I was trying to make is systems with directory support
already have established APIs, familiar to programmers on those systems.
--
Ian Collins.
jacob navia
> Nothing, it's a good proposal. Whether anyone using windows or a system
> using the POSIX API would use the functions is another question. I
> guess the point I was trying to make is systems with directory support
> already have established APIs, familiar to programmers on those systems.
>
And they can use those! Nobody is going to put a gun behind their
heads to force them to use something else.
But people that want PORTABLE code, i.e. code that doesn't need to be
rewritten from system to system it would be NICE to have a simple
API that would work in all systems you see?
That is a place where a standard API, even if it is limited and simpler
than the OS API would be quite useful.
Francis Glassborow
> Jack Klein wrote:
>>
>> Since embedded systems do not use file systems at all, they do not
>> have directory access.
>>
>
> Well, having shown us your great knowledge of embedded systems today,
> let's stop this conversation with that statement.
>
> Embedded EPROM file systems are just so universal now, that such a
> statement just reflects your real world knowledge.
>
> Of course I can recommend you a site that will tell you all the
> different EPROM/DISK/ etc file systems available today for embedded
> systems:
>
>
systems have no use for a file system. I would guess this is true of the
overwhelming majority (numerically) of embedded systems (while a sat-nav
probably uses some form of file system the 3 dozen+ processors running
various facilities in a car have absolutely no need for a file system.)
Please get away from the idea that all the world uses ever more complex
embedded systems. much of it uses simple ones ever more frequently.
Ian Collins
But there is a point hidden in the rhetoric, a lot more systems (be they
embedded or otherwise) use file systems than complex maths. So if
something is going to be standardised, make it something useful!
--
Ian Collins.
jacob navia
> And most of us are also well aware that a great number of embedded
> systems have no use for a file system.
My bread machine has 15 different programs with different variants. It
is a appliance that I bought for 40 euros 2 years ago. Obviously
there is a file holding somewhere the programs sequences, that are quite
complex (heat/move motor, stop, start reverse etc)
There isn't maybe a file system but probably a file in EPROM.
Now, from a software maintenance standpoint, using an EPROM
file system compatible with NTFS or ext3 or whatever has an
obvious advantage in allowing people to develop the stuff
in normal PCs and then dump the files into EPROM.
> I would guess this is true of the
> overwhelming majority (numerically) of embedded systems (while a sat-nav
> probably uses some form of file system the 3 dozen+ processors running
> various facilities in a car have absolutely no need for a file system.)
>
Maybe. So what?
You want to drop fopen/fclose???
If they do not have a file system, why would they be bothered by a
function for opening or closing directories?
This ideology of standardizing by the lowest possible system is
hurting the language because it just makes any new development
impossible in C.
If we trim the language so that it will support
the user in an 8 bit microprocessor with no file system, no
console, no floating point, no recursion because only 256 bytes of
stack, then the users in other systems will surely go to other
languages... what is a good thing isn't it? C is dead anyway
so let's kill it quickly and go on to C++.
> Please get away from the idea that all the world uses ever more complex
> embedded systems. much of it uses simple ones ever more frequently.
Why do you want to restrain C to 8 bit processors with no file system?
They may be the majority of microprocessors sold but do they need
any standard C? They will use a crippled version of the language
anyway since if they have no file system fopen/fwrite will not work
anyway!
I just can't understand the logic behind this, other than destroying
any progress in C.
jacob navia
> But there is a point hidden in the rhetoric, a lot more systems (be they
> embedded or otherwise) use file systems than complex maths. So if
> something is going to be standardised, make it something useful!
Complex math is NOT a good thing to standardize. You can do complex math
with several priorities:
1) I want fast complex math, without any accuracy requirements beyond
5-6 digits.
2) I want fast 18 digits accuracy for scientific work
3) I want fail safe behavior with NANs and zeroes. I do not
care about speed.
4) I am doing engineering calculations and need to do some
calculations with 36 digits precision to ensure that the
result is at least 10 digits correct.
How are you going to satisfy them all?
The solution is NOT that the compiler system prescribes an
arbitrary solution to that conflicting requirements but that we
introduce a procedure (operator overloading) that allows
all those users to write THEIR OWN libraries using THEIR
OWN priorities. That is the solution that lcc-win proposed.
Lcc-win proposes a complex maths package that can be configured by the
user to his/her requirements! Why? Because operator overloading
provides the LANGUAGE framework that allows third party libraries
to be built that will be targeted at each of the priorities
above!
Wojtek Lerch
> I haven't changed my mind about anything.
Sorry; I should have written "were convinced to consider a possibility of
changing" or something like that. I apologize for my unrealistic optimism.
> That is an obvious reason to laugh at my proposal, adopt an ironic
> tone etc.
No, that is not. This is.
> This discussion with you then, has no longer any sense.
You have convinced me.
Jack Klein
wrote in comp.std.c:
> Jack Klein wrote:
> >
> > Since embedded systems do not use file systems at all, they do not
> > have directory access.
> >
>
> Well, having shown us your great knowledge of embedded systems today,
> let's stop this conversation with that statement.
>
> Embedded EPROM file systems are just so universal now, that such a
> statement just reflects your real world knowledge.
>
> Of course I can recommend you a site that will tell you all the
> different EPROM/DISK/ etc file systems available today for embedded
> systems:
Warning, this is mostly anecdotal and off-topic and anecdotal, just
another probably futile attempt to expand Jacob's horizons. It
contains little relevance to the C standard.
Jacob,
The first embedded system product I developed was first displayed at
the IMTS (formerly meant "International Machine Tool Show", now
redefined as "International Manufacturing Technology Show") in
September of 1982.
I have made my living for more than 25 years developing embedded
systems.
The largest and most complex executes on a PowerPC core in a Xilinx
FPGA. This system boots MontaVista Linux from a Compact Flash, which
does indeed have several file systems on it, including FAT16 and ext3.
This is the only true embedded system I have ever been involved with
that uses any sort of file system.
The smallest, and also the most recent, uses an 8-bit microcontroller
from Atmel. It has 4K octets of flash memory to hold its program, 512
octets of RAM for stack and variables, and 256 octets of EEPROM, and
is physically 5mm square. It needs exactly 16 octets of persistent
storage, each holding a value between 0 and 16 inclusive.
When the circuit board is assembled, it is connected to a calibration
fixture using a communications interface built into the micro. The
calibration fixture executes a sequence to determine the proper values
for these 16 octets, and gives the micro the values to store.
For the entire rest of the life of this product, it performs only one
function -- when it is powered up, it takes those 16 values from
EEPROM and writes them into 16 hardware devices on the board, actually
controlling the light output of 16 infrared LEDs.
File system? It might actually have been possible to implement some
minimal system in the constraints of limited program space and RAM,
but it would certainly been a waste of time and effort to do so. The
executable image, written in C, merely uses the first 16 octets of the
memory-mapped EEPROM for its 16 values.
I don't want to go on forever with this, I just want you to understand
a few things.
1. The majority of embedded systems do indeed use 8-bit
microcontrollers with only a few thousand octets of program storage
and a few hundred bytes of RAM. They may have, internal to the
microcontroller or on a separate chip, a few hundred or a few thousand
bytes of EEPROM for storage of persistent date.
2. Many more powerful and complex embedded systems use 16-bit or
32-bit microprocessors or microcontrollers or digital signal
processors. Many of these also have flash or EEPROM for persistent
storage.
But the vast majority of these systems have absolutely no need for a
file system. There are no users running arbitrary applications and
creating arbitrary files. What persistent storage they have is used
to store specific parameters relating to the tasks they perform. The
exact type of all data is known at the time the program is written.
There are embedded systems that do use off-the-shelf operating
systems, and use, because they need them, sophisticated file systems.
Operating systems such as Linux, Windows Mobile, Symbian, and many
others. The most common examples are portable devices like cell
phones, GPS units, and PDAs, MP3 players.
While these devices sell in large quantities, they are actually a
minority of the large number of embedded devices designed, built, and
sold every day.
Do you think that the microcontroller inside your PC's keyboard needs
or has a file system? Or the one in your mouse?
What about the microcontroller inside your DVD drive?
Understand, I do not object to your desire to see C evolve and extend,
although I do not agree with it.
What I do object to is your allusions to the nature of embedded
systems, which is clearly a field about which you know little. You
make assertions about them that are generally completely wrong.
Walter Banks
jacob navia wrote:
> You yourself acknowledge that your last implementations used a
> file system, and I bet than in 2019, when the next standard is
> due, nobody will ever use a processor with less than 1GB of EPROM
> and a super multi tasking OS!
Jacob,
As much as I recognize that most of this is in jest. The last file I looked was C
source for a processor blinking led's in a pair of sneakers. In 2019
this code will still be a hundred bytes or less.
My point is that most of the current small applications will continue
to be implemented with little incentive to make them bigger.
w..
santosh
Indeed, and any sufficiently complex system is itself usually made up of
a collection of simpler systems, so small embedded systems aren't going
to go away. It isn't feasible to make every existing embedded system 32
bit with megabytes of memory and file systems and what not. Many are,
but most aren't, and that will probably remain the case, even in the
future.
Keith Thompson
> I agree that most 8 bit microprocessors have no file system.
> I developed 2 years ago a version of lcc-win for a 16 Bit
> DSP. There was no file system. I know that. But tell me:
>
> Do you really propose dropping fopen/fread/fwrite/fclose ???
>
> Those functions have no business in a no file system C implementation.
>
> I think you do not propose that, at least I haven't seen you
> proposing that.
>
> It is obvious that a no file system implementation will be one without
> all those functions, or all those functions implemented as stubs
> that return an error code.
I'm surprised that you don't mention the existing distinction between
freestanding and hosted implementations. As you know, a freestanding
implementation needn't support <stdio.h>, or any other standard header
other than <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>,
<stddef.h>, and <stdint.h>.
If directory access were added to C1X, then presumably it would be
required only for hosted implementations, i.e., ones that already must
support <stdio.h>.
So the question of whether embedded systems have directories is not
particularly relevant. What is relevant is whether most or all
*hosted* implementations have directories. And, as far as I know, the
answer to that is yes. (I think IBM's old MVS mainframe operating
system doesn't have "directories" as such, but it does have similar
constructs that can probably be handled by a directory interface.)
Currently, a hosted implementation needs to be able to open a file
given a string that specifies its name, but the standard says nothing
about how that string is interpreted. A directory interface would add
to that methods for constructing file names and for extracting
directory names from them, among other things.
And if there are rare hosted implementations without directory
support, the appropriate routines could just fail (as is already
possible for file I/O routines) -- or the C implementation could
pretend that everything is in a single directory.
> Why can't we standardize a directory accessing API? No file system
> implementations will just add several stubs to the fopen/fclose stubs.
Because of the distinction between hosted and freestanding
implementations, such stubs aren't even necessary in most cases.
> Absolutely nothing is lost, no one is harmed, and we have a better
> library for the MANY people that use modern file systems today.
Maybe.
Defining a portable interface that works on Unix and Windows isn't too
difficult. Extending it to, say, VMS is a bit trickier. Defining a
directory interface that (a) covers existing systems and doesn't
preclude future changes, (b) provides enough functionality to be
useful without being unwieldy compared to native routines, and (c)
would fit well into the C standard will be really difficult.
The dividing line between what's in the C standard library and what
isn't is often arbitrary. There's no really good fundamental reason
why file access is in the standard and directory access isn't; both
could have been included, or both could have been left to secondary
standards.
Another factor is the fact that POSIX already provides a portable
directory interface, and many operating systems (even ones that aren't
Unix-based) support POSIX. This means that the added value of a
standard C directory interface would be limited to its support on
non-POSIX systems. Maybe that's enough; I have no strong opinion one
way or the other.
I have no real objection to adding directory support to the C
standard, but there are valid reasons *not* to do so. One is, as I
mentioned, that the added benefit might not support the effort
necessary to define and implement it. Another is that each new
feature added to a new C standard makes it more likely that C1X will
suffer the same fate as C99, because vendors aren't sufficiently
motivated to implement it.
> You yourself acknowledge that your last implementations used a
> file system, and I bet than in 2019, when the next standard is
> due, nobody will ever use a processor with less than 1GB of EPROM
> and a super multi tasking OS!
I'm sure you'd lose that bet, for reasons that others have covered.
You probably have a computer with 1GB or so of memory and a super
multi-tasking OS in front of you as you're reading this -- but how
many embedded CPUs are in that system and its peripherals, and how
many of those would benefit from the additional power?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
> Ian Collins wrote:
>> But there is a point hidden in the rhetoric, a lot more systems (be they
>> embedded or otherwise) use file systems than complex maths. So if
>> something is going to be standardised, make it something useful!
>
> Complex math is NOT a good thing to standardize. You can do complex math
> with several priorities:
>
> 1) I want fast complex math, without any accuracy requirements beyond
> 5-6 digits.
>
> 2) I want fast 18 digits accuracy for scientific work
>
> 3) I want fail safe behavior with NANs and zeroes. I do not
> care about speed.
>
> 4) I am doing engineering calculations and need to do some
> calculations with 36 digits precision to ensure that the
> result is at least 10 digits correct.
>
> How are you going to satisfy them all?
All of these apply equally to floating-point. Of course it's too late
now, but would you not have standardized floating-point?
Note that requirements 1 and 2 are already largely satisifed by the
existence of the three different complex types (float _Complex, double
_Complex, and long dobule _Complext), though the latter two aren't
required to support more than 10 decimal digits.
jacob navia
>> You yourself acknowledge that your last implementations used a
>> file system, and I bet than in 2019, when the next standard is
>> due, nobody will ever use a processor with less than 1GB of EPROM
>> and a super multi tasking OS!
>
> I'm sure you'd lose that bet, for reasons that others have covered.
> You probably have a computer with 1GB or so of memory and a super
> multi-tasking OS in front of you as you're reading this -- but how
> many embedded CPUs are in that system and its peripherals, and how
> many of those would benefit from the additional power?
>
They will not benefit at all, but they will be there for OTHER reasons.
It is very difficult to buy a chip of 512 bytes of RAM today, as you may
know.
It is even more difficult to find a 4 bit processor or many other
small components that just disappear and are replaced by bigger ones
for just ECONOMIES OF SCALE!
The small applications of 2019 will use 4GB of RAM and embedded multi
tasking OSes because there wont be any SMALLER components than those
for sale in that time, not because they need it!
For many applications, 512 bytes of RAM are large enough. A thermometer
can store 512 temperature readings in those bytes, enough for 21 days
of hourly temperature readings. But it will be equipped with 4096 or
even more because those components are CHEAPER than the smaller ones.
I can buy in my supermarket 2GB for 40 euros, but to buy 4K
components I would have to pay MUCH more in a specialized store.
Software development will still be expensive in 2019, and people will
want to use standard environments, so that maintenance is easier.
This means for us that standards should try to not do things for
today's machines but for 2019-2029 machines, what is quite difficult.
jacob navia
Please see the answer to Mr K. Thompson in this same thread.
jacob navia
> jacob navia <ja...@nospam.com> writes:
>> Ian Collins wrote:
>>> But there is a point hidden in the rhetoric, a lot more systems (be they
>>> embedded or otherwise) use file systems than complex maths. So if
>>> something is going to be standardised, make it something useful!
>> Complex math is NOT a good thing to standardize. You can do complex math
>> with several priorities:
>>
>> 1) I want fast complex math, without any accuracy requirements beyond
>> 5-6 digits.
>>
>> 2) I want fast 18 digits accuracy for scientific work
>>
>> 3) I want fail safe behavior with NANs and zeroes. I do not
>> care about speed.
>>
>> 4) I am doing engineering calculations and need to do some
>> calculations with 36 digits precision to ensure that the
>> result is at least 10 digits correct.
>>
>> How are you going to satisfy them all?
> [...]
>
> All of these apply equally to floating-point. Of course it's too late
> now, but would you not have standardized floating-point?
>
This just doesn't apply. There many NAN tests and other algorithmic
issues in complex number multiplication and division than in normal
floating point. Floating point is done exclusively in hardware
nowadays, in most machines.
Those that do NOT have a coprocessor aren't used for floating point
intensive calculations anyway, so that the issue is moot.
Not so with complex operations, not at all. They are done
exclusively in software. This is surely a BIG difference!
Ian Collins
> Ian Collins wrote:
>> But there is a point hidden in the rhetoric, a lot more systems (be they
>> embedded or otherwise) use file systems than complex maths. So if
>> something is going to be standardised, make it something useful!
>
> Complex math is NOT a good thing to standardize. You can do complex math
> with several priorities:
>
I was referring to C99's _Complex and its associated functions. An
example of something considered worthy of standardisation, but of little
use to the majority of C programmers.
--
Ian Collins.
Jack Klein
wrote in comp.std.c:
Unfortunately, C99 is largely irrelevant to embedded systems. Even if
a significant number of embedded developers were interested in it,
which is not the case, conforming C99 implementations for embedded
architectures are as rare, or more so, than they are for common
desktop environments.
Actually, Jacob's statement to which I first responded was this:
> > Unnecessary yes, but it could be that you just consider that
> > refusing to standardize obvious stuff like directory access for
> > instance, or other features that are present in MOST platforms
> > even in modern embedded systems just destroys any evolution of the
> > language.
>
The phrase "hosted environment" is not present.
Perhaps you and Jacob both associate the phrase "modern embedded
system" as "an embedded system executing in a hosted environment". I
think that would surprise the majority of embedded programmers.
Wojtek Lerch
> Actually, Jacob's statement to which I first responded was this:
>
>> > Unnecessary yes, but it could be that you just consider that
>> > refusing to standardize obvious stuff like directory access for
>> > instance, or other features that are present in MOST platforms
>> > even in modern embedded systems just destroys any evolution of the
>> > language.
>>
> The phrase "hosted environment" is not present.
No, and neither is the phrase "freestanding environment". Given that
freestanding environments are not required to implement any of the library
functionality standardized in C99 except for a few headers that contain
nothing but typedefs and macros, I don't think it would be reasonable to
assume that Jacob's suggestion to standardize directory access was meant to
include requiring that functionality in freestanding implementations.
> Perhaps you and Jacob both associate the phrase "modern embedded
> system" as "an embedded system executing in a hosted environment". I
> think that would surprise the majority of embedded programmers.
I can't speak for Jacob, but my understanding of "modern embedded system" is
not really relevant to the point I was trying to make, which is that only
hosted implementations, embedded or otherwise, should be considered relevant
to the discussion about the standardization of directory access.
BTW On a closer look, it seems that Jacob's statement doesn't talk about
directory access in embedded systems at all: unless his punctuation doesn't
reflect his intent accurately, directory access is one example of what he
would like to see standardized, and "other features that are present in most
platforms even in modern embedded systems " is another -- and he doesn't
seem to explain what other features he has in mind, what systems he
considers modern, or how he wants to measure what constitutes "MOST
platforms".
Walter Banks
jacob navia wrote:
> It is very difficult to buy a chip of 512 bytes of RAM today, as you may
> know.
Look at microchip freescale and atmel web sites Each of these
companies are still introducing new parts some with ram
less than 512 bytes.
Small processors with very small RAM are still being engineered
and will likely to continue to be. The ISA of the RS08 was developed
within the last 2 or 3 years and parts have RAM between 48 to
144 bytes. The RS08 has a C compiler.
The 8051 just continues to be re-implimented and used in small
applications
> For many applications, 512 bytes of RAM are large enough. A thermometer
> can store 512 temperature readings in those bytes, enough for 21 days
> of hourly temperature readings.
This is the very reason these parts will continue to be available.
There are many applications where small is enough and that market
is big enough to support a specific parts industry
> Software development will still be expensive in 2019, and people will
> want to use standard environments, so that maintenance is easier.
I agree with you on this point. Software tools is very labor intensive.
> This means for us that standards should try to not do things for
> today's machines but for 2019-2029 machines, what is quite difficult.
We will likely see ISA'a designed for machine generated code
for that time frame. We will also see even more 8 bit processors
Regards
--
Walter Banks, President
Byte Craft Limited
Tel. (519) 888-6911
Fax (519) 746 6751
http://www.bytecraft.com
wal...@bytecraft.com
Francis Glassborow
> You yourself acknowledge that your last implementations used a
> file system, and I bet than in 2019, when the next standard is
> due, nobody will ever use a processor with less than 1GB of EPROM
> and a super multi tasking OS!
opinions that are largely unsupportable. They just hand your opponents a
stick to beat you with.
*-bit processors are widely in use and are likely to remain so for the
foreseeable future. I suspect they may be relatively expensive if you
want to buy them in ones, but the price is dramatically different if you
are in the market for 100000 or more (as you would be if you were a
manufacturer of motor vehicles, for example)
Buying them one at a time results in your paying for all the incidentals
(packaging, stocking etc.) which are seriously more than the cost of a
single unit.
--
Note that robinton.demon.co.uk addresses are no longer valid.
jacob navia
Look, this trend is already obvious today. To see a sample of
applications where windows is used when an 8 bit microprocessor would
be more than enough see:
http://www.networkworld.com/community/node/29644?ts
ALl of them do not need at all windows! But windows is used just
because it is easier than other stuff, more adapted to the application
but more complicated to set up.
santosh
Just because something is used increasingly doesn't necessarily make
that something suitable or sensible for all such uses, does it? After
all, this is the argument you make over and over with regard to C++ and
C, is it not?
Therefore merely citing a page that documents apparent gross misuse of
resources doesn't mean that everyone should start coding for (or
anticipate) such a situation.
Walter Banks
jacob navia wrote:
> Look, this trend is already obvious today. To see a sample of
> applications where windows is used when an 8 bit microprocessor would
> be more than enough see:
>
> http://www.networkworld.com/community/node/29644?ts
>
> ALl of them do not need at all windows! But windows is used just
> because it is easier than other stuff, more adapted to the application
> but more complicated to set up.
There is also a Microchip PIC gift dispensing kiosk.
Train, ship and AC controls are hardly 8 bit suitable
projects. I have seen the control system on some of the
newer Bullet trains and I have been on the bridge
within the last year of a modern ferry. These both take
full advantage of operating system.
For every one of these applications there are dozens more
like the small processor in the keyboard I am typing on
(written in C) and the mouse I am using also written in
C. The tons of USB devices and finally don't forget the
greeting cards and sneakers.
Computing is expanding but in both ways.
w..
Ian Collins
>
> Look, this trend is already obvious today. To see a sample of
> applications where windows is used when an 8 bit microprocessor would
> be more than enough see:
>
and days engineering time are worth spending to save a few in the
finished product.
Don't forget that world is C's stronghold. 8 bit cores will be around
for years, if not decades to come. Just look how many 8051 variants are
still made today, getting on for 30 years after that core was designed.
I wouldn't be surprised if more 8051 based CPUs are shipped this year
than x64 processors.
The C standard must never loose site of this core user group. I think
C99 did, which at least partly accounts for it's pitiful take up.
--
Ian Collins.
Francis Glassborow
> Francis Glassborow wrote:
>> jacob navia wrote:
>>> You yourself acknowledge that your last implementations used a
>>> file system, and I bet than in 2019, when the next standard is
>>> due, nobody will ever use a processor with less than 1GB of EPROM
>>> and a super multi tasking OS!
>> I do wish you would confine yourself to technical issues rather than
>> opinions that are largely unsupportable. They just hand your opponents
>> a stick to beat you with.
>>
>> *-bit processors are widely in use and are likely to remain so for the
>> foreseeable future. I suspect they may be relatively expensive if you
>> want to buy them in ones, but the price is dramatically different if
>> you are in the market for 100000 or more (as you would be if you were
>> a manufacturer of motor vehicles, for example)
>>
>> Buying them one at a time results in your paying for all the
>> incidentals (packaging, stocking etc.) which are seriously more than
>> the cost of a single unit.
>>
>
> Look, this trend is already obvious today. To see a sample of
> applications where windows is used when an 8 bit microprocessor would
> be more than enough see:
>
all kinds of things today that we did otherwise in the past (e.g. radios
and TVs) but we also use vast numbers of minimalist microprocessors
(such as those from the 8051 family) to carry out simple tasks. There
too the number has been increasing over the years and shows no sign of
abating. Apparently (in common with Joe Public) you are not aware as to
how pervasive small (really small) embedded systems have become. You see
the headline CPU in a product and completely miss the far larger number
of support microprocessors that make the product work as we wish it to.
Even in a modern desktop computer there are many more micro-processors
than the CPU running thw whole machine and the GPU looking after your
display.