Microsoft abandons the C language

[Keith Thompson]

Look, what it is this languages of C11 and C99 what everyone talks about?
I never heard of them. C++, sure of course I know. C11 or C22 or Cff...
hocus pocus!

[...]

You've heard of them now, and you've been told more than once what
they are and where to find more information about them.

I believe you are deliberately trolling. If not, you are being
willfully ignorant. You are also making a fool of yourself in the
presence of a number of people who know much more about this than
you do. In any case, it appears that any further discussion with you
would be a waste of my time; your benefit of the doubt has run out.

*plonk*

And if you've never heard of that, see
<http://en.wikipedia.org/wiki/Plonk_(Usenet)>.

 

[Keith Thompson]

There's a need to distinguish between the various versions of the C
standard. That's all the numbers mean. The language "C" -- unadorned
with any numbers -- is, as of a short while ago, defined by a standard
that no compiler yet supports. In practice, all people now program in a
language that is not C as currently defined by ISO.

*All* people? There's plenty of code being written that's valid
C11, even if it doesn't use all the features of the language (very
few programs use all the features of whatever language they're
written in).

I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none), but I wouldn't make that argument myself. The source code
either is or is not conforming, regardless of what you do with it.

A lot of code does use implementation-defined features not defined
by any version of the standard, but not all of it does.

 

[Vincenzo Mercuri]

Il 30/08/2012 02:51, Keith Thompson ha scritto:
[..]

I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none)

[..]

There is a compiler, available only for Windows, that claims
to support C11. I've never used it, but if you are interested,
it's called "Pelles C": http://www.pellesc.de/

 

[Ben Bacarisse]

*All* people? There's plenty of code being written that's valid
C11, even if it doesn't use all the features of the language (very
few programs use all the features of whatever language they're
written in).

I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none), but I wouldn't make that argument myself. The source code
either is or is not conforming, regardless of what you do with it.

I intended the use of the verb "to program" to suggest that the intent
matters. A lot of code posted here would go though a C++ compiler but
the people who wrote it were not programming in C++.

Even with this interpretation (which I agree was not well put) you have
a point. There are certainly people who are deliberately programming in
C11 despite having to do so within the constraints of what their
implementation will accept.

 

[Ian Collins]

You probably use an extension language with all this strange stuff. For
example, in C you cannot have vla[size] where size is a variable. You
must do #define size 20 instead.

VLA's have been part of C since C99. Have you been living under a
rock for the past 13 years?

OK, so this is in "C99". I am talking here about C, not any extension
language.

They were included in IAL 58>> Algol 60.

52 years later and it's still a controversial idea?

Bad ideas don't improve with age!

 

[James Kuyper]

I just noticed a connection (or rather, lack thereof):

On 08/27/2012 04:58 PM, rashid wrote:
....

Sorry this is garbage. MSVC supports all C/C++ standards, also extra
features (eg C++ style // comments will be accepted in C programs too)

On 08/29/2012 04:00 PM, rashid wrote:
....

Look, what it is this languages of C11 and C99 what everyone talks about?
I never heard of them. C++, sure of course I know. C11 or C22 or Cff...
hocus pocus!

C90, C99, and C11 are the different versions of the C standard that you
claimed, above, that MSVC supports. If you don't know what the names of
those standard versions are, how could you feel so confident in your
(incorrect) claim that it supports all of them?

 

[Ben Bacarisse]

You probably use an extension language with all this strange stuff. For
example, in C you cannot have vla[size] where size is a variable. You
must do #define size 20 instead.

VLA's have been part of C since C99. Have you been living under a
rock for the past 13 years?

OK, so this is in "C99". I am talking here about C, not any extension
language.

They were included in IAL 58 >> Algol 60.

52 years later and it's still a controversial idea?

Just an observation I spotted recently: Paul Graham has argued that
programmers looking down the language power scale know they are looking
down ("Why would anyone program in language X? It doesn't even have
feature Y!") but programmers looking up often don't know they are looking
up. They see weird languages with hairy features that they've never
seen the need for.

No one else here would be so short-sighted, but I often think of this
whenever I see a hairy feature in some language I don't know.

 

[Keith Thompson]

Il 30/08/2012 02:51, Keith Thompson ha scritto:
[..]

I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none)

[..]

There is a compiler, available only for Windows, that claims
to support C11. I've never used it, but if you are interested,
it's called "Pelles C": http://www.pellesc.de/

Interesting. I installed it and I've been playing around with it. It
doesn't complain about a call to gets(), and I ran into a bug triggered
by:

#include <noreturn.h>
#include <stdlib.h>

(reversing the order avoids the error). Apart from that, I haven't seen
any failure to conform to C11.

So far, I'm impressed.

 

[jacob navia]

Le 29/08/12 22:00, rashid a écrit :

I am talking about the C language which MSVC++ will compile correctly,
and just as portable to Unix or Apple.

Apple?

Using my Mac (OS X 10.8.1) I compile that without any problems:
/tmp $ cat t1.c
#include <stdbool.h>
#include <complex.h>
#include <stdint.h>

static inline void foo(uint32_t *restrict p) {
}

int main(void) {
bool b = false;
int size = 20;
uint32_t vla[size];
double complex x;
foo(vla);
return 0;
}
/tmp $ gcc -std=c99 t1.c
/tmp $ uname -a
Darwin foo.org 12.1.0 Darwin Kernel Version 12.1.0: Tue Aug 14 13:29:55
PDT 2012; root:xnu-2050.9.2~1/RELEASE_X86_64 x86_64
/tmp $

 

[Vincenzo Mercuri]

Il 30/08/2012 06:38, Keith Thompson ha scritto:

Il 30/08/2012 02:51, Keith Thompson ha scritto:
[..]

I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none)

[..]

There is a compiler, available only for Windows, that claims
to support C11. I've never used it, but if you are interested,
it's called "Pelles C": http://www.pellesc.de/

Interesting. I installed it and I've been playing around with it. It
doesn't complain about a call to gets(), and I ran into a bug triggered
by:

#include <noreturn.h>
#include <stdlib.h>

(reversing the order avoids the error). Apart from that, I haven't seen
any failure to conform to C11.

So far, I'm impressed.

Oh, haha! Strange way to "support C11". It definitely doesn't,
but at least it confirmed being a Beta version (I'd say Alpha,
probably). However, thanks for bothering to install it.

 

[Keith Thompson]

Il 30/08/2012 06:38, Keith Thompson ha scritto:

Il 30/08/2012 02:51, Keith Thompson ha scritto:
[..]
I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none)
[..]

There is a compiler, available only for Windows, that claims
to support C11. I've never used it, but if you are interested,
it's called "Pelles C": http://www.pellesc.de/

Interesting. I installed it and I've been playing around with it. It
doesn't complain about a call to gets(), and I ran into a bug triggered
by:

#include <noreturn.h>
#include <stdlib.h>

(reversing the order avoids the error). Apart from that, I haven't seen
any failure to conform to C11.

So far, I'm impressed.

Oh, haha! Strange way to "support C11". It definitely doesn't,
but at least it confirmed being a Beta version (I'd say Alpha,
probably). However, thanks for bothering to install it.

What do you mean it "definitely doesn't"? I found two fairly minor
bugs in the implementation, both with easy workarounds. _Noreturn,
_Generic, <threads.h>, _Static_assert, and the various predefined
macros all seem to be ok.

 

[Vincenzo Mercuri]

Il 30/08/2012 13:00, Keith Thompson ha scritto:

Il 30/08/2012 06:38, Keith Thompson ha scritto:

Il 30/08/2012 02:51, Keith Thompson ha scritto:
[..]
I suppose you could say it's not C11 if it's not compiled with
a conforming C11 compiler (of which, as far as I know, there are
none)
[..]

There is a compiler, available only for Windows, that claims
to support C11. I've never used it, but if you are interested,
it's called "Pelles C": http://www.pellesc.de/

Interesting. I installed it and I've been playing around with it. It
doesn't complain about a call to gets(), and I ran into a bug triggered
by:

#include <noreturn.h>
#include <stdlib.h>

(reversing the order avoids the error). Apart from that, I haven't seen
any failure to conform to C11.

So far, I'm impressed.

Oh, haha! Strange way to "support C11". It definitely doesn't,
but at least it confirmed being a Beta version (I'd say Alpha,
probably). However, thanks for bothering to install it.

What do you mean it "definitely doesn't"? I found two fairly minor
bugs in the implementation, both with easy workarounds. _Noreturn,
_Generic, <threads.h>, _Static_assert, and the various predefined
macros all seem to be ok.

Sorry, I thought you said it ironically, given the rate at which you
found the two bugs mentioned. Good then, I've never used it, but I should
give it a try. I think we'd better report any bug through that contact
form linked in the homepage.

 

[James Kuyper]

On 08/29/2012 10:37 PM, Ben Bacarisse wrote:
....

Just an observation I spotted recently: Paul Graham has argued that
programmers looking down the language power scale know they are looking
down ("Why would anyone program in language X? It doesn't even have
feature Y!") but programmers looking up often don't know they are looking
up. They see weird languages with hairy features that they've never
seen the need for.

I know exactly what you mean. I've had to deal with several new
languages recently, including Haskall and Lua (at least, they're new to
me). Lua looks reasonably familiar, but Haskall leaves me feeling the
same way you describe. For all I know it may have some significant
advantages compared to the languages I'm more familiar with, at least
for some uses, but for now just the simple conceptual differences are so
daunting that it's difficult to imagine what those advantages might be.
Fortran I (sic) and APL were the first two computer languages I learned,
and I learned them equally easily - but that was three decades ago, and
my mind's a lot less flexible now. :-(

 

[Rui Maciel]

They were included in IAL 58 >> Algol 60.

52 years later and it's still a controversial idea?

Allocating memory without the means to check if the allocation was
successful and, if not, to gracefully recover from it is something that, in
spite of all those decades having passed, still doesn't sit well with some
people. That, and the segfaults that can be triggered by it.


Rui Maciel

 

[Rui Maciel]

Its the same allocation used everytime you call a function with the same
check for successful allocation of the stack frame.

There is a significant difference between allocating a couple of bytes, and
allocating buffers with an undetermined size. If you understand this
difference then you will be able to understand why VLAs, as they were added
to C, can be frowned upon.

Since that disturbs
you so much

If blowing up the stack doesn't disturb you then you are on the wrong line
of business, or not in the business at all. Others are, and they have to
anticipate any problem which might be caused by it.


Rui Maciel

 

[Keith Thompson]

Il 30/08/2012 13:00, Keith Thompson ha scritto: [...]

What do you mean it "definitely doesn't"? I found two fairly minor
bugs in the implementation, both with easy workarounds. _Noreturn,
_Generic, <threads.h>, _Static_assert, and the various predefined
macros all seem to be ok.

Sorry, I thought you said it ironically, given the rate at which you
found the two bugs mentioned. Good then, I've never used it, but I should
give it a try. I think we'd better report any bug through that contact
form linked in the homepage.

It looks like they want bug reports through their web forum at
<http://forum.pellesc.de/index.php>; bug reports are at
<http://forum.pellesc.de/index.php?board=3.0>.

My report on the <noreturn.h> problem is at
<http://forum.pellesc.de/index.php?topic=4733.0>.

 

[jacob navia]

Le 30/08/12 21:08, Rui Maciel a écrit :

There is a significant difference between allocating a couple of bytes, and
allocating buffers with an undetermined size. If you understand this
difference then you will be able to understand why VLAs, as they were added
to C, can be frowned upon.



If blowing up the stack doesn't disturb you then you are on the wrong line
of business, or not in the business at all. Others are, and they have to
anticipate any problem which might be caused by it.


Rui Maciel

I think your complaints can be addressed with

int fn(int siz)
{
int tab[siz<1000?siz:1000];
int *p;

if (siz >= 1000)
p = malloc(siz*sizeof(int));
else
p = &tab[0];
// Use p here instead of tab directly
// and at the end of the function:
if (siz >= 1000) {
free(siz);
}
}

If you know that your data will almost never go beyond 200 you will
almost always win, without EVER having a HARD-WIRED limit and using
almost always a fast stack allocation.

As you may know, VLAs DECREASE stack usage since in most cases
you do:

#define MAXDATA 2000
int fn(void)
{
int tab[MAXDATA];
}

even if you know that in most cases the data will be 200 or so.
WITH a FIXED stack allocation you have to go to the worst
case...

VLAs give you the needed flexibility.

 

[jacob navia]

Le 30/08/12 22:51, jacob navia a écrit :

int tab[siz<1000?siz:1000];

That should have been
int tab[siz<1000?siz:1];

of course, to avoid taking anyway 1000 bytes of stack even if we are
going to allocate it anyway.

 

[Nomen Nescio]

True, but Algol 60 wasn't designed on a fundamentally broken platform.

Don't kid yourself, plenty of things are still controversial 52 years later,
like the difference between FORTRAN and Fortran.

Allocating memory without the means to check if the allocation was
successful and, if not, to gracefully recover from it is something that, in
spite of all those decades having passed, still doesn't sit well with some
people. That, and the segfaults that can be triggered by it.

Well said. However, it is not true that all languages and all platforms
implement VLAs with such reckless disregard as C on POSIX platforms, there
/are/ ways to do this properly. However with the UNIX <-> POSIX <-> C <->
What About The Children (legacy code that must continue to fail identically
to the way it has always failed) hot potato tossing that typifies any
attempt to do anything correctly, this will never be fixed in UNIX, POSIX,
or C language.

 

[BartC]

Don't kid yourself, plenty of things are still controversial 52 years
later,
like the difference between FORTRAN and Fortran.

I suspect the denotation 'FORTRAN' used to be more popular simply because a
lot of equipment then only worked in upper case...