Free C Compiler on Windows
karthikbalaguru
I find many compilers available in internet.
I would like to know the best Free C Compiler
on a Windows machine.
Has anyone analyzed that ?
Thx in advans,
Karthik Balaguru
LL
MinGW compiler is one.
Flash Gordon
If you are prepared to accept certain things being broken. If I recall
correctly the format specifiers for at least one type don't work because
it uses one representation in the compiler and then uses the C library
from MS which uses a different representation.
There is no one best compiler for Windows in my opinion. It all depends
on what your requirements are.
There are a number listed on these links:
http://clc-wiki.net/wiki/C_Compilers
http://clc-wiki.net/wiki/C_IDEs
--
Flash Gordon
Richard Heathfield
> LL wrote:
>> On Sat, 28 Feb 2009 04:24:57 -0800, karthikbalaguru wrote:
>>
>>> Hi,
>>>
>>> I find many compilers available in internet. I would like to
>>> know the best Free C Compiler on a Windows machine.
>>>
>>> Has anyone analyzed that ?
>>>
>>> Thx in advans,
>>> Karthik Balaguru
>>
>> MinGW compiler is one.
>
> If you are prepared to accept certain things being broken.
I think you have to accept that if you're determined to use Windows.
Certainly I've had issues with Borland C, and others have reported
issues with Microsoft C.
<snip>
> There is no one best compiler for Windows in my opinion. It all
> depends on what your requirements are.
For Win32 API programming, it's hard to beat Visual Studio, once
you've got it set up right. If you're short on time (or just plain
lazy) and are therefore using BCB, however, then Borland C works
just fine for the C bits of the code. (And yes, I do use BCB when
I'm short on time or just plain lazy...)
(I think both of these are available in legally-free versions,
although I paid for my copies thereof.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
jacob navia
The lcc-win compiler comes with compiler + IDE and windowed debugger
It offers many extensions to the bare bones C language and allows you to
access all the windows API.
The URL is below
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield
> karthikbalaguru wrote:
>> Hi,
>>
>> I find many compilers available in internet.
>> I would like to know the best Free C Compiler
>> on a Windows machine.
>>
>> Has anyone analyzed that ?
>>
>> Thx in advans,
>> Karthik Balaguru
>
> The lcc-win compiler comes with compiler + IDE and windowed
> debugger
Note, however, that Jacob Navia is the vendor, so this is not an
independent recommendation. Nor does the lcc-win compiler conform
to any known C Standard, so whether it counts as a C compiler
depends heavily on what you mean by "C compiler".
Flash Gordon
> Flash Gordon said:
>
>> LL wrote:
>>> On Sat, 28 Feb 2009 04:24:57 -0800, karthikbalaguru wrote:
>>>
>>>> Hi,
>>>>
>>>> I find many compilers available in internet. I would like to
>>>> know the best Free C Compiler on a Windows machine.
>>>>
>>>> Has anyone analyzed that ?
>>>>
>>>> Thx in advans,
>>>> Karthik Balaguru
>>> MinGW compiler is one.
>> If you are prepared to accept certain things being broken.
>
> I think you have to accept that if you're determined to use Windows.
> Certainly I've had issues with Borland C, and others have reported
> issues with Microsoft C.
I consider the MinGW issue more serious than the issues I remember
seeing reported for reasonably current versions of MS or Borland compilers.
>> There is no one best compiler for Windows in my opinion. It all
>> depends on what your requirements are.
>
> For Win32 API programming, it's hard to beat Visual Studio, once
> you've got it set up right. If you're short on time (or just plain
> lazy) and are therefore using BCB, however, then Borland C works
> just fine for the C bits of the code. (And yes, I do use BCB when
> I'm short on time or just plain lazy...)
Personally I would normally reach for either Cygwin or Visual Studio on
Windows depending on my requirements at the time. Cygwin if I want gcc
and/or some level of Posix compatibility, Visual Studio if I want a
Windows application. I've found the Borland implementations tend to get
in my way when I want to dig in to and take control of what is going on.
> (I think both of these are available in legally-free versions,
> although I paid for my copies thereof.)
I can confirm that the current version of Visual Studio can b legally
downloaded from Microsoft for free. I don't know what limitations apply
to the free version as compared to the paid-for version, I just use what
comes with my company MSDN subscription.
--
Flash Gordon
jacob navia
> jacob navia said:
>
>> karthikbalaguru wrote:
>>> Hi,
>>>
>>> I find many compilers available in internet.
>>> I would like to know the best Free C Compiler
>>> on a Windows machine.
>>>
>>> Has anyone analyzed that ?
>>>
>>> Thx in advans,
>>> Karthik Balaguru
>> The lcc-win compiler comes with compiler + IDE and windowed
>> debugger
>
> Note, however, that Jacob Navia is the vendor, so this is not an
> independent recommendation. Nor does the lcc-win compiler conform
> to any known C Standard, so whether it counts as a C compiler
> depends heavily on what you mean by "C compiler".
>
This is a lie since I am not selling anything
The compiler is freely available
I am not a "vendor" moron!
And lcc-win conforms to C99, and will accept most syntax of C90
when it doesn't contradict with the newer standards.
To the original poster:
But you should not take into account what this guy says.
He is a known troll
James Kuyper
> Richard Heathfield wrote:
>> jacob navia said:
>>> The lcc-win compiler comes with compiler + IDE and windowed
>>> debugger
>>
>> Note, however, that Jacob Navia is the vendor, so this is not an
>> independent recommendation. Nor does the lcc-win compiler conform to
>> any known C Standard, so whether it counts as a C compiler depends
>> heavily on what you mean by "C compiler".
>>
>
> This is a lie since I am not selling anything
On the first page of your web site it says "if you use it professionally
you have to have to buy a licence.", so at the very least you are
selling software licenses.
> The compiler is freely available
>
> I am not a "vendor" moron!
You vend software licenses. That makes you a vendor. That you also
provide the same software for free for non-commercial uses does not
invalidate the use of the term "vendor".
> And lcc-win conforms to C99, and will accept most syntax of C90
> when it doesn't contradict with the newer standards.
So it now has a fully conforming mode in which it diagnosis all uses of
any extensions for which C99 requires a diagnostic?
I assume, also, that you've fixed the va_list problem that you described
on 2009-02-03 in this newsgroup?
> To the original poster:
>
> But you should not take into account what this guy says.
> He is a known troll
Nonsense.
karthikbalaguru
Can you pls provide me with a link of free download.
I do not find links in borland.com.
I got the below link
http://www.johnsmiley.com/cis18.notfree/smiley029/smiley029.htm
that redirects to
http://www.codegear.com/downloads/free/cppbuilder
Is it a C compiler or C++ Compiler ?
Flash Gordon
> Richard Heathfield wrote:
>> jacob navia said:
>>
>>> karthikbalaguru wrote:
>>>> Hi,
>>>>
>>>> I find many compilers available in internet.
>>>> I would like to know the best Free C Compiler
>>>> on a Windows machine.
>>>>
>>>> Has anyone analyzed that ?
>>>>
>>>> Thx in advans,
>>>> Karthik Balaguru
>>> The lcc-win compiler comes with compiler + IDE and windowed
>>> debugger
>>
>> Note, however, that Jacob Navia is the vendor, so this is not an
>> independent recommendation. Nor does the lcc-win compiler conform to
>> any known C Standard, so whether it counts as a C compiler depends
>> heavily on what you mean by "C compiler".
>>
>
> This is a lie since I am not selling anything
> The compiler is freely available
That does not make you independent. You have spent a lot of time and
effort working on it so you are naturally biased in its favour. There is
nothing wrong with you being in favour of your work, but it does mean
your recommendations are not independent.
Oh, and it is not free for commercial use, so you are selling it. Again,
nothing wrong with selling it, but *you* are lying when you claim that
you are not selling anything.
> I am not a "vendor" moron!
You are the vendor, unless you have now passed that role on to someone else?
> And lcc-win conforms to C99, and will accept most syntax of C90
> when it doesn't contradict with the newer standards.
You've finished implementing C99 then? I'm surprised you did not
announce it.
> To the original poster:
>
> But you should not take into account what this guy says.
> He is a known troll
He is not a troll. I don't think you try to troll either, but you
certainly fly off the handle and in your zeal to defend yourself against
anything you perceive as an attack start saying things which are
demonstrably false.
--
Flash Gordon
Luuk
start reading at this last page....
it says:
Borland C++ Compiler
Windows 5.5 08/24/2000 8.7 Mb Free Borland C++ Compiler download......
--
Luuk
Ben Bacarisse
> jacob navia wrote:
<snip>
>> And lcc-win conforms to C99, and will accept most syntax of C90
>> when it doesn't contradict with the newer standards.
>
> So it now has a fully conforming mode in which it diagnosis all uses
> of any extensions for which C99 requires a diagnostic?
I don't know about that, but the version dated 2009-02-22 still has
some C99 long-standing conformance problems. Some are quite old. I
think I reported all those that I found at the time, but some reports
were not acknowledged so Jacob might not have see them. Of course he
may have decided that the reports were erroneous (which is perfectly
possible).
I have suggested before, since full conformance is so hard, that
Jacob simply list the know issues (like gcc does) and then he can say
that lcc-win is "working towards conformance" or some such wording.
--
Ben.
Richard
> jacob navia said:
>
>> karthikbalaguru wrote:
>>> Hi,
>>>
>>> I find many compilers available in internet.
>>> I would like to know the best Free C Compiler
>>> on a Windows machine.
>>>
>>> Has anyone analyzed that ?
>>>
>>> Thx in advans,
>>> Karthik Balaguru
>>
>> The lcc-win compiler comes with compiler + IDE and windowed
>> debugger
>
> Note, however, that Jacob Navia is the vendor, so this is not an
> independent recommendation. Nor does the lcc-win compiler conform
> to any known C Standard, so whether it counts as a C compiler
> depends heavily on what you mean by "C compiler".
Miaow!
Richard
And as if by magic Heathfield's lacky appears to take a free kick at
Jacob. Absolutely shameful. Hey "Flash no nym", why not list all these
compiler "issues" you have from the earlier thread?
<deafening silence>
jacob navia
> You vend software licenses. That makes you a vendor. That you also
> provide the same software for free for non-commercial uses does not
> invalidate the use of the term "vendor".
>
You also sell stuff to earn your life. As everyone does.
This makes you also a vendor.
What makes me mad is that this work that I have personally developed and
financed and that costs like 500 euros/month to keep going in server
costs and associated expenses makes me a "vendor".
You do not give a dam about that of course, it is my money that is
financing lcc-win as a free service, not yours!!
>> And lcc-win conforms to C99, and will accept most syntax of C90
>> when it doesn't contradict with the newer standards.
>
> So it now has a fully conforming mode in which it diagnosis all uses of
> any extensions for which C99 requires a diagnostic?
>
No, for instance it will accept // comments as you and your stupid
"regulars club" have pointed out.
Anbd yes I WILL NOT FIX THAT since it isn't broken anyway!
> I assume, also, that you've fixed the va_list problem that you described
> on 2009-02-03 in this newsgroup?
>
And obviously since I work for free, I have to work according to your plans?
I do whatever I want with my free time. And I do not know what va_list
problem you are talking about. It was a minor problem with a declaration
that I fixed. A declaration like "long long unsigned int". That was
parsed as unsigned int and that is fixed. Now is parsed as
unsigned long long.
Richard Heathfield
> Richard Heathfield wrote:
>> jacob navia said:
>>
>>> karthikbalaguru wrote:
>>>> Hi,
>>>>
>>>> I find many compilers available in internet.
>>>> I would like to know the best Free C Compiler
>>>> on a Windows machine.
>>>>
>>>> Has anyone analyzed that ?
>>>>
>>>> Thx in advans,
>>>> Karthik Balaguru
>>> The lcc-win compiler comes with compiler + IDE and windowed
>>> debugger
>>
>> Note, however, that Jacob Navia is the vendor, so this is not an
>> independent recommendation. Nor does the lcc-win compiler conform
>> to any known C Standard, so whether it counts as a C compiler
>> depends heavily on what you mean by "C compiler".
>>
>
> This is a lie since I am not selling anything
Firstly, for a statement to be a lie, it must be (a) untrue and (b)
deliberately so. Neither applies. You *do* sell the compiler,
according to your Web site, so that makes you a vendor.
> The compiler is freely available
Yes. It is also available for sale, for commercial use and for use
in universities. Still, if it makes you happy, I'll happily
substitute the word "maintainer".
> I am not a "vendor" moron!
No comment.
> And lcc-win conforms to C99,
I found this claim interesting, since I wasn't aware that you had
previously claimed conformance. I checked your Web site:
http://www.q-software-solutions.de/products/lcc-win32/objectives.shtml
According to that page, "Lcc-win32 implements the full ANSI-C
standard".
If that is true, then I certainly owe you an apology. Is it true?
> and will accept most syntax of C90
> when it doesn't contradict with the newer standards.
>
> To the original poster:
>
> But you should not take into account what this guy says.
> He is a known troll
Troll is as troll does. I don't call people liars when they tell the
truth as they see it. You, however, seem to revel in it.
jacob navia
> jacob navia wrote:
>> I am not a "vendor" moron!
>
> You are the vendor, unless you have now passed that role on to someone
> else?
>
Look. If you want to get a technical detail of gcc you should buy a
contract of software maintenance with gcc with RedHat for 25 000
dollars/Year.
Obviously when GNU sells consulting for exhorbitant prices that's OK.
When I sell a licence it is obviously a bad thing.
You also sell something to earn your life, either your time as
programmer or a product or whatever. You are ALSO a "vendor" then.
Richard Heathfield
<snip>
> Can you pls provide me with a link of free download.
> I do not find links in borland.com.
> I got the below link
> http://www.johnsmiley.com/cis18.notfree/smiley029/smiley029.htm
> that redirects to
> http://www.codegear.com/downloads/free/cppbuilder
CodeGear is Borland's latest name. They make fabulous software but
they're not so hot on marketing, and don't seem to realise the
value of the Borland brand name.
> Is it a C compiler or C++ Compiler ?
Both. To get it to use C rules, give your C file a .c extension
(e.g. hello.c).
Richard Heathfield
> James Kuyper wrote:
>> You vend software licenses. That makes you a vendor. That you
>> also provide the same software for free for non-commercial uses
>> does not invalidate the use of the term "vendor".
>>
>
> You also sell stuff to earn your life. As everyone does.
>
> This makes you also a vendor.
Yes, but you do actually sell the compiler, which makes you a
compiler vendor.
> What makes me mad is that this work that I have personally
> developed and financed and that costs like 500 euros/month to keep
> going in server costs and associated expenses makes me a "vendor".
You say that as if "vendor" is an insult. It isn't.
> You do not give a dam about that of course, it is my money that is
> financing lcc-win as a free service, not yours!!
I don't see the point of that sentence. Presumably you weren't
expecting him to subsidise lcc-win32.
>>> And lcc-win conforms to C99, and will accept most syntax of C90
>>> when it doesn't contradict with the newer standards.
>>
>> So it now has a fully conforming mode in which it diagnosis all
>> uses of any extensions for which C99 requires a diagnostic?
>
> No, for instance it will accept // comments as you and your stupid
> "regulars club" have pointed out.
C99 compilers are *required* to accept // comments, so the fact that
lcc-win32 accepts them is not an indication of non-conformance to
C99.
> Anbd yes I WILL NOT FIX THAT since it isn't broken anyway!
Right. (It does, however, mean that your code doesn't conform to
C90. That isn't a problem if you're not claiming C90 conformance,
which you don't appear to be.)
>
>> I assume, also, that you've fixed the va_list problem that you
>> described on 2009-02-03 in this newsgroup?
>>
>
> And obviously since I work for free, I have to work according to
> your plans?
No, he's not asking you to fix it. He's trying to find out whether
you have fixed it. Do you see the difference? If you haven't fixed
it, presumably that's a conformance issue. If he used lcc-win32
himself, he could find out easily enough for himself whether you've
fixed that problem, so we might reasonably deduce with fair
confidence that he isn't one of your users, and so obviously you
have nothing to gain *from him* for fixing it. What you do have to
gain from fixing it (if you haven't already fixed it) is a closer
approximation to C99 conformance. If that's a design goal for you,
then it's something you may well find worth fixing, for your own
benefit.
> I do whatever I want with my free time.
Who has claimed differently?
> And I do not know what
> va_list problem you are talking about.
If you care about C99 conformance, try asking him nicely to explain
what he means, instead of jumping up and down with anger every time
anyone mentions a conformance issue.
> It was a minor problem with
> a declaration that I fixed. A declaration like "long long unsigned
> int". That was parsed as unsigned int and that is fixed. Now is
> parsed as unsigned long long.
I don't see how that is relevant to va_list.
Richard Heathfield
> Flash Gordon wrote:
>> jacob navia wrote:
>>> I am not a "vendor" moron!
>>
>> You are the vendor, unless you have now passed that role on to
>> someone else?
>>
>
> Look. If you want to get a technical detail of gcc you should buy
> a contract of software maintenance with gcc with RedHat for 25 000
> dollars/Year.
Yes - if we want something fixed but don't want to fix it ourselves,
we either have to pay for it or put up with the problem and hope
someone will fix it for free.
> Obviously when GNU sells consulting for exhorbitant prices that's
> OK.
Yes. Nobody is forced to buy it.
> When I sell a licence it is obviously a bad thing.
Who has said it's a bad thing to sell licences? (Apart from you.)
> You also sell something to earn your life, either your time as
> programmer or a product or whatever. You are ALSO a "vendor" then.
Yes, if you like, although normally the term is used for those who
sell software (or whatever) on a commercial basis rather than an
employment basis. If he sells a product, yes, he vends that
product. You sell lcc-win32 (EVEN THOUGH you also give it away),
and that makes you a vendor. It's not a dirty word.
Joachim Schmitz
> jacob navia said:
>
> I found this claim interesting, since I wasn't aware that you had
> previously claimed conformance. I checked your Web site:
>
> http://www.q-software-solutions.de/products/lcc-win32/objectives.shtml
>
> According to that page, "Lcc-win32 implements the full ANSI-C
> standard".
>
> If that is true, then I certainly owe you an apology. Is it true?
Why don't you just take his word on this?
Bye, Jojo
Han from China
> This is a lie since I am not selling anything
> The compiler is freely available
It's pointless. He's simply not rational. Most trolls aren't.
> I am not a "vendor" moron!
Even if you *were* a vendor, it doesn't matter. We all remember the
Heathfield who was plugging his book years back. Double standards
for the troll Richard Heathfield.
> But you should not take into account what this guy says.
> He is a known troll
Yes, his trolling against you and others over the years is
undeniable. It's just envy. He probably wishes he could write
a widely used compiler. Best plonked.
Yours,
Han from China
--
"Only entropy comes easy." -- Anton Chekhov
nick_keigh...@hotmail.com
> >> I am not a "vendor" moron!
>
> > You are the vendor, unless you have now passed that role on to someone
> > else?
>
> Look. If you want to get a technical detail of gcc you should buy a
> contract of software maintenance with gcc with RedHat for 25 000
> dollars/Year.
I thought we were talking about lcc?
> Obviously when GNU sells consulting for exhorbitant prices that's OK.
I'm not sure that GNU and Redhat are synonomous terms but you
may know better
> When I sell a licence it is obviously a bad thing.
not in my book. Nor, I think, to many other of the posters to this
thread.
People are simply saying that you should say that your compiler is
free
*for non-commercial use*, if those are the terms on which it is
offered.
> You also sell something to earn your life, either your time as
> programmer or a product or whatever. You are ALSO a "vendor" then.
yes but not the vendor of LCC.
I'm impressed with anyone that implements a full compiler and if you
wish
to make money from this then I wish you the best of luck!
Richard Heathfield
In a word - experience.
Joachim Schmitz
> Joachim Schmitz said:
>
>> Richard Heathfield wrote:
>>> jacob navia said:
>> <snip>
>>>> And lcc-win conforms to C99,
>>>
>>> I found this claim interesting, since I wasn't aware that you had
>>> previously claimed conformance. I checked your Web site:
>>>
>>>
> http://www.q-software-solutions.de/products/lcc-win32/objectives.shtml
>>>
>>> According to that page, "Lcc-win32 implements the full ANSI-C
>>> standard".
>>>
>>> If that is true, then I certainly owe you an apology. Is it true?
>>
>> Why don't you just take his word on this?
>
> In a word - experience.
?? he claims ANSI-C conformanance on his website, so why do you ask whether
he really claims that? You saw it yourself, so why the doubts?
Or do you think he claims wrongly? In that case just go ahead and prove it
wrong.
Bye, Jojo
Antoninus Twink
> (It does, however, mean that your code doesn't conform to C90. That
> isn't a problem if you're not claiming C90 conformance, which you
> don't appear to be.)
You really are a snake in the grass, Heathfield.
You seem to have given up your full-frontal attacks (saying directly
that "lcc-win is not a C compiler" etc.) and instead you've turned to
the sly and underhand technique of nasty insinutation - you know
perfectly well that people will read between the lines and find the same
old lie ("not a C compiler"), but you dress it up with a veneer of
moderation and politeness.
I'm not sure I've encountered anyone so dishonest and so crafty in the
whole of my life.
Richard Heathfield
> Richard Heathfield wrote:
>> Joachim Schmitz said:
>>
>>> Richard Heathfield wrote:
>>>> jacob navia said:
>>> <snip>
>>>>> And lcc-win conforms to C99,
>>>>
>>>> I found this claim interesting, since I wasn't aware that you
>>>> had previously claimed conformance. I checked your Web site:
>>>>
>>>>
>>
http://www.q-software-solutions.de/products/lcc-win32/objectives.shtml
>>>>
>>>> According to that page, "Lcc-win32 implements the full ANSI-C
>>>> standard".
>>>>
>>>> If that is true, then I certainly owe you an apology. Is it
>>>> true?
>>>
>>> Why don't you just take his word on this?
>>
>> In a word - experience.
>
> ?? he claims ANSI-C conformanance on his website, so why do you
> ask whether he really claims that? You saw it yourself, so why the
> doubts?
Because he himself seems to be in some doubt.
From elsethread:
James Kuyper asked: "So it now has a fully conforming mode in which
it diagnosis all uses of any extensions for which C99 requires a
diagnostic?"
and Jacob Navia replied: "No, for instance it will accept //
comments as you and your stupid "regulars club" have pointed out."
So here he denies C99 conformance, citing conforming behaviour to
support the denial. But on his Web site he claims conformance.
> Or do you think he claims wrongly? In that case just go ahead and
> prove it wrong.
Before I think about whether I'd be prepared to spend the time
proving him wrong, it would be nice to know what he is actually
claiming.
Joachim Schmitz
You read on his website what he's claiming, so I don't see your point
Bye, Jojo
Antoninus Twink
> You read on his website what he's claiming, so I don't see your point
He doesn't have a point. He isn't really interested in whether or not
lcc-win conforms to C99 - all he wants is an excuse to do down Jacob.
He seems to believe that just because he is a serial liar and a stranger
to the truth, then everyone else must inhabit the same gutter of
dishonesty that he does.
Richard Heathfield
> Richard Heathfield wrote:
<snip>
>> Before I think about whether I'd be prepared to spend the time
>> proving him wrong, it would be nice to know what he is actually
>> claiming.
>
> You read on his website what he's claiming, so I don't see your
> point
It's simple enough - in one place (his Web site) he's claiming
conformance, and in another place (Usenet) he's claiming
non-conformance. They can't both be right. Which should I believe,
and why?
Keith Thompson
> Joachim Schmitz said:
>
>> Richard Heathfield wrote:
>
> <snip>
>
>>> Before I think about whether I'd be prepared to spend the time
>>> proving him wrong, it would be nice to know what he is actually
>>> claiming.
>>
>> You read on his website what he's claiming, so I don't see your
>> point
>
> It's simple enough - in one place (his Web site) he's claiming
> conformance, and in another place (Usenet) he's claiming
> non-conformance. They can't both be right. Which should I believe,
> and why?
In addition to this, at times in the past, he has claimed C99
conformance while his compiler has had known and acknowledged
conformance failures. As I recall, he has at times used the phrase
"C99 conformance", or something similar, to refer to something less
than 100% conformance; the fact that a few features that he considered
unimportant were not yet implemented did not stop him from saying or
implying that lcc-win32 is a conforming C99 compiler.
Here's a brief discussion of lcc-win32's C99 status on
comp.compilers.lcc from 2006-08-02:
http://groups.google.com/group/comp.compilers.lcc/browse_thread/thread/882dc4507702ee1e
To summarize, at the time jacob wrote:
| Designated initializers and structure initializers with the
| dot notation are missing.
[...]
| Besides the preprocessor is still missing the variable
| arguments feature.
I've just downloaded and installed the latest version (3.8, Feb 22
2009). A quick test indicates that it does now support these features
that were missing at the time, so perhaps lcc-win does conform to C99
(apart from bugs, which are inevitable in any large software project).
If so, this is great news, and congratulations are in order. (I did
find a case where the compiler chokes on a moderately complicated
initializer. I'll post a bug report to comp.compilers.lcc.)
--
Keith Thompson (The_Other_Keith) k...@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"
Flash Gordon
> Flash Gordon wrote:
>> jacob navia wrote:
>>> I am not a "vendor" moron!
>>
>> You are the vendor, unless you have now passed that role on to someone
>> else?
>>
>
> Look. If you want to get a technical detail of gcc you should buy a
> contract of software maintenance with gcc with RedHat for 25 000
> dollars/Year.
No, to get any details of gcc just download the source package. If you
want professional support on it you have to pay. If you just want to use
it for free for whatever purpose then you do so.
> Obviously when GNU sells consulting for exhorbitant prices that's OK.
GNU does NOT sell it. Some companies sell support. However, if a gcc
developer was posting recommending gcc (and I was aware they were a gcc
developer) then I would point out that they were not independent.
> When I sell a licence it is obviously a bad thing.
No, it is NOT a bad thing.
> You also sell something to earn your life, either your time as
> programmer or a product or whatever. You are ALSO a "vendor" then.
Generally someone in my position is called an employee and it is the
company that employs me that is a vendor. However, I don't mind if you
call me a vendor since it is not an insult.
--
Flash Gordon
Keith Thompson
> James Kuyper wrote:
[...]
>>> And lcc-win conforms to C99, and will accept most syntax of C90
>>> when it doesn't contradict with the newer standards.
>>
>> So it now has a fully conforming mode in which it diagnosis all uses
>> of any extensions for which C99 requires a diagnostic?
>>
>
> No, for instance it will accept // comments as you and your stupid
> "regulars club" have pointed out.
Huh?
In the recent discussion about accepting // comments, there was one
person ("Tea Pot" or "teapot") complaining about the fact that lcc-win
doesn't issue a diagnostic. The rest of us, including the so-called
"regulars club", were *defending you* against this person's absurd
accusations.
A C99 compiler is required to accept // comments. lcc-win accepts //
comments. There is no conformance issue there.
> Anbd yes I WILL NOT FIX THAT since it isn't broken anyway!
Good. We didn't say it was broken.
But it has nothing to do with C99 conformance.
[...]
Richard Heathfield
<snip>
> In the recent discussion about accepting // comments, there was
> one person ("Tea Pot" or "teapot") complaining about the fact that
> lcc-win
> doesn't issue a diagnostic. The rest of us, including the
> so-called "regulars club", were *defending you* against this
> person's absurd accusations.
>
> A C99 compiler is required to accept // comments. lcc-win accepts
> //
> comments. There is no conformance issue there.
Right.
[JN]
>> Anbd yes I WILL NOT FIX THAT since it isn't broken anyway!
>
> Good. We didn't say it was broken.
>
> But it has nothing to do with C99 conformance.
Not quite true. If lcc-win32 did *not* support // comments, that
would be a conformance issue. So // comments are relevant to
conformance. But if you simply mean it's a dead end as far as this
discussion is concerned, then of course I agree.
Han from China
> No, for instance it will accept // comments as you and your stupid
> "regulars club" have pointed out.
We've certainly established that Heathfield has no room to talk when it
comes to bugs. One only has to look at "C Unleashed" and the buggy crap on
his Web site. There you are releasing a compiler, and what does Heathfield
have to show for himself? Check his Web site for a laugh.
None of the people picking on you in this thread could write a compiler,
especially not Heathfield and especially not Flash Gordon.
All they are is language lawyers trying to feel important in the shadows
of real C programmers, but it's gradually become apparent that they're not
even good at being language lawyers.
Not worth your time, in my opinion. You're WAY above them.
James Kuyper
> James Kuyper wrote:
>> You vend software licenses. That makes you a vendor. That you also
>> provide the same software for free for non-commercial uses does not
>> invalidate the use of the term "vendor".
>>
>
> You also sell stuff to earn your life. As everyone does.
>
> This makes you also a vendor.
Essentially 100% of what I sell is my labor, and someone who does that
is called a worker, not a vendor. You are selling the product of your
labor, rather than the labor itself, and as such that makes you a
vendor, at least insofar as your roll as an implementor of C.
> What makes me mad is that this work that I have personally developed and
> financed and that costs like 500 euros/month to keep going in server
> costs and associated expenses makes me a "vendor".
>
>
> You do not give a dam about that of course, it is my money that is
> financing lcc-win as a free service, not yours!!
You're right; I don't care about that; it's your decision about how you
use your money, and it doesn't affect anything that is of interest to
me. But I don't see why you treat the term "vendor" as if it were an insult.
>>> And lcc-win conforms to C99, and will accept most syntax of C90
>>> when it doesn't contradict with the newer standards.
>>
>> So it now has a fully conforming mode in which it diagnosis all uses
>> of any extensions for which C99 requires a diagnostic?
>>
>
> No, for instance it will accept // comments as you and your stupid
> "regulars club" have pointed out.
We're talking about C99 conformance here - what part of the C99 standard
mandates diagnostics for // comments? That was an issue only for C90
conformance, and you do not claim C90 conformance (or so I thought?).
The relevant issues for C99 conformance would be the extensions you
provide that allow code which counts as a syntax error or constraint
violation under C99, such as operator overloading. Does lcc-win have a
mode in which it diagnoses such syntax errors or constraint violation,
as it is required to do by the C99 standard? It doesn't have to be the
default mode; it could be invoked with the option
-stupid_C99_mandatory_diagnostics; but it's not a fully conforming
implementation of C99 except when it is invoked in such a mode.
>> I assume, also, that you've fixed the va_list problem that you
>> described on 2009-02-03 in this newsgroup?
>>
>
> And obviously since I work for free, I have to work according to your
> plans?
No, my plans don't have anything to do with it. Your compiler doesn't
have to conform to C99, and I have no plans whatsoever for your
compiler. You can do with it whatever you like. Conform to C99 or not,
as you wish. Define your own extensions, conforming or not. However, if
you claim that it conforms to C99, and that claim is false, criticism is
entirely in order, and I'm willing to provide it. If you would simply
qualify that claim, as gcc does, by listing known non-conforming
features, there would be no problem.
> I do whatever I want with my free time. And I do not know what va_list
> problem you are talking about. ...
Wasn't the precise date, the newsgroup, and the fact that the message
was about va_list enough information? You don't post a lot of messages
here anymore, a search on those parameters with google only produces one
hit. The relevant words from that message are:
> This will work under lcc-win 32 bits, but will not work for
> lcc-win 64 bits, either under windows or unix. (x86)
>
> The problem is that each access to the va_list needs an inlined
> function call to the extractor since it is no longer a linear list.
> ...
> So you can't pass the address of the va_args data. You have to pass
> the va_args data structure itself.
As Kaz pointed out:
> If it doesn't work, it's broken. There is a footnote in C99:
>
> ``It is permitted to create a pointer to a va_list and pass that pointer to another function, in which case the original function may make further use of the original list after the other function returns.''
>
> The footnote isn't normative, but it doesn't matter, because it's not the footnote which is making it well-defined. The footnote is just a reminder to the implementor not to forget about that case.
James Kuyper
Experience has shown that jacob has some difficulties with the subtle
details of conformance requirements. For instance, he's correctly aware
of the fact that the C standard allows for extensions, but had to be
convinced of the fact that, in fully conforming mode, a C implementation
must produce at least one diagnostic if the program contains any syntax
errors or constraint violations - even if those occur as the result of
using one of the extensions. That doesn't mean the compiler must reject
such code - the diagnostic message could say "Congratulations for making
use of lcc-win's extension allowing operator overloading!". However, a
diagnostic of some kind is required. It's still not entirely clear
whether he fully understands this point.
lawrenc...@siemens.com
>
> This is a lie since I am not selling anything
> The compiler is freely available
>
Sure you are! "Vend" has lots of meanings beyond just selling for
money. You publish and promote your compiler and that's vending in the
broad sense of the word.
> And lcc-win conforms to C99, and will accept most syntax of C90
> when it doesn't contradict with the newer standards.
Does that mean you've finally finished up all the little "unimportant"
bits of full C99 compliance that were still pending?
--
Larry Jones
I've got PLENTY of common sense! I just choose to ignore it. -- Calvin
jacob navia
[snip]
You are confused, and my compiler is compliant.
va_arg macros take an OBJECT of type va_list, not a pointer to that object.
If you pass a pointer to a va_list object, to be able to use it you have
to dereference that pointer making a copy of the pointed to va_list object.
Obviously you can do that as many times as you want, the original object
remains untouched and when the called function returns, the function
will not see any of the modifications done within the called function.
Example:
void foo(va_list *pva_list);
within the function1:
void function1(void)
{
va_list f = va_start(arg2);
va_list *pva_list = &f;
foo(pva_list);
}
void foo(va_list *pva_list)
{
va_list f = *pva_list; // Dereference pointer making a COPY
int m = va_arg(f, int);
}
To be able to use the va_arg macro you need a va_list OBJECT, not a
pointer. Obviously YOU CAN pass a pointer but you can't pass that
pointer to a va_arg macro since the prototype of that macro is:
type va_arg(va_list ap,type);
(C99 standard 7.15.1.1). It takes an object, not a pointer.
There are no problems with my implementation.
jacob navia
> void function1(void)
> {
> va_list f = va_start(arg2);
Nonsense, that should have been:
void function1(int arg1, int arg2,...)
{
va_list f = va_start(arg2);
...
CBFalconer
> James Kuyper wrote:
>>
... snip ...
>>
>>> And lcc-win conforms to C99, and will accept most syntax of C90
>>> when it doesn't contradict with the newer standards.
>>
>> So it now has a fully conforming mode in which it diagnosis all
>> uses of any extensions for which C99 requires a diagnostic?
>
> No, for instance it will accept // comments as you and your stupid
> "regulars club" have pointed out.
>
If you haven't noticed, the C99 standard accepts // as a single
line comment marker. However C90 doesn't. You might wish to read
the standard. See below.
>
>> I assume, also, that you've fixed the va_list problem that you
>> described on 2009-02-03 in this newsgroup?
>
> And obviously since I work for free, I have to work according to
> your plans? I do whatever I want with my free time. And I do not
> know what va_list problem you are talking about. It was a minor
> problem with a declaration that I fixed. A declaration like "long
> long unsigned int". That was parsed as unsigned int and that is
> fixed. Now is parsed as unsigned long long.
No, but most maintainers of software keep track of bugs, when they
were reported, and when (if ever) they were fixed.
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer
>
... snip ...
>
> a contract of software maintenance with gcc with RedHat for 25 000
> dollars/Year.
>
> Obviously when GNU sells consulting for exhorbitant prices that's
> OK. When I sell a licence it is obviously a bad thing.
For your information, RedHat is not GNU. RedHat are allowed to
sell anything they own, which includes their skill at analysing
gcc. The source for gcc is freely available. You can download it,
and compile it, and own a fresh copy of gcc. You can even sell it,
if you can find a sucker that wants to pay for what is freely
available.
However you do not make the source of lcc-win32 freely available.
This prevents anybody from improving it. This is your right, but
don't put it in the same class as GNU gcc.
CBFalconer
> Joachim Schmitz said:
>> Richard Heathfield wrote:
>>> Joachim Schmitz said:
>>>> Richard Heathfield wrote:
>>>>
>>>>
>>>>> According to that page, "Lcc-win32 implements the full ANSI-C
>>>>> standard".
>>>>>
>>>>> If that is true, then I certainly owe you an apology. Is it
>>>>> true?
>>>>
>>>> Why don't you just take his word on this?
>>>
>>> In a word - experience.
>>
>> ?? he claims ANSI-C conformanance on his website, so why do you
>> ask whether he really claims that? You saw it yourself, so why the
>> doubts?
>
> Because he himself seems to be in some doubt.
In addition it is virtually impossible to tell his versions apart.
There seems to be no way to determine it, other than the date on
the object file, which is easily altered. This was the situation
some years ago, possibly he has improved it.
jacob navia
> Richard Heathfield wrote:
>> Joachim Schmitz said:
>>> Richard Heathfield wrote:
>>>> Joachim Schmitz said:
>>>>> Richard Heathfield wrote:
>>>>>
> ... snip ...
>>>>>> According to that page, "Lcc-win32 implements the full ANSI-C
>>>>>> standard".
>>>>>>
>>>>>> If that is true, then I certainly owe you an apology. Is it
>>>>>> true?
>>>>> Why don't you just take his word on this?
>>>> In a word - experience.
>>> ?? he claims ANSI-C conformanance on his website, so why do you
>>> ask whether he really claims that? You saw it yourself, so why the
>>> doubts?
>> Because he himself seems to be in some doubt.
> ... snip ...
>
> In addition it is virtually impossible to tell his versions apart.
> There seems to be no way to determine it, other than the date on
> the object file, which is easily altered. This was the situation
> some years ago, possibly he has improved it.
>
lcc -v
OK?
Chris M. Thomasson
news:15a681ad-14ba-4ec2...@v5g2000prm.googlegroups.com...
> Hi,
>
> I find many compilers available in internet.
> I would like to know the best Free C Compiler
> on a Windows machine.
>
> Has anyone analyzed that ?
Why not use a compiler created by the same follks who created Windows:
http://www.microsoft.com/Express
;^)
Anyway, I would personally download multiple compilers and get your code to
compile correctly on all of them. It tends to help out with "portability".
CBFalconer
> CBFalconer wrote:
>
... snip ...
>
>> In addition it is virtually impossible to tell his versions apart.
>> There seems to be no way to determine it, other than the date on
>> the object file, which is easily altered. This was the situation
>> some years ago, possibly he has improved it.
>
> lcc -v
>
> OK?
Good. I can forget that complaint.
Antoninus Twink
> jacob navia wrote:
>> financing lcc-win as a free service, not yours!!
>
> You're right; I don't care about that; it's your decision about how you
> use your money, and it doesn't affect anything that is of interest to
> me.
Of course not!
After all, you and your kind only care about the Standard in and of
itself. Any actual implementations of that Standard simply "aren't of
interest to you".
It's this sort of blind stupidity that has led to the current C Standard
being a white elephant that no one is interested in implementing (after
all, you don't care about their work, so why should they care about
yours?), all the while keeping antiquated cruft and garbage like gets()
hanging around for ever more.
jacob navia
> It's this sort of blind stupidity that has led to the current C Standard
> being a white elephant that no one is interested in implementing (after
> all, you don't care about their work, so why should they care about
> yours?), all the while keeping antiquated cruft and garbage like gets()
> hanging around for ever more.
>
They included gets() in the next version of the standard, a proposal
presented some months ago. ALl they would do is to add a tiny footnote
saying that that function is "obsolescent". Getting rid of it would be
too much change for the standard.
Ina similar way they refuse to get rid of the buffer overflow in the
code of the asctime() function.
The argument for asctime() is that since the standard can't have a
buffer overflow, if you find one... well, it is implicit that the values
you are using are illegal!
The only reason they are publishing a nesw standard is that according to
ISO rules if a standard group doesn't publish anything in 10 years it
becomes obsolete.
Richard
> jacob navia wrote:
>> James Kuyper wrote:
>>> jacob navia wrote:
>>>
> ... snip ...
>>>
>>>> And lcc-win conforms to C99, and will accept most syntax of C90
>>>> when it doesn't contradict with the newer standards.
>>>
>>> So it now has a fully conforming mode in which it diagnosis all
>>> uses of any extensions for which C99 requires a diagnostic?
>>
>> No, for instance it will accept // comments as you and your stupid
>> "regulars club" have pointed out.
>>
>> Anbd yes I WILL NOT FIX THAT since it isn't broken anyway!
>
> If you haven't noticed, the C99 standard accepts // as a single
> line comment marker. However C90 doesn't. You might wish to read
> the standard. See below.
You bitter, jealous, vindictive cretin. Jacob provides a FREE compiler
and you point HIM to standards? All you have written is a crappy gets
substitute which is incredibly poorly laid out and, frankly, nothing
more than a first year student would be asked to write in any reputable
project.
>
>>
>>> I assume, also, that you've fixed the va_list problem that you
>>> described on 2009-02-03 in this newsgroup?
>>
>> And obviously since I work for free, I have to work according to
>> your plans? I do whatever I want with my free time. And I do not
>> know what va_list problem you are talking about. It was a minor
>> problem with a declaration that I fixed. A declaration like "long
>> long unsigned int". That was parsed as unsigned int and that is
>> fixed. Now is parsed as unsigned long long.
>
> No, but most maintainers of software keep track of bugs, when they
> were reported, and when (if ever) they were fixed.
I'm sure we can all learn from your professional Pascal projects. Why do
you bother?
Old Wolf
> Yes, if you like, although normally the term is used for those who
> sell software (or whatever) on a commercial basis rather than an
> employment basis. If he sells a product, yes, he vends that
> product. You sell lcc-win32 (EVEN THOUGH you also give it away),
> and that makes you a vendor. It's not a dirty word.
I'd feel uncomfortable too if I were
accepting money for lcc-win32, TBH.
lawrenc...@siemens.com
>
> Ina similar way they refuse to get rid of the buffer overflow in the
> code of the asctime() function.
You persist in misunderstanding -- that is *not* "the code of the
asctime() function", it is an illustration of the algorithm to be used
by the asctime() function. Yes, it happens to look a lot like C code
since that was the simplest way to describe the algorithm, but no where
is there even a hint that implementations should use that code verbatim.
> The only reason they are publishing a nesw standard is that according to
> ISO rules if a standard group doesn't publish anything in 10 years it
> becomes obsolete.
No, the existing standard can be reaffirmed if no changes are deemed
necessary.
--
Larry Jones
Honey, are we out of aspirin again? -- Calvin's Dad
Keith Thompson
> jacob navia <ja...@nospam.org> wrote:
>>
>> Ina similar way they refuse to get rid of the buffer overflow in the
>> code of the asctime() function.
>
> You persist in misunderstanding -- that is *not* "the code of the
> asctime() function", it is an illustration of the algorithm to be used
> by the asctime() function. Yes, it happens to look a lot like C code
> since that was the simplest way to describe the algorithm, but no where
> is there even a hint that implementations should use that code verbatim.
Yes, but implementations are certainly allowed to use that code
verbatim, and one could argue that there's not much reason not to do
so.
Because asctime() is defined by an algorithm expressed in C, its
behavior is defined by that C code. In particular, its behavior is
well defined in some very odd (and not very useful) cases, and
undefined in some cases that could have been caught as errors. Those
cases can be determined unambiguously by examining the code, but
they're not stated at all clearly.
In my opinion, asctime() is irredeemably ugly; perhaps deprecating it
in favor of strftime() would be better than trying to "fix" it.
jacob navia
> jacob navia <ja...@nospam.org> wrote:
>> Ina similar way they refuse to get rid of the buffer overflow in the
>> code of the asctime() function.
>
> You persist in misunderstanding -- that is *not* "the code of the
> asctime() function", it is an illustration of the algorithm to be used
> by the asctime() function.
GREAT!
In that "illustration" then, we have a buffer overflow. That is part of
the specs or what?
> Yes, it happens to look a lot like C code
> since that was the simplest way to describe the algorithm, but no where
> is there even a hint that implementations should use that code verbatim.
>
Why show code with buffer overflows?
>> The only reason they are publishing a nesw standard is that according to
>> ISO rules if a standard group doesn't publish anything in 10 years it
>> becomes obsolete.
>
> No, the existing standard can be reaffirmed if no changes are deemed
> necessary.
That is what the first proposal looks like. gets() is STILL there!
asctime() buffer overflow in the "illustration" is still there.
There are almost NO changes. The language is completely frozen in the
bugs that this people persist on perpetuating.
lawrenc...@siemens.com
>
> In that "illustration" then, we have a buffer overflow. That is part of
> the specs or what?
Yes, it is part of the spec: certain input values result in undefined
behavior, so correct programs must avoid such inputs.
> That is what the first proposal looks like. gets() is STILL there!
> asctime() buffer overflow in the "illustration" is still there.
>
> There are almost NO changes. The language is completely frozen in the
> bugs that this people persist on perpetuating.
The document you're referring to is *not* a "first proposal" -- it's a
working document that the committee has just started making changes to.
There will be many more working documents (there's already a second one)
with many more changes before the committee produces a first proposal
for a new standard (which is called a Committee Draft [CD] in ISO-speak).
--
Larry Jones
Just when I thought this junk was beginning to make sense. -- Calvin
Keith Thompson
>> That is what the first proposal looks like. gets() is STILL there!
>> asctime() buffer overflow in the "illustration" is still there.
>>
>> There are almost NO changes. The language is completely frozen in the
>> bugs that this people persist on perpetuating.
>
> The document you're referring to is *not* a "first proposal" -- it's a
> working document that the committee has just started making changes to.
Yes, we've tried to explain this to jacob multiple times.
> There will be many more working documents (there's already a second one)
Would that be http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf?
I see that the file is about a third the size of the previous draft,
n1336.pdf; do you know why?
> with many more changes before the committee produces a first proposal
> for a new standard (which is called a Committee Draft [CD] in ISO-speak).
--
jacob navia
> Would that be http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf?
From that document:
----------------------------------------------------------------------
7.19.7.7 The gets function
Synopsis
1 #include <stdio.h>
char *gets(char *s);
Description
2 The gets function reads characters from the input stream pointed to by
stdin, into the array pointed to by s, until end-of-file is encountered
or a new-line character is read.
Any new-line character is discarded, and a null character is written
immediately after the last character read into the array.
Returns
3 The gets function returns s if successful. If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is returned.
If a read error occurs during the operation, the array contents are
indeterminate and a null pointer is returned.
Forward references: future library directions (7.27.9).
------------------------------------------------------------------------
Keith Thompson
Right. This has not changed from the C99 standard, to N1256 (C99 plus
TC1, TC2, and TC3), to N1336 (the first preliminary C201X draft), to
N1362 (the second preliminary C201X draft).
Note that all these documents other than the original C99 standard
have the following in the "Future library directions" section:
The gets function is obsolescent, and is deprecated.
So what exactly is your point, jacob? As Larry Jones recently said in
reference to N1336 (and I'm sure this applies equally to N1362):
| The document you're referring to is *not* a "first proposal" -- it's a
| working document that the committee has just started making changes to.
Whatever changes might be made with regard to gets(), the committee
just hasn't gotten to them yet.
Richard Heathfield
> jacob navia <ja...@nospam.org> wrote:
<snip>
>> That is what the first proposal looks like. gets() is STILL
>> there! asctime() buffer overflow in the "illustration" is still
>> there.
>>
>> There are almost NO changes. The language is completely frozen in
>> the bugs that this people persist on perpetuating.
>
> The document you're referring to is *not* a "first proposal" --
> it's a working document that the committee has just started making
> changes to.
And at what point will they notice, and remove, the gets() function?
Sheesh, guys!
jacob navia
So, after all those discussions in comp.std.c, after all those documents
everywhere, after the thousands of pages explaining why gets() is an
error they STILL DO NOT ACKNOWLEDGE that gets() should go.
Great. And now you ask
"What is your point jacob"?
I said:
<quote>
The language is completely frozen in the bugs that this people persist
on perpetuating.
<end quote>
And no, I still do not see why this function will REMAIN in the language
until 2020 or later!
Lew Pitcher
wrote:
[snip]
>> Whatever changes might be made with regard to gets(), the committee
>> just hasn't gotten to them yet.
>>
>
> So, after all those discussions in comp.std.c, after all those documents
> everywhere, after the thousands of pages explaining why gets() is an
> error they STILL DO NOT ACKNOWLEDGE that gets() should go.
I don't agree.
You would be correct in that assertion *if this were the published
standard*, but it isn't. It is a /working document/; a draft that is
acknowledged by the authors to be incomplete and still under development.
Boy, you /really/ don't get the "standardization process", do you?
[snip]
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
jacob navia
> I don't agree.
>
> You would be correct in that assertion *if this were the published
> standard*, but it isn't. It is a /working document/; a draft that is
> acknowledged by the authors to be incomplete and still under development.
>
> Boy, you /really/ don't get the "standardization process", do you?
>
> [snip]
>
And how many YEARS will it take for those people to realize that gets()
is not really a good idea? It is already one year more or less since
they started this isn't it?
Boy, I surely do not get the "standardization process". I just do not
get it why it is SO difficult to just
(1) Select the text that defines the gets() function
(2) Press the "delete" key
(3) Save
Boy, I do not get it. I am too stupid for that. I need a freshman class
in the "standardization process".
Lesson (1)
Bugs aren't bugs
Lesson (2)
If you find a bug or a misfeature, rule (1) applies.
Lew Pitcher
wrote:
> Lew Pitcher wrote:
>> I don't agree.
>>
>> You would be correct in that assertion *if this were the published
>> standard*, but it isn't. It is a /working document/; a draft that is
>> acknowledged by the authors to be incomplete and still under development.
>>
>> Boy, you /really/ don't get the "standardization process", do you?
>>
>> [snip]
>>
>
> And how many YEARS will it take for those people to realize that gets()
> is not really a good idea?
Probably about as long as it has taken for developers to realize that
void main() { ... }
is not a good idea.
The problem is, we still see programmers code void main(), even though the
standard says otherwise. You *will not* rid the world of gets() simply by
removing it from the standard.
To answer your question seriously: the standards body probably *already
understands that gets() has serious flaws*. They simply haven't made a
change to their working document yet.
> It is already one year more or less since they started this isn't it?
So? You imagine that international standards are written overnight? Not by a
long shot.
Bartc
> Antoninus Twink wrote:
>> It's this sort of blind stupidity that has led to the current C
>> Standard being a white elephant that no one is interested in
>> implementing (after all, you don't care about their work, so why
>> should they care about yours?), all the while keeping antiquated
>> cruft and garbage like gets() hanging around for ever more.
>>
>
> They included gets() in the next version of the standard, a proposal
> presented some months ago. ALl they would do is to add a tiny footnote
> saying that that function is "obsolescent". Getting rid of it would be
> too much change for the standard.
Yes why is it necessary to have gets() as part of the standard library when
it's so easy to create your own:
#include <stdio.h>
#include <limits.h>
char* gets(char *s){
char *t;
t=fgets(s,LONG_MAX,stdin);
if (t==NULL) return NULL;
while (*t!='\n') ++t;
*t=0;
return s;
}
--
Bartc
Kaz Kylheku
> Boy, I surely do not get the "standardization process". I just do not
> get it why it is SO difficult to just
>
> (1) Select the text that defines the gets() function
> (2) Press the "delete" key
> (3) Save
Agreed. The gets function does not require a fscking obsolescence phase. Just
delete it! No mention of it anywhere. Implementations then have to remove gets
from their <stdio.h> header, and allow programs to use it as a name with
external linkage. This bold move can be accomplished in one revision.
James Kuyper
>> That is what the first proposal looks like. gets() is STILL there!
>> asctime() buffer overflow in the "illustration" is still there.
> The document you're referring to is *not* a "first proposal" -- it's a
> working document that the committee has just started making changes to.
> There will be many more working documents (there's already a second one)
> with many more changes before the committee produces a first proposal
> for a new standard (which is called a Committee Draft [CD] in ISO-speak).
Let me ask the questions that jacob seems incapable of asking:
If the committee were planning to make some changes to the next version
of the standard to deal with gets() and asctime(), at what point in the
process could jacob reasonably expect to find a document reflecting
those planned changes? Can you estimate how soon that point will be
reached?
At what point in the process could jacob reasonably assume that the
absence of any changes means that the committee isn't planning to make
any? Can you estimate when that point will be reached?
Finally, in the unlikely event that jacob ever decides to do something
more productive about these issues than complain in this newsgroup about
how stupid he thinks the committee is, what should that something be,
and what is the deadline for doing it in time for this version of the
standard?
Ben Bacarisse
That is marginally worse than gets since it has undefined behaviour
when EOF is not immediately preceded by '\n'. In that situation fgets
reads some characters (that may well fit in the user's buffer) but
there is no newline to find.
In the spirit of spelling corrections, here is mine so you can find
the bug I will not doubt leave in it:
/* Don't try this at home. */
char *gets(char *s)
{
char *cp = s;
int c;
while ((c = getchar()) != EOF && c != '\n')
*cp++ = c;
if (c == EOF && cp == s)
return NULL;
*cp = 0;
return s;
}
But, honestly, why would you?
--
Ben.
CBFalconer
>
... snip ...
>
> gets() is not really a good idea? It is already one year more or
> less since they started this isn't it?
>
> Boy, I surely do not get the "standardization process". I just
> do not get it why it is SO difficult to just
>
> (1) Select the text that defines the gets() function
> (2) Press the "delete" key
> (3) Save
>
> Boy, I do not get it. I am too stupid for that. I need a
> freshman class in the "standardization process".
Sane standardizers do NOT simply make existing conforming code
erroneous. Believe it or not, some users of GCC would like to
apply it to source code they have been using unchanged since Jeanne
d'Arc died, without having it abort on errors. So gets will NOT
just get deleted. It WILL get deprecated.
Han from China
> Let me ask the questions that jacob seems incapable of asking:
On the contrary -- it seems Jacob has succeeded in turning the
tables around in this thread.
As a suggestion to Jacob, whenever someone bitches about his
compiler and conformance to any ISO standard, he should demand
that they show him precisely what conformance means, using
only the wording of the standard in question. C99 says that
a conforming implementation shall accept any strictly conforming
program, but the definition of a strictly conforming program
has yet to be pinned down precisely, particularly in terms
of output and minimum implementation limits. If the C99 standard
can't even tell Jacob whether
int main(void)
{
return 0;
}
is a strictly conforming program, then I don't really blame
him for taking a practical approach with his compiler.
There's also the undeniable fact that many heads bang together
on comp.std.c to decipher certain aspects of the C99 standard,
with plenty of unresolved questions, so how can *any* implementor
be expected to adhere to C99 to the letter if there's not even
a common, unified interpretation of the C99 text?
Yet another indication of the need for a formal semantics.
Yours,
Han from China
--
"Only entropy comes easy." -- Anton Chekhov
Richard Heathfield
> jacob navia wrote:
>>
> ... snip ...
>>
>> And how many YEARS will it take for those people to realize that
>> gets() is not really a good idea? It is already one year more or
>> less since they started this isn't it?
>>
>> Boy, I surely do not get the "standardization process". I just
>> do not get it why it is SO difficult to just
>>
>> (1) Select the text that defines the gets() function
>> (2) Press the "delete" key
>> (3) Save
>>
>> Boy, I do not get it. I am too stupid for that. I need a
>> freshman class in the "standardization process".
>
> Sane standardizers do NOT simply make existing conforming code
> erroneous.
To name but two counter-examples, restrict (which invades user
namespace) and the removal of implicit int.
> Believe it or not, some users of GCC would like to
> apply it to source code they have been using unchanged since
> Jeanne
> d'Arc died, without having it abort on errors. So gets will NOT
> just get deleted. It WILL get deprecated.
Source code that uses gets() /needs/ changing.
jacob navia
> Finally, in the unlikely event that jacob ever decides to do something
> more productive about these issues than complain in this newsgroup about
> how stupid he thinks the committee is, what should that something be,
> and what is the deadline for doing it in time for this version of the
> standard?
Look Mr
(1) Nowhere I have insulted anyone, nor I am saying anywhere that some
people are stupid. You are putting words on my mouth.
(2) Yes, I disagree with some decisions of the committee. This never
means that I think that people are stupid because they do not agree
with me. Yes, I use irony, and yes, I have criticized the current
state of affairs. That is all.
(3) Concerning gets():
The only actions needed (since this function is ALREADY declared
obsolescent) is to delete the text that describes it from the
standard. This is very easy to do and needs no further
justification.
(4) Concerning asctime() I have proposed a drop in replacement for
the code presented in the standard in the discussion group
comp.std.c. The proposed code produces exactly the
same output for all inputs that are within range. I would like
to present this code in a formal way to the committee but I can't
afford to pay the plane tickets and hotel expenses for assiting to
the committee meetings somewhere in China or in San Francisco.
(5) To allow interested people to reach the committee I have proposed
that they have a web presence somewhere so that it is possible to
send them a document without having to pay 3000 US$ in plane and
hotel tickets. Not everybody has that travel expenses budget. I
pay all costs to keep lcc-win. I can't add to that the expense
of several trips per year to some place in the world.
Phil Carmody
> Thompson wrote:
[citing the working document]
>> The gets function is obsolescent, and is deprecated.
>
> documents everywhere, after the thousands of pages explaining why
> gets() is an error they STILL DO NOT ACKNOWLEDGE that gets() should
> go.
Which bit of 'obsolescent' and 'deprecated' do you not understand?
Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.
jacob navia
> jacob navia <ja...@nospam.org> writes:
>> Thompson wrote:
> [citing the working document]
>>> The gets function is obsolescent, and is deprecated.
>> So, after all those discussions in comp.std.c, after all those
>> documents everywhere, after the thousands of pages explaining why
>> gets() is an error they STILL DO NOT ACKNOWLEDGE that gets() should
>> go.
>
> Which bit of 'obsolescent' and 'deprecated' do you not understand?
>
> Phil
This is since quite a while now. It is already in the current
standard.
What I can't understand is
(1) Why gets() is STILL in the standard text, since it is already
declared deprecated it could be DROPPED now!
(2) The only hint to its deprecation is in that footnote...
(3) If it gets (no pun intended :-) into the standard it will remain
there until 2020. And no, I can't understand that.
Walter Banks
jacob navia wrote:
(1)(2) Your irony is not helping your cause.
(3)(4) Make your argument in a formal paper then present and argue your
position on the addition changes you want. Show your position
represents a reasoned position for the language.Be part of the
document trail that standards need to support the choices being
made.
(4) Actually the next meeting is in Canada. You have a vested interest
in the C language and without your presence your customers have
a limited voice in changes in WG14.
(5) There is plenty of web presence, committee documents are on line
many committee members are active on news groups. The formal
process requires sincere debate by interested parties to work.What
is on the newsgroups is editorial comment.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
nick_keigh...@hotmail.com
<snip>
> (4) Actually the next meeting is in Canada. You have a vested interest
> in the C language and without your presence your customers have
> a limited voice in changes in WG14.
air fares to Canada do not grow on trees
> (5) There is plenty of web presence, committee documents are on line
> many committee members are active on news groups. The formal
> process requires sincere debate by interested parties to work.What
> is on the newsgroups is editorial comment.
maybe there a good reasons why things work the way they do. But the
process
*does* exclude people (maybe deliberatly) who can't afford the time/
money to
zip around the world
Spiros Bousbouras
> James Kuyper wrote:
> > Finally, in the unlikely event that jacob ever decides to do something
> > more productive about these issues than complain in this newsgroup about
> > how stupid he thinks the committee is, what should that something be,
> > and what is the deadline for doing it in time for this version of the
> > standard?
>
> Look Mr
>
> (1) Nowhere I have insulted anyone, nor I am saying anywhere that some
> people are stupid. You are putting words on my mouth.
No he isn't. Earlier in the thread you called Richard Heathfield
a moron.
Spiros Bousbouras
> lawrence.jo...@siemens.com wrote:
> > jacob navia <ja...@nospam.org> wrote:
> ...
> >> That is what the first proposal looks like. gets() is STILL there!
> >> asctime() buffer overflow in the "illustration" is still there.
> ...
> > The document you're referring to is *not* a "first proposal" -- it's a
> > working document that the committee has just started making changes to.
> > There will be many more working documents (there's already a second one)
> > with many more changes before the committee produces a first proposal
> > for a new standard (which is called a Committee Draft [CD] in ISO-speak).
>
> Let me ask the questions that jacob seems incapable of asking:
>
> If the committee were planning to make some changes to the next version
> of the standard to deal with gets() and asctime(), at what point in the
> process could jacob reasonably expect to find a document reflecting
> those planned changes? Can you estimate how soon that point will be
> reached?
>
> At what point in the process could jacob reasonably assume that the
> absence of any changes means that the committee isn't planning to make
> any? Can you estimate when that point will be reached?
s/jacob/we/g and these are reasonable questions. That's not to
say I am particularly fussed about gets() staying in the next
standard or not. There are plenty of ways for undefined behavior
even without gets() so I don't think it makes any practical
difference.
James Kuyper
While jacob has frequently used wording that strongly implies that just
about every idea he disagrees with is either stupid or insane, I have to
admit that he seldom uses those exact words; and I'm not sure whether
has ever done so with respect to the committee.
A google search shows 81 hits for the query "stupid group:comp.lang.c
author:jacob author:navia", but the since Google won't take me to the
specific message that met the query, but only to the thread it was on,
it's a little hard to track down exactly how he was using the term. In
the cases I checked out, he was referring to "regulars" and Richard
Heathfield, but not the committee.
Richard Heathfield
No, he didn't. (He did call me a troll, but presumably that's
because he doesn't understand the term.)
Spiros Bousbouras
> Spiros Bousbouras said:
>
>
>
> > On 5 Mar, 05:31, jacob navia <ja...@nospam.org> wrote:
> >> James Kuyper wrote:
> >> > Finally, in the unlikely event that jacob ever decides to do
> >> > something more productive about these issues than complain in
> >> > this newsgroup about how stupid he thinks the committee is,
> >> > what should that something be, and what is the deadline for
> >> > doing it in time for this version of the standard?
>
> >> Look Mr
>
> >> (1) Nowhere I have insulted anyone, nor I am saying anywhere that
> >> some
> >> people are stupid. You are putting words on my mouth.
>
> > No he isn't. Earlier in the thread you called Richard Heathfield
> > a moron.
>
> No, he didn't. (He did call me a troll, but presumably that's
> because he doesn't understand the term.)
From http://tinyurl.com/cqs9g7
"I am not a "vendor" moron!"
jacob navia
> Spiros Bousbouras said:
>
>> On 5 Mar, 05:31, jacob navia <ja...@nospam.org> wrote:
>>> James Kuyper wrote:
>>>> Finally, in the unlikely event that jacob ever decides to do
>>>> something more productive about these issues than complain in
>>>> this newsgroup about how stupid he thinks the committee is,
>>>> what should that something be, and what is the deadline for
>>>> doing it in time for this version of the standard?
>>> Look Mr
>>>
>>> (1) Nowhere I have insulted anyone, nor I am saying anywhere that
>>> some
>>> people are stupid. You are putting words on my mouth.
>> No he isn't. Earlier in the thread you called Richard Heathfield
>> a moron.
>
> No, he didn't. (He did call me a troll, but presumably that's
> because he doesn't understand the term.)
>
Look, I replied to your "vendor" stuff with that. It was a knee-jerk
reaction, not really thought out.
In any case, I did not treat the standards committee of "stupids".
Keith Thompson
> Richard Heathfield wrote:
>> Spiros Bousbouras said:
>>> On 5 Mar, 05:31, jacob navia <ja...@nospam.org> wrote:
>>>> James Kuyper wrote:
>>>>> Finally, in the unlikely event that jacob ever decides to do
>>>>> something more productive about these issues than complain in
>>>>> this newsgroup about how stupid he thinks the committee is,
>>>>> what should that something be, and what is the deadline for
>>>>> doing it in time for this version of the standard?
>>>> Look Mr
>>>>
>>>> (1) Nowhere I have insulted anyone, nor I am saying anywhere that
>>>> some
>>>> people are stupid. You are putting words on my mouth.
>>> No he isn't. Earlier in the thread you called Richard Heathfield
>>> a moron.
>>
>> No, he didn't. (He did call me a troll, but presumably that's
>> because he doesn't understand the term.)
>>
>
> Look, I replied to your "vendor" stuff with that. It was a knee-jerk
> reaction, not really thought out.
Admitting that it was "not really thought out" is a good start. You
might also consider acknowledging that the numerous people who pointed
out that (a) yes, you are a vendor, and (b) calling someone a "vendor"
is not even vaguely an insult were right.
> In any case, I did not treat the standards committee of "stupids".
Perhaps, but you've certainly given the impression at times that you
hold them in some contempt.
lawrenc...@siemens.com
> lawrenc...@siemens.com writes:
> > There will be many more working documents (there's already a second one)
>
Yep.
> I see that the file is about a third the size of the previous draft,
> n1336.pdf; do you know why?
A different PDF distiller.
--
Larry Jones
I thought my life would seem more interesting with a musical
score and a laugh track. -- Calvin
lawrenc...@siemens.com
>
> maybe there a good reasons why things work the way they do. But the process
> zip around the world
Yes, there are lots of good reason for the standardization process
working the way it does, mostly having to do with fairness and
stability. And, as I've explained before, the barriers to participation
are also deliberate, primarily to help prevent dilettants from clogging
up the process with lots of spurrious proposals. It's also worth
pointing out, however, that the committee's "zipping around the world"
is *not* intended to prevent participation but to encourage it by
reducing travel costs for people in the general part of the world where
the meeting is being held. The barriers are intended to be easily
scaled by motivated participants, who are assumed to be commercial
entities. That's not necessarily a good assumption any more for
software-related standards, but it is still a valid assumption for the
vast majority of standards and the same rules apply to all. The powers
that be are beginning to recognize that software standards are
different, but standards for the standardization process change even
more slowly than other standards.
And, as I've also said a number of times before, anyone who is seriously
interestd but can't participate directly for whatever reason is free to
submit papers to the committee convener who will forward them to the
committee.
--
Larry Jones
I think my cerebellum just fused. -- Calvin
Keith Thompson
[...]
> And, as I've also said a number of times before, anyone who is seriously
> interestd but can't participate directly for whatever reason is free to
> submit papers to the committee convener who will forward them to the
> committee.
Contact information for the committee convener can be found at
<http://www.open-std.org/JTC1/SC22/WG14/www/contacts>.
Tea Pot
> I would like
> to present this code in a formal way to the committee but I can't
> afford to pay the plane tickets and hotel expenses for assiting to
> the committee meetings somewhere in China or in San Francisco.
Why don't you add a small surcharge to every license you sell for lcc to
support your contributions to the development of the Standard?
CBFalconer
> Phil Carmody wrote:
>
... snip ...
>
>> Which bit of 'obsolescent' and 'deprecated' do you not understand?
>
> standard. What I can't understand is
>
> (1) Why gets() is STILL in the standard text, since it is already
> declared deprecated it could be DROPPED now!
>
> (2) The only hint to its deprecation is in that footnote...
>
> (3) If it gets (no pun intended :-) into the standard it will
> remain there until 2020. And no, I can't understand that.
It is not deprecated in the current standard. Only in the draft
for the next standard. The purpose of deprecation is to warn that
a feature will probably be dropped in a future standard.
CBFalconer
>
... snip ...
>
> The only actions needed (since this function is ALREADY
> declared obsolescent) is to delete the text that describes
> it from the standard. This is very easy to do and needs no
> further justification.
Your information is flawed. It has not been declared obsolescent.
The only such declaration is in the drafts (repeat - drafts) for
the next (repeat - next) issure of the standard.
Keith Thompson
> jacob navia wrote:
>> Phil Carmody wrote:
>>
> ... snip ...
>>
>>> Which bit of 'obsolescent' and 'deprecated' do you not understand?
>>
>> This is since quite a while now. It is already in the current
>> standard. What I can't understand is
>>
>> (1) Why gets() is STILL in the standard text, since it is already
>> declared deprecated it could be DROPPED now!
>>
>> (2) The only hint to its deprecation is in that footnote...
>>
>> (3) If it gets (no pun intended :-) into the standard it will
>> remain there until 2020. And no, I can't understand that.
>
> It is not deprecated in the current standard. Only in the draft
> for the next standard. The purpose of deprecation is to warn that
> a feature will probably be dropped in a future standard.
It was first deprecated in C99 TC3. This is not a draft of the next
standard, it is a technical corrigendum for the current one. Unless
I'm very much mistaken, TC3 has the same official status as the
standard itself.
Richard Heathfield
Ah, I see - I parsed it as written, but presumably you are
postulating a missing comma. You may have a point. If so, he
doesn't understand the words "vendor" or "moron" either.
Richard Heathfield
> Richard Heathfield wrote:
>> Spiros Bousbouras said:
>>
>>> On 5 Mar, 05:31, jacob navia <ja...@nospam.org> wrote:
>>>> James Kuyper wrote:
>>>>> Finally, in the unlikely event that jacob ever decides to do
>>>>> something more productive about these issues than complain in
>>>>> this newsgroup about how stupid he thinks the committee is,
>>>>> what should that something be, and what is the deadline for
>>>>> doing it in time for this version of the standard?
>>>> Look Mr
>>>>
>>>> (1) Nowhere I have insulted anyone, nor I am saying anywhere
>>>> that some
>>>> people are stupid. You are putting words on my mouth.
>>> No he isn't. Earlier in the thread you called Richard Heathfield
>>> a moron.
>>
>> No, he didn't. (He did call me a troll, but presumably that's
>> because he doesn't understand the term.)
>>
>
> Look, I replied to your "vendor" stuff with that. It was a
> knee-jerk reaction, not really thought out.
I suggest that, in future, you think before posting. Up to you, of
course - just an idea.
> In any case, I did not treat the standards committee of "stupids".
I can't parse that. Sorry.
Golden California Girls
> jacob navia wrote:
> ... snip ...
>> (3) Concerning gets():
>> The only actions needed (since this function is ALREADY
>> declared obsolescent) is to delete the text that describes
>> it from the standard. This is very easy to do and needs no
>> further justification.
>
> Your information is flawed. It has not been declared obsolescent.
> The only such declaration is in the drafts (repeat - drafts) for
> the next (repeat - next) issure of the standard.
I suggest you obtain TC 1, 2 & 3 and incorporate them into your copy of the
standard as it is out of date.
In any case the standard must say that for any implementation that has a switch
to decetct depreciated things the default setting must be to reject them.
Keith Thompson
> CBFalconer wrote:
>> jacob navia wrote:
>> ... snip ...
>>> (3) Concerning gets():
>>> The only actions needed (since this function is ALREADY
>>> declared obsolescent) is to delete the text that describes
>>> it from the standard. This is very easy to do and needs no
>>> further justification.
>>
>> Your information is flawed. It has not been declared obsolescent.
>> The only such declaration is in the drafts (repeat - drafts) for
>> the next (repeat - next) issure of the standard.
>
> I suggest you obtain TC 1, 2 & 3 and incorporate them into your copy
> of the standard as it is out of date.
Or just grab a copy of
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>.
> In any case the standard must say that for any implementation that
> has a switch to decetct depreciated things the default setting must
> be to reject them.
Where did you get that? The standard says no such thing. And the
word is "deprecated", not "depreciated". (I don't usually bother to
correct spelling errors, but in this case the two words are related
but distinct.)
Golden California Girls
> Golden California Girls <gldnc...@aol.com.mil> writes:
>> CBFalconer wrote:
>>> jacob navia wrote:
>>> ... snip ...
>>>> (3) Concerning gets():
>>>> The only actions needed (since this function is ALREADY
>>>> declared obsolescent) is to delete the text that describes
>>>> it from the standard. This is very easy to do and needs no
>>>> further justification.
>>> Your information is flawed. It has not been declared obsolescent.
>>> The only such declaration is in the drafts (repeat - drafts) for
>>> the next (repeat - next) issure of the standard.
>> I suggest you obtain TC 1, 2 & 3 and incorporate them into your copy
>> of the standard as it is out of date.
>
> Or just grab a copy of
> <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>.
>
>> In any case the standard must say that for any implementation that
>> has a switch to decetct depreciated things the default setting must
>> be to reject them.
>
> Where did you get that? The standard says no such thing. And the
> word is "deprecated", not "depreciated". (I don't usually bother to
> correct spelling errors, but in this case the two words are related
> but distinct.)
[Thanks for the spelling correction, must be tax time.]
I know the standard doesn't. Opining a needed change. It won't break any code,
but may break makefiles which are outside the standard, so the standards
committee can truthfully say the change won't break anything in C. Perhaps
making it easier to get passed rather than removing deprecated items.
Antoninus Twink
> jacob navia said:
>> In any case, I did not treat the standards committee of "stupids".
>
> I can't parse that. Sorry.
Heathfield, your colonial-esque arrogance is truly unmatched. I can just
imagine you in a pith helmet lining up the native civilians and ordering
your troops to fire indiscriminately.
Richard
He's a christian. What did you expect from the ignorant arsehole?
Kenny McCormack
Remember, in Xtianity, it is perfectly justified to kill heathen natives
once you've "converted" them. This is absolutely true and non-debatable.
The whole point is, convert them (by whatever means necessary), then
kill them so that they can die in a state of grace.
If Xtianity is true (which by assumption it is), then the above is
unassailable by any logic.
lawrenc...@siemens.com
>
> If the committee were planning to make some changes to the next version
> of the standard to deal with gets() and asctime(), at what point in the
> process could jacob reasonably expect to find a document reflecting
> those planned changes? Can you estimate how soon that point will be
> reached?
The committee has very few plans to make any specific changes; what gets
done depends very much on what individual committee members and other
meeting attendees propose and work to refine. Which is why Jacob needs
to make a formal proposal to the committee and either attend a meeting
(or two) himself or get someone else to do so on his behalf if he really
wants to see any changes. It's likely that the committee will make a
"clean up" pass through the document that would include looking at
deprecated items and deciding whether to actually delete them or not,
but it likely won't be until fairly late in the process and there's no
guarantee that it will actually occur or that the committee will decide
to remove anything. And that would only address gets(), not asctime().
> At what point in the process could jacob reasonably assume that the
> absence of any changes means that the committee isn't planning to make
> any? Can you estimate when that point will be reached?
When the first CD (committee draft) is produced.
> Finally, in the unlikely event that jacob ever decides to do something
> more productive about these issues than complain in this newsgroup about
> how stupid he thinks the committee is, what should that something be,
> and what is the deadline for doing it in time for this version of the
> standard?
As I recall, the proposed timeline called for a CD at the end of this
year. My best guess is that that is probably not realistic and will
likely be sometime next year instead. Any proposals would need to be
made before then to have a realistic chance of being adopted. (Changes
after CD registration are usually limited to those of high importance or
very low impact [e.g., editorial changes].)
--
Larry Jones
ANY idiot can be famous. I figure I'm more the LEGENDARY type! -- Calvin
CBFalconer
>>
>>> (1) Why gets() is STILL in the standard text, since it is
>>> already declared deprecated it could be DROPPED now!
>>>
>>
>> It is not deprecated in the current standard. Only in the draft
>> for the next standard. The purpose of deprecation is to warn
>> that a feature will probably be dropped in a future standard.
>
> It was first deprecated in C99 TC3. This is not a draft of the
> next standard, it is a technical corrigendum for the current one.
> Unless I'm very much mistaken, TC3 has the same official status
> as the standard itself.
I was not aware that it appeared there. Learn something every
other day.
David Thompson
wrote:
> jacob navia wrote:
> > void function1(void)
> > {
> > va_list f = va_start(arg2);
>
> Nonsense, that should have been:
>
> void function1(int arg1, int arg2,...)
> {
> va_list f = va_start(arg2);
> ...
Minor point but for the record, actually
va_list f; va_start (f, arg2);