Free C Compiler on Windows

[Spiros Bousbouras]

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]

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]

No he isn't. Earlier in the thread you called Richard Heathfield
a moron.

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.

 

[Spiros Bousbouras]

Spiros Bousbouras said:





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:


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]

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.

 

[lawrence.jones]

Would that be http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf?
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.

 

[lawrence.jones]

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

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.

 

[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>.

 

[CBFalconer]

Phil Carmody wrote:
.... snip ...


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.

 

[CBFalconer]

.... 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.

 

[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?

 

[Keith Thompson]

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.

 

[Keith Thompson]

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

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.)

 

[Antoninus Twink]

jacob navia said:

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]

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.

He's a christian. What did you expect from the ignorant arsehole?

 

[Kenny McCormack]

He's a christian. What did you expect from the ignorant arsehole?

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.

 

[lawrence.jones]

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].)

 

[CBFalconer]

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]

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);