Microsoft abandons the C language

[Ben Bacarisse]

It was an honest attempt to help you out - though I found it hard to
imagine that your English skill were that bad. However, I had to assume
that they were that bad - if they weren't, you would have had no reason
to ask what "it" was.

What a position to be in, what does one do? If you explain one of the
basic words of the English language it will make me look stupid, but
clearly I need help. Left with "it" unexplained I might continue to
embarrass myself by asking about what "it" is. It's a bind and I'm
sorry I put you in such a difficult position.

Now that I know that you did know what "it" was,
I'm mystified by your decision to ask a question you already knew the
answer to.

And now, you are forced to form yet another low opinion of me. I am
feart to explain further lest it drop even lower.

<snip>

 

[James Kuyper]

What a position to be in, what does one do? If you explain one of the
basic words of the English language it will make me look stupid, but
clearly I need help. Left with "it" unexplained I might continue to
embarrass myself by asking about what "it" is. It's a bind and I'm
sorry I put you in such a difficult position.


And now, you are forced to form yet another low opinion of me. I am
feart to explain further lest it drop even lower.

I thought I should place my response in context. My wife's not a native
speaker of English, and her English is somewhat poor (though nowhere
near as bad as my Mandarin). She has given me not merely permission, but
orders, to correct her English whenever I notice her making a mistake,
even when it feels rude to do so (as it often does). As a result, I've
gotten into the habit of both a) expecting that oddly worded statements
and questions often indicate a misunderstanding of English, and b)
trying to correct that misunderstanding. I apologize for providing
unneeded explanation. But it was an odd question to be asking.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×™×©×™, 7 בספטמבר 2012 23:59:19 UTC+1, מ×ת James Kuyper:

I'm still lost. Static analysis can be done when some aspects of what's
being analysed depends on input, can't it? When I prove termination of
a loop, that's static analysis is it not? The proof can be often done
even when the loop conditions and execution depend on input. It would
be rather pointless otherwise.

So I gave the example of a loop governed by an input 64 bit integer.

"It depends" is a bit of a loose way of talking. It is static analysis if you can prove that the loop will terminate, in a mathematical sense. But it's a useless static analysis for any practical purposes.

 

[Ben Bacarisse]

בת×ריך ×™×•× ×©×™×©×™, 7 בספטמבר 2012 23:59:19 UTC+1, מ×ת James Kuyper:

Both quotations have the wrong attribution.

So I gave the example of a loop governed by an input 64 bit integer.

"It depends" is a bit of a loose way of talking. It is static analysis
if you can prove that the loop will terminate, in a mathematical
sense. But it's a useless static analysis for any practical purposes.

I disagree. The proof shows the absence of one particular kind of
problem. That's valuable to know: for some instances (particularly very
long running instances) you know it's not fruitless to wait a bit longer
for a result. Even if all expected input are cases that will
effectively "run forever" you have at least got one matter settled: the
problem is not termination, per se, but running time.

What this has to do with VALs, I don't know.

 

[Ben Bacarisse]

.€. .€.Ben Bacarisse.€.
<.€[email protected].€.>
.€.wrote.€.:.€.

etc.

Something went wrong here. Your post has no Content-Type header and
whatever guess my newsreader made, it look like the wrong one.

<snip>

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,8 בספטמבר 2012 14:29:49 UTC+1, מ×ת Ben Bacarisse:

I disagree. The proof shows the absence of one particular kind of
problem. That's valuable to know: for some instances (particularly very
long running instances) you know it's not fruitless to wait a bit longer
for a result. Even if all expected input are cases that will
effectively "run forever" you have at least got one matter settled: the
problem is not termination, per se, but running time.

If the input is a random, unsigned 64 bit value, the computer will almost
certainly break long before the loop will terminate. So the analysis is
useless as a description of how the system will behave.

 

[Ben Bacarisse]

בת×ריך ×™×•× ×©×‘×ª, 8 בספטמבר 2012 14:29:49 UTC+1, מ×ת Ben Bacarisse:
If the input is a random, unsigned 64 bit value, the computer will almost
certainly break long before the loop will terminate. So the analysis is
useless as a description of how the system will behave.

You seem to be talking about an odd program you've dreamt up that uses
huge random input as a loop counter and has no apparent purpose other
than to be an example of where arguments about loops become pointless.
You are right, some silly programs should not have any static analysis
done on them. Is that the point you were trug to make?

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,8 בספטמבר 2012 17:39:52 UTC+1, מ×ת Ben Bacarisse:

You seem to be talking about an odd program you've dreamt up that uses
huge random input as a loop counter and has no apparent purpose other
than to be an example of where arguments about loops become pointless.
You are right, some silly programs should not have any static analysis
done on them. Is that the point you were trug to make?

But you also get analogous problems with more realistic problems.

Consider this

marks = load100marks();
qsort(marks, 100, sizeof(struct mark), compmarks);

How much stack does it use? The maximum is probably 100 nested calls. But that
can only happen if the input has been deliberately arranged so that qsort
shows pessimal performance. The chance of it happening by accident is 1/100! Again, the computer is more likely to break.
But what's the chance of someone deliberately arranging the input to break the program? You can't answer that by static analysis.

So it depends what you mean.

 

[Ben Bacarisse]

בת×ריך ×™×•× ×©×‘×ª, 8 בספטמבר 2012 17:39:52 UTC+1, מ×ת Ben Bacarisse:
But you also get analogous problems with more realistic problems.

Consider this

marks = load100marks();
qsort(marks, 100, sizeof(struct mark), compmarks);

How much stack does it use? The maximum is probably 100 nested calls. But that
can only happen if the input has been deliberately arranged so that qsort
shows pessimal performance. The chance of it happening by accident is 1/100! Again, the computer is more likely to break.
But what's the chance of someone deliberately arranging the input to break the program? You can't answer that by static analysis.

So it depends what you mean.

I don't see how it depends on what I mean. What did I say (more
specifically what interpretation of something I said) makes this example
pertinent? Did I somehow suggest that all analyses are always useful in
all cases? As far as I recall, the only assertion I make is that static
analysis is no precluded by the use of VLAs.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,8 בספטמבר 2012 22:29:04 UTC+1, מ×ת Ben Bacarisse:

I don't see how it depends on what I mean. What did I say (more
specifically what interpretation of something I said) makes this example
pertinent? Did I somehow suggest that all analyses are always useful in
all cases?

You said "if I can prove such and such about the behaviour of a program that
depends on its input, am I doing static analysis or not?". The exact example
you used was proving that loop would terminate, even though the stopping condition was determined by input. The answer is "it depends what you mean".
In a formal sense you can prove things, but "static analysis" implies "a
useful static analysis". Then the examples where the static analysis may
be problematic are by no means contrived.

If you mean "if we can calculate maximum bounds for the vlas, can we usually prove that the stack limit won't be breached?" the answer is obviously "yes".

 

[Ben Bacarisse]

בת×ריך ×™×•× ×©×‘×ª, 8 בספטמבר 2012 22:29:04 UTC+1, מ×ת Ben Bacarisse:
You said "if I can prove such and such about the behaviour of a
program that depends on its input, am I doing static analysis or
not?". The exact example you used was proving that loop would
terminate, even though the stopping condition was determined by
input. The answer is "it depends what you mean". In a formal sense
you can prove things, but "static analysis" implies "a useful static
analysis". Then the examples where the static analysis may be
problematic are by no means contrived.

That is exactly what I thought you meant.

<snip>

 

[BartC]

or a[v] is big or v is not know in the run time
] one has to verify if stack variable are ok

how the a compiler can do that: i don't know...

In these days of modern times any system with halfway decent VM will leave
unmapped pages around the stack so that overflows will page fault which
sends an
overflow indication to the program.

That still depends on rational stack frame size. For example on a 32 bit
machine, allocating auto char a[300000000000] could move stack pointers
past
guard pages and still kill the heap or anything else.

The compiler will know about such a large allocation and generate
appropriate code that does extra checks (if it thinks it's likely to skip a
page).

Although your example of allocating 300GB will likely generate a
compile-time error.

 

[lawrence.jones]

And how are VLA's more efficiently implementable in those environments?

The context in which they can occur is much more limited. Imagine what
would happen in a typical implementation if a call to alloca() occured
in the middle of the argument list to a function call: you've got some
arguments pushed on the stack, then the allocated space, then some more
arguments....

 

[Kaz Kylheku]

And how are VLA's more efficiently implementable in those environments?

The difference is that the people who wrote the above weren't
armchair language inventors masquerading as an ISO committee.

They were doing the proper job of taking stock of what is there, codifying
it and in general doing what was necessary, and avoiding what was
unnecessary.

 

[Kaz Kylheku]

The context in which they can occur is much more limited. Imagine what
would happen in a typical implementation if a call to alloca() occured
in the middle of the argument list to a function call: you've got some
arguments pushed on the stack, then the allocated space, then some more
arguments....

That can all be "specified away". Implementations of alloca usually publish
various restrictions on its use. It would not be the first half-broken,
fragile thing that is specified in C. Like, oh, how non-volatile locals
turn into a pumpkin if they are modified between setjmp and longjmp.

The quote from the Rationale above is all we have as the reason for why alloca
was not codified, and we have to take that as the complete reason.

Nothing is said about any contextual problems with where alloca calls may be
placed.

 

[lawrence.jones]

That can all be "specified away". Implementations of alloca usually publish
various restrictions on its use.

The standard would have to codify the union of all the restrictions from
all of the implementations, some of which *aren't* documented, in order
to allow the existing implementations to conform. If it missed any, then
impacted implementations would have to change (presumably in an
undesirable fashion) or remain non-conforming.

 

[jacob navia]

Le 23/08/12 20:05, jacob navia a écrit :
[snip]

Another problem. The interfaces in the header files of windows are no
longer written in C but in a language that is exclusively understood by
the microsoft compilers.

For example:

HRESULT (STDMETHODCALLTYPE *IsEqualObject )(__RPC__in IObjectIdentity
*This, __RPC__in_opt IUnknown *punk);

Problem is that there are HUNDREDS of "__RPC__in" or "__RPC__in_opt"
"__RPC__IN_opt_count_extended" etc.

Obviously this is not defined anywhere apparently, it is assumed that
the compiler understand all those annotations that have NO prefix that
would identify them easily...

You have to make a file like

#define __RPC__in
#define __RPC__in_out
#define __RPC_in_out_opt
#define inout
#define out
#define optional
#define OPTIONAL

and that file will get HUGE because there are hundreds of those

 

[Öö Tiib]

Le 23/08/12 20:05, jacob navia a écrit :
[snip]

Another problem. The interfaces in the header files of windows are no
longer written in C but in a language that is exclusively understood by
the microsoft compilers.

Big surprise. The header files of Windows API are specially made for MS
compilers. That started long ago when Borland's compilers and IDEs for MS
operating systems were more popular than MS's own. So MS decided that
Borland has to suck egg and added lot of argle-bargle into API headers.
They got even farther with some APIs. Type library is in some DLLs.
Nothing to #include. Instead write something like:

#import <msxml.dll> // xml API "included"
#import <msado15.dll> // ado API "included"

So ... you are still lucky if it looks like C, more or less and so you
can still adopt some other compiler or use some non-MS tool.

 

[Kaz Kylheku]

Le 23/08/12 20:05, jacob navia a écrit :
[snip]

Another problem. The interfaces in the header files of windows are no
longer written in C but in a language that is exclusively understood by
the microsoft compilers.

When has that not been the case? Windows doesn't come with any header files.
They are part of a development SDK from Microsoft which comes with a compiler.

If you develop your own compiler, you develop and supply your own headers.

Likewise, the header files in a GNU Linux system are only understood by a
compiler which implements a myriad GCC extensions.

Speaking of GCC: its build system contains scripts to "fix up" system headers.
Traditionally, you would install GCC as a secondary compiler on some
proprietary system (usually a Unix). For GCC to be usable, it had provide all
the system programming header files, like <sys/types.h> or <unistd.h>. But,
the ones on the system were not necessarily usable with GCC. So GCC would make
a copy of the headers elsewhere, fix them up, and then use the fixed up copies.