曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

Probably the most common misuse in practically all-programming languages is that of uninitialized
variables. This mistake is very hard to catch because unit testing will not flag it unless explicitly designed to
do so. The typical manifestation of this error is when a program that has been working successfully is run
under different environmental conditions and the results are not as expected.
Calls to de-allocate memory should be examined to make sure that not only is the pointer released but that
the memory used by the structure is released.
The order of evaluation of operands when side effects from function calls modify the operands is generally
dismissed as poor programming practice but in reality is an issue that is poorly defined (no standard of any
type has been defined) and arbitrarily resolved by implementers of language compilers.
Method of Assessment
The technique used to compare programming languages will not deal with differences among manufacturers
of the same language. Compiler vendor implementations, by and large, do not differ significantly from the
intent of the standard, however standards are not unambiguous and they are interpreted conveniently for
marketing purposes. One should be aware that implementations will not adhere 100% to the standard
because of the extremely large number of states a compiler can produce. The focus of this study then is to
review the definition of a few languages for certain characteristics that will provide for the user a shell
against inadvertent misuse. When evaluating a language, the following questions should be asked of the
language as a minimum:
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-19
·  Can it be shown that the program cannot jump to an arbitrary location?
·  Are there language features that prevent an arbitrary memory location from being
overwritten?
·  Are the semantics of the language defined sufficiently for static code analysis to be
feasible?
·  Is there a rigorous model of both integer and floating point arithmetic within the
standard?
·  Are there procedures for checking that the operational program obeys the model of the
arithmetic when running on the target processor?
·  Are the means of typing strong enough to prevent misuse of variables?
·  Are there facilities in the language to guard against running out of memory at runtime?
·  Does the language provide facilities for separate compilation of modules with type
checking across module boundaries?
·  Is the language well understood so designers and programmers can write safety-critical
software?
·  Is there a subset of the language which has the properties of a safe language as
evidenced by the answers to the other questions?
J.5.11 Formal Methods and Safety-Critical Considerations
In the production of safety-critical systems or systems that require high assurance, Formal Methods* provide
a methodology that gives the highest degree of assurance for a trustworthy software system. Assurance
cannot be measured in a quantitative, objective manner for software systems that require reliability figures
that are of the order of one failure in 10
9
hours of operation. An additional difficulty that software reliability
cannot address to date, in a statistically significant manner, is the difference between catastrophic failures
and other classes of failures.
Formal Methods have been used with success on both military and commercial systems that were considered
safety-critical applications. The benefits from the application of the methodology accrue to both safety and
non-safety areas. Formal Methods do not guarantee a precise quantifiable level of reliability; at present they
are only acknowledged as producing systems that provide a high level of assurance.
On a qualitative level the following list identifies different levels of application of assurance methods in
software development. They are ranked by the perceived level of assurance achieved with the lowest
numbered approaches representing the highest level of assurance. Each of the approaches to software
development is briefly explained by focusing on that part of the development that distinguishes it from the
other methods.
Formal development down to object code requires that formal mathematical proofs be
carried out on the executable code.
Formal development down to source code requires that the formal specification of the
system undergo proofs of properties of the system.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-20
Rigorous development down to source code is when requirements are written in a formal
　
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊下(138)