ietf-mxcomp
[Top] [All Lists]

RE: Why not XML

2004-06-23 20:32:15

But as the CodeRed Principle as shown, there will always be 
enough of a legacy market to still be effective.  

Yes, but the point I am making is that when you compare the
vulnerabily of deployed, tested code (most XML parsers) vs
a new syntax that is less than a year old you cannot fairly
make the claim that the new code is likely to be safer.

SPF is already a very complex syntax requiring about the same
number of state transitions as syntactic parsing of the XML 
format.

Over the years, can you vouch for Microsoft having a solid 
engineering team with enough foresight? 

Over the years Bill has hired rather a lot of good people,
do not blame the current employees of the company for the
consequences of a twenty year old code base and supporting
every device ever built by any manufacturer.


Anyway,  can you vouch that some undocumented enbedded XML 
attribute that
does some undocumented logic doing the object instantiation 
and parsing is not going to be there?

Actually yes I can for the interfaces I use. 

And in any case, if you are still using a language that is 
vulnerable to
buffer overflow issues you are a decade out of date.

Phillip good point, but it might not be the language but the 
API or the
library you are using!. In this case, the XML API 
components/library or
sub-system! 

Then code the stuff yourself. 

The amount of effort that has gone into this thread could
have generated six XML parsers.

I would have written one myself and posted it to the list if
I had not been submerged with phishing attacks.

#define strncpy()  exit(-1)

Remember, there is no such thing as a bad language, just bad 
programmers.

No, there are bad languages.

Pascal is Wirthless as one Turing award winner once commented.

The lack of bounds checking in C was negligent even at the time.
There are no buffer overrun problems in any other commonly used
language - except through calls to C substrates.


<Prev in Thread] Current Thread [Next in Thread>