[SystemSafety] C++ and Pointers
David Crocker
dcrocker at eschertech.com
Wed Jun 5 21:42:13 CEST 2019
Peter,
You are purposefully ignoring the fact that there are many C and C++
subsets and associated static analysers to avoid implicit type
conversions and other poorly-designed features of the C language (most
but not all of which have been inherited into C++). I think we can all
agree that C and C++ should never be used to write high integrity
software without the use of such a subset and associated enforcement tool.
Regards
David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486
On 05/06/2019 20:28, Peter Bernard Ladkin wrote:
>
> On 2019-06-05 21:04 , David Crocker wrote:
>>>> That is, "memory location" is the only strong data type in C++.
>> <<
>>
>> Not at all. Enumerations are strong types (use "enum class" to avoid default conversions to int),
> Any data type which uses a programmer instruction to avoid conversions is not strong.
>
>> so
>> are all user-defined classes unless <you say not>
> Any data type which allows a programmer instruction to allow conversions is not strong.
>
>> The unwelcome
>> implicit narrowing conversions between numeric types are easily avoided ......
> If you employ programmers willing to easily avoid them.
>
> This is no longer an aesthetic issue, as people have been suggesting for a couple of decades. The
> majority of exploitations in CVE databases are some input string rendering a device non-functional.
> Ways of avoiding "bad input" by relying on programmers and designers to "do the right thing" are
> continuing not to work, into what is now the third decade of such cybersecurity problems.
>
> PBL
>
> Prof. Peter Bernard Ladkin, Bielefeld, Germany
> MoreInCommon
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319 www.rvs-bi.de
>
>
>
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190605/705500c5/attachment.html>
More information about the systemsafety
mailing list