Re: How Ada could have prevented the Red Code distributed denial of service attack.

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Kaz Kylheku wrote:
> In article <3B7D2033.1C780DF5@home.com>, Warren W. Gay VE3WWG wrote:
> >Kaz Kylheku wrote:
> >> In article <3B7C9288.6CD8C288@home.com>, Warren W. Gay VE3WWG wrote:
> >> >When you can show the compiler's yacc grammer that specifically
> >> >addresses specific aspects of the STL (ie. specific to certain
> >> >class names), then you might have something.
> >>
> >> The C++ language is no defined by a yacc grammar.
> >
> >I'd be _real_ surprised if gcc does not use yacc to implement the C++
> >compiler. But even so, then let's move on..
> 
> GCC uses bison. GCC does not define the C++ language.

Oh, whine about big differences please. Bison is a yacc
knock-off if you havn't noticed. Good grief.. I don't believe
I had to address that here.

And of course GCC does not define the C++ language -- stop putting
words in my mouth.  But GCC is a good implementation to look at,
since source code is readily available for it.

> >> In the terminology that I'm using, a programming language is a broader
> >> container which contains components like ``grammar'' and ``library''.
> >>
> >> To call the language a grammar is to mistake the part for the whole.
> >
> >I agree with you on this, but you are putting words in my mouth. The
> >grammer does indeed help to define the language (its form and its
> >rules), but obviously is not the language itself.
> >
> >But what about this: What language does the STL use?
> 
> Use in what sense?

What is it written in?

> The library is kind of lexicon which makes available
> certain identifiers in certain categories. These categories come
> from the C++ syntax.

You tried hard not to say "language" here, didn't you =)

> Because those identifiers are available, the rest of my program which
> uses those identifers has a meaning which can be inferred from the
> semantic descriptions of those identifers in the standard.

Bzzzt! None of those identifiers would have any meaning without 
a language that defines how they are assembled together.

> >Hmmm.. lemme guess, it's probably C++ and perhaps a sprinkling of
> >is a _translated_ library, that is shipped with "include" files.
> >Again, the "include" files are written in C++.
> 
> I can't infer this requirement in the C++ standard. Can you cite
> a reference that standard headers must be files that are written in C++,
> or that there must must exist previously translated libraries
> as visible components?

Again, tell me what you call the source code that is contained in
the header files. Their written in C++ of course.

> As far as I can tell, when you write #include <iostream> that is
> simply a magic incantation 

Magic now?

> which makes certain identifiers
> available. Those identifiers behave ``as if'' they were introduced
> by C++ declarations.

Again, none of those declarations would have any value if there were
no language predefined that identified how they were assembled and
put together to create a translation (which is the object of this
process).

> >But wait a minute? You cannot define something in terms of itself.
> >So this leads to one of two conclusions:
> >
> >The language that the STL is written in is:
> 
> The language that the library it's written in is English. 

Oh... so now someone is using a "English-to-object code translater"
to produce your STL libraries now?  You mean your STL is not written
in any computer language? Don't be rediculous.

> How it's
> implemented is just an artifact of an implementation.

I'll concede that your STL could have been entirely written in Ada, or
assembler language. But we both know that no implementation of it will
be done that way. You say its unimportant. I say its very important
to this discussion, but you don't want to face it because it works
against your argument.

> Such artifacts do
> not define the language and do not necessarily provide a framework for
> clear, platform-independent reasoning about a language.
> 
> Note that many components of a standard library cannot be written in
> that language. Only their interface can be expressed as a declaration
> that language. (How can you write, say, the time() function in C
> without invoking some platform-specific system service, or
> accessing clock hardware?)

I already said that parts of it will not be C++. So what's your point?

> The C99 standard has introduced a new header containing type-generic
> macros for math functions <tgmath.h>. There is no way to write these
> type-generic macros in C99! So tell me, what language are they
> ``written'' in?

I have to confess ignorance on this feature, because I have not seen
this C99 feature yet.

> Lastly, same languages have very little syntax at all; 

But we're not talking about some languages, but C++.

> everything is
> done with standard functions, or forms that resemble them. 

But even they have a language (which includes rules, grammer) that 
defines how those functions are invoked.

> You could
> argue that (cons ...) is not part of Lisp, but merely a library function
> for constructing and initializing a cons cell; the only things that are
> part of the language are parentheses, macro characters, quotes and a few
> other elements of the read syntax. Yet, the majority of programs would
> lose their meaning if (cons) were removed. There are special operators,
> but any of those could be implemented using macros. So there is no way
> to draw the division about what is core and what can be implemented as a
> library.

I know what you're saying above, but this last statement is simply
rubbish. Admitedly, there are some grey areas but as a practicle
concession, everyone (else) uses a division between language and library
for very practicle reasons. You for some reason, have an aversion to it.

> The syntax alone doesn't provide that core, because you'd have
> nothing to bootstrap with. There are may ways of choosing the core subset
> of special forms that will be intrinsic; it's an implementation choice.

But without the core language, and a compiler that supports it, you
cannot compile your STL _library_. The STL is written in something,
which is not English. I mean, what do
you call that source code that makes up the STL? Not english, not object
code, hmmm, source language code, yes-- and what source code is 
that? -- its C++.

> >  - or the STL is not part of the C++ language proper. As such, it
> >    only enhances the usefulness of the C++ language, as a _library_
> 
> ``language proper'' is just a synonym for ``grammar'' or ``syntax''.
> It's not a synonym for ``language''.

So you say... but that is not completely what I said.

In conclusion, and this will be my last word on it, since I can already
see that whatever I post here, you'll just reject anyway. For the
benefit of the other readers, I'll just conclude with this thought,
and move on:

I know the point that you are making.. yes, there is a sense that 
libraries and other tools (macros) enhance the use of the "facility", 
if you will. Language standards may even mandate that certain library
facilities be provided (as does Ada95), but you'll note that these
documents usually recognize that these components are library components
(or macro facilities).

So there is still a practical distinction between the language and 
the libraries, even though they may be specified in a language standard,
or standards document.

As someone else has pointed out, the standards committees have already
made these distinctions between language, library and environment(?).
This by itself shows a practical recognition by the defining standards
committe that these are valid classifications to make, and used for 
very practical purposes. 
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg