Topic: Re: [std-proposals] Enforcing safe coding techniques
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Wed, 14 Mar 2018 00:02:25 +0000
Raw View
--001a113cf3deb1e44805675417a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
In short, I don't support this. Language features aren't safe or unsafe, it
depends how you use them. Having really safe code would be unacceptable, as
that would mean no UB and thus incur a performance overhead, which I don't
want.
The compiler would not be able to enforce this as a result.
On Tue, Mar 13, 2018, 7:32 PM Mikl=C3=B3s P=C3=A1l <palmiklos@gmail.com> wr=
ote:
> Hi All,
>
>
> Im sharing my idea about making C++ language more suitable for safer
> coding. This is not a new attempt to create a new safe subset of the C++
> language. This is more an attempt to take the benefit of both safety
> enforcements and unrestricted coding.
>
> Fair enough.
>
> Thanks in advance for your comments.
>
> The problem
>
>
> Modern C++ standards introduce more and more safe constructions, which ca=
n
> replace unsafe coding techniques. However, C++ still allows these unsafe
> coding techniques for compatibility. Unsafe techniques in large source
> code, maintained by many people, makes software quality assurance
> difficult. The modern, so called =E2=80=9Cinherently safe=E2=80=9D langua=
ges can answer
> this problem somehow, but unlike C++, they can=E2=80=99t provide the dire=
ct control
> over the inherently unsafe hardware.
>
> Observation
>
>
> We can divide our source code into two parts:
>
>
> 1. Safe part, which can be constructed using only safe coding techniques.
> This is usually the largest part of the source code.
>
>
> 2. Unsafe part, in which we can=E2=80=99t avoid using unsafe techniques, =
but we
> can proof the safety of such solutions. These can be very small and
> isolated code parts. Usually these parts are the small building blocks of
> the safe part.
>
>
> Example:
>
>
> We can use a vector template class and its iterators safely throughout ou=
r
> source code, instead of using unsafe arrays and pointers. But we need an
> implementation for that vector class, which can only be built upon unsafe
> operations. The safety of the whole code, regarding to the usage of our
> vector class, is provided by the proof the correctness of that
> implementation.
>
That's not true. Iterators are not inherently safer than pointers. It all
depends on how you use them.
If you dereference an out-of-range pointer, you get UB.
If you dereference an out-of-range iterator, you get UB.
Also, the reason std::array exists is not because language arrays are
unsafe, it's because they support more operations.
>
> The proposed solution
>
>
> We should qualify the two parts of the source code mentioned above. Also
> we need to define, which coding techniques we consider unsafe, and suppos=
e
> that the compiler can recognize them.
>
It's not that easy:
// Unsafe, iterator might be out-of-range
template<typename It>
void getNext(It iterator) { ++iterator =3D {}; }
// 100% safe
template<typename T>
T get(T *Ptr) { return Ptr ? *Ptr : T(); }
Would you say that the first is safe and the second unsafe?
> Proposed qualifiers:
>
>
> =E2=80=9Csafe=E2=80=9D: qualifies functions, where unsafe coding techniqu=
es are not
> allowed by the compiler.
>
>
> =E2=80=9Ctrusted=E2=80=9D: qualifies functions, where unsafe coding techn=
iques are
> allowed, but their correctness is proven by the author.
>
>
> Unqualified code: functions, where unsafe coding techniques are allowed,
> and their correctness is unknown.
>
>
> We can either add our qualifiers as new reserved words to the language, o=
r
> we can use other syntax such as attributes. At this level of this proposa=
l,
> the syntax is not decided.
>
>
> We need to allow these qualifiers on global and member functions, functio=
n
> pointers, and on other language constructions related to function
> implementations and their execution. Lambda functions may inherit the
> qualification of the function that they are defined within.
>
>
> Rules
>
>
> - Safe functions shall not contain unsafe language constructions.
>
>
But then a lot of types would be unsafe that you consider here to be safe.
Allocators would use pointers for example. How would that work?
> - Trusted and unqualified functions may contain unsafe language
> constructions.
> - Safe and trusted functions can call only safe and trusted functions.
> - Unqualified functions can call any functions.
> - Safe and trusted function pointers shall be assigned from either
> safe or trusted functions or function pointers.
> - Unqualified function pointers can be assigned from any functions or
> function pointers.
> - Same rules for initialization of references.
>
> Usage
>
>
> Qualify all the entry points of your application as safe. This results
> that the whole call tree of that application is enforced to consist of
> either safe or trusted functions. Qualify as much of the source code as y=
ou
> can safe, and move the smallest unsafe
>
> code blocks to trusted functions. Proof the correctness of these trusted
> functions.
>
> Notes
>
>
> - The basic idea behind the rules above is that safe and trusted
> functions are equally safe. The difference between them is that the sa=
fety
> of =E2=80=9Csafe=E2=80=9D functions is provided by the compiler, while=
the safety of
> =E2=80=9Ctrusted=E2=80=9D functions is provided by the author of their=
source code.
> - Standard and third party library functions are expected to be
> qualified. Legacy library functions known to be unsafe, such as strcpy=
,
> must be unqualified.
> - The qualification of the main entry point function doesn't imply
> qualification of constructors and destructors of static objects. They =
need
> to be qualified additionally.
>
> Useful tools
>
>
> For quality assurance of an application having large source code we need =
a
> tool for detecting changes on trusted source code, or addition of new
> trusted code. Quality assurance of the changed and added source code need
> to be done or redone.
>
> Digital signatures on code blocks (possibly in comments) can be used to
> proof that trusted source code parts has been quality assured by the auth=
or.
>
> Implementation notes
>
>
> The implementation of the new rules requires some changes in the linkage
> of functions. This change may affect the whole toolchain creating and
> processing object code.
>
>
> Safe and unsafe coding techniques
>
>
> This proposal at this level is not about defining, which C++ source code
> constructions are unsafe. However, at first thoughts, just some unsafe
> examples: pointer arithmetic, indexing of raw arrays, =E2=80=9CC=E2=80=9D=
style functions
> having variable number of arguments, but not including compile time
> verifiable formatted input/output. RAII for memory allocation can be
> enforced by considering =E2=80=9Cnew=E2=80=9D and =E2=80=9Cdelete=E2=80=
=9D keywords unsafe.
>
All of those aren't intently inherently unsafe though. new/delete have
their place and aren't unsafe, pointer arithmetic is safe in certain.
I don't think you can generalize and consider certain features as safe or
unsafe, because it depends on what you do with them.
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/245f1f1b-d16=
8-4434-a605-f82bff4a99af%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/245f1f1b-d1=
68-4434-a605-f82bff4a99af%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALmDwq0dMPLNhnLoG-z8traY-F%2B%3DFv51_4-7sE%3D5U=
%3D6p2DfVBA%40mail.gmail.com.
--001a113cf3deb1e44805675417a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><p style=3D"font-family:sans-serif;font-size:12.8px"=
><span style=3D"font-size:large">In short, I don't support this. Langua=
ge features aren't safe or unsafe, it depends how you use them. Having =
really safe code would be unacceptable, as that would mean no UB and thus i=
ncur a performance overhead, which I don't want.</span></p><p style=3D"=
font-family:sans-serif;font-size:12.8px"><span style=3D"font-size:large">Th=
e compiler would not be able to enforce this as a result.</span></p><p styl=
e=3D"font-family:sans-serif;font-size:12.8px"><span style=3D"font-size:larg=
e">On Tue, Mar 13, 2018, 7:32 PM Mikl=C3=B3s P=C3=A1l <<a href=3D"mailto=
:palmiklos@gmail.com">palmiklos@gmail.com</a>> wrote:</span><br></p><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<h1>Hi All,</h1><p><br></p><p>Im sharing my idea about making C++ language =
more suitable for safer coding. This is not a new attempt to create a new s=
afe subset of the C++ language. This is more an attempt to take the benefit=
of both safety enforcements and unrestricted coding.</p><p></p></div></blo=
ckquote></div></div><div dir=3D"auto">Fair enough.</div><div dir=3D"auto"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
p><br></p><p><span id=3D"m_-4661574982183608709result_box" class=3D"m_-4661=
574982183608709short_text" lang=3D"en"><span>Thanks in advance for your com=
ments.</span></span></p><h1><br></h1><h1><span lang=3D"EN-US">The problem</=
span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Modern C++ standards
introduce more and more safe constructions, which can replace unsafe coding
techniques. However, C++ still allows these unsafe coding techniques for
compatibility. Unsafe techniques in large source code, maintained by many
people, makes software quality assurance difficult. The modern, so called
=E2=80=9Cinherently safe=E2=80=9D languages can answer this problem somehow=
, but unlike C++, they
can=E2=80=99t provide the direct control over the inherently unsafe hardwar=
e.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">Observati=
on</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We can
divide our source code into two parts:</span></p><p class=3D"MsoNormal"><sp=
an lang=3D"EN-US"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">1. Safe
part, which can be constructed using only safe coding techniques. This is
usually the largest part of the source code.</span></p><p class=3D"MsoNorma=
l"><span lang=3D"EN-US"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">2. Unsafe
part, in which we can=E2=80=99t avoid using unsafe techniques, but we can p=
roof the
safety of such solutions.</span><span lang=3D"EN-US"> </span><span lang=3D"=
EN-US">These can be very small and isolated code
parts. Usually these parts are the small building blocks of the safe part.<=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span></p><p class=3D"MsoN=
ormal"><span lang=3D"EN-US">Example:</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span></p><p class=3D"MsoN=
ormal"><span lang=3D"EN-US">We can use
a vector template class and its iterators safely throughout our source code=
,
instead of using unsafe arrays and pointers. But we need an implementation =
for
that vector class, which can only be built upon unsafe operations. The safe=
ty
of the whole code, regarding to the usage of our vector class, is provided =
by
the proof the correctness of that implementation.</span></p></div></blockqu=
ote></div></div><div dir=3D"auto">That's not true. Iterators are not in=
herently safer than pointers. It all depends on how you use them.=C2=A0</di=
v><div dir=3D"auto">If you dereference an out-of-range pointer, you get UB.=
</div><div dir=3D"auto">If you dereference an out-of-range iterator, you ge=
t UB.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, the reason s=
td::array exists is not because language arrays are unsafe, it's becaus=
e they support more operations.</div><div dir=3D"auto"></div><div dir=3D"au=
to"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">The propo=
sed solution</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We should
qualify the two parts of the source code mentioned above. Also we need to
define, which coding techniques we consider unsafe, and suppose that the
compiler can recognize them.</span></p></div></blockquote></div></div><div =
dir=3D"auto">It's not that easy:</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">// Unsafe, iterator might be out-of-range</div><div dir=3D"aut=
o">template<typename It></div><div dir=3D"auto">void getNext(It itera=
tor) { ++iterator =3D {}; }</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">// 100% safe</div><div dir=3D"auto">template<typename T></div><di=
v dir=3D"auto">T get(T *Ptr) { return Ptr ? *Ptr : T(); }</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Would you say that the first is safe and =
the second unsafe?</div><div dir=3D"auto"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Proposed
qualifiers:</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><br></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">=E2=80=9Csafe=E2=80=9D:
qualifies functions, where unsafe coding techniques are not allowed by the
compiler.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">=E2=80=9Ctrusted=E2=80=9D:
qualifies functions, where unsafe coding techniques are allowed, but their
correctness is proven by the author.</span></p><p class=3D"MsoNormal"><span=
lang=3D"EN-US"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Unqualified
code: functions, where unsafe coding techniques are allowed, and their
correctness is unknown.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-U=
S"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We can
either add our qualifiers as new reserved words to the language, or we can =
use
other syntax such as attributes. At this level of this proposal, the syntax=
is
not decided.</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span></p><p class=3D"MsoN=
ormal"><span lang=3D"EN-US">We need to
allow these qualifiers on global and member functions, function pointers, a=
nd on
other language constructions related to function implementations and their
execution. Lambda functions may inherit the qualification of the function t=
hat they
are defined within.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><=
br></span></p>
<h1><span lang=3D"EN-US">Rules</span></h1><p></p>
<ul><li><span lang=3D"EN-US">Safe
functions shall not contain unsafe language constructions.</span></li></ul>=
</div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">But then a lot of types would be unsafe that you consider here to be safe=
.. Allocators would use pointers for example. How would that work?</div><div=
dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><ul><=
li><span lang=3D"EN-US">Trusted
and unqualified functions may contain unsafe language constructions.</span>=
</li><li><span lang=3D"EN-US">Safe and
trusted functions can call only safe and trusted functions.</span></li><li>=
<span lang=3D"EN-US">Unqualified
functions can call any functions.</span></li><li><span lang=3D"EN-US">Safe =
and
trusted function pointers shall be assigned from either safe or trusted fun=
ctions
or function pointers.</span></li><li><span lang=3D"EN-US">Unqualified
function pointers can be assigned from any functions or function pointers.<=
/span></li><li><span lang=3D"EN-US">Same
rules for initialization of references.</span></li></ul><h1><span lang=3D"E=
N-US">Usage</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Qualify all
the entry points of your application as safe. This results that the whole c=
all
tree of that application is enforced to consist of either safe or trusted f=
unctions.
Qualify as much of the source code as you can safe, and move the smallest u=
nsafe </span><span lang=3D"EN-US"></span></p><p class=3D"MsoNormal"><span l=
ang=3D"EN-US"><span style=3D"font-size:11.0pt;line-height:107%;font-family:=
"Calibri",sans-serif" lang=3D"EN-US">code
blocks </span> to trusted functions. Proof the correctness of these trusted
functions.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">Notes</sp=
an></h1><p></p>
<ul><li><span lang=3D"EN-US">The basic
idea behind the rules above is that safe and trusted functions are equally
safe. The difference between them is that the safety of =E2=80=9Csafe=E2=80=
=9D functions is provided
by the compiler, while the safety of =E2=80=9Ctrusted=E2=80=9D functions is=
provided by the author
of their source code.</span></li><li><span lang=3D"EN-US">Standard
and third party library functions are expected to be qualified. Legacy libr=
ary
functions known to be unsafe, such as strcpy, must be unqualified.</span></=
li><li><span lang=3D"EN-US">The
qualification of the main entry point function doesn't imply qualificat=
ion of
constructors and destructors of static objects. They need to be qualified
additionally.</span></li></ul><h1><span lang=3D"EN-US"></span></h1><h1><spa=
n lang=3D"EN-US">Useful tools</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">For quality
assurance of an application having large source code we need a tool for det=
ecting
changes on trusted source code, or addition of new trusted code. Quality
assurance of the changed and added source code need to be done or redone.</=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Digital
signatures on code blocks (possibly in comments) can be used to proof that =
trusted source code parts has
been quality assured by the author.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">Implement=
ation notes</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The
implementation of the new rules requires some changes in the linkage of
functions. This change may affect the whole toolchain creating and processi=
ng
object code.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><br></sp=
an></p>
<h1><span lang=3D"EN-US">Safe and unsafe coding
techniques</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">This
proposal at this level is not about defining, which C++ source code constru=
ctions
are unsafe. However, at first thoughts, just some unsafe examples: pointer
arithmetic, indexing of raw arrays, =E2=80=9CC=E2=80=9D style functions hav=
ing variable number
of arguments, but not including compile time verifiable formatted input/out=
put.
RAII for memory allocation can be enforced by considering =E2=80=9Cnew=E2=
=80=9D and =E2=80=9Cdelete=E2=80=9D
keywords unsafe.</span></p></div></blockquote></div></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">All of those aren't intently inherently un=
safe though. new/delete have their place and aren't unsafe, pointer ari=
thmetic is safe in certain.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">I don't think you can generalize and consider certain features as s=
afe or unsafe, because it depends on what you do with them.</div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">
</div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/245f1f1b-d168-4434-a605-f82bff4a99af%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/245f1f1b-d168-4434-a605-f82bff4a99af%40isocpp.org</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq0dMPLNhnLoG-z8traY-F%2B%3DFv51=
_4-7sE%3D5U%3D6p2DfVBA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0d=
MPLNhnLoG-z8traY-F%2B%3DFv51_4-7sE%3D5U%3D6p2DfVBA%40mail.gmail.com</a>.<br=
/>
--001a113cf3deb1e44805675417a1--
.
Author: Marius Bancila <marius.bancila@gmail.com>
Date: Wed, 14 Mar 2018 09:44:13 +0200
Raw View
--000000000000d5b43305675a8b1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I think you are missing a very important aspect: the definition of safe
(and unsafe). I don't think this is a common understanding, so before we
can think of what we can consider safe and unsafe you need to explain what
you understand by that.
On Wed, Mar 14, 2018 at 1:32 AM, Mikl=C3=B3s P=C3=A1l <palmiklos@gmail.com>=
wrote:
> Hi All,
>
>
> Im sharing my idea about making C++ language more suitable for safer
> coding. This is not a new attempt to create a new safe subset of the C++
> language. This is more an attempt to take the benefit of both safety
> enforcements and unrestricted coding.
>
>
> Thanks in advance for your comments.
>
> The problem
>
>
> Modern C++ standards introduce more and more safe constructions, which ca=
n
> replace unsafe coding techniques. However, C++ still allows these unsafe
> coding techniques for compatibility. Unsafe techniques in large source
> code, maintained by many people, makes software quality assurance
> difficult. The modern, so called =E2=80=9Cinherently safe=E2=80=9D langua=
ges can answer
> this problem somehow, but unlike C++, they can=E2=80=99t provide the dire=
ct control
> over the inherently unsafe hardware.
>
> Observation
>
>
> We can divide our source code into two parts:
>
>
> 1. Safe part, which can be constructed using only safe coding techniques.
> This is usually the largest part of the source code.
>
>
> 2. Unsafe part, in which we can=E2=80=99t avoid using unsafe techniques, =
but we
> can proof the safety of such solutions. These can be very small and
> isolated code parts. Usually these parts are the small building blocks of
> the safe part.
>
>
> Example:
>
>
> We can use a vector template class and its iterators safely throughout ou=
r
> source code, instead of using unsafe arrays and pointers. But we need an
> implementation for that vector class, which can only be built upon unsafe
> operations. The safety of the whole code, regarding to the usage of our
> vector class, is provided by the proof the correctness of that
> implementation.
>
> The proposed solution
>
>
> We should qualify the two parts of the source code mentioned above. Also
> we need to define, which coding techniques we consider unsafe, and suppos=
e
> that the compiler can recognize them.
>
> Proposed qualifiers:
>
>
> =E2=80=9Csafe=E2=80=9D: qualifies functions, where unsafe coding techniqu=
es are not
> allowed by the compiler.
>
>
> =E2=80=9Ctrusted=E2=80=9D: qualifies functions, where unsafe coding techn=
iques are
> allowed, but their correctness is proven by the author.
>
>
> Unqualified code: functions, where unsafe coding techniques are allowed,
> and their correctness is unknown.
>
>
> We can either add our qualifiers as new reserved words to the language, o=
r
> we can use other syntax such as attributes. At this level of this proposa=
l,
> the syntax is not decided.
>
>
> We need to allow these qualifiers on global and member functions, functio=
n
> pointers, and on other language constructions related to function
> implementations and their execution. Lambda functions may inherit the
> qualification of the function that they are defined within.
>
>
> Rules
>
>
> - Safe functions shall not contain unsafe language constructions.
> - Trusted and unqualified functions may contain unsafe language
> constructions.
> - Safe and trusted functions can call only safe and trusted functions.
> - Unqualified functions can call any functions.
> - Safe and trusted function pointers shall be assigned from either
> safe or trusted functions or function pointers.
> - Unqualified function pointers can be assigned from any functions or
> function pointers.
> - Same rules for initialization of references.
>
> Usage
>
>
> Qualify all the entry points of your application as safe. This results
> that the whole call tree of that application is enforced to consist of
> either safe or trusted functions. Qualify as much of the source code as y=
ou
> can safe, and move the smallest unsafe
>
> code blocks to trusted functions. Proof the correctness of these trusted
> functions.
>
> Notes
>
>
> - The basic idea behind the rules above is that safe and trusted
> functions are equally safe. The difference between them is that the sa=
fety
> of =E2=80=9Csafe=E2=80=9D functions is provided by the compiler, while=
the safety of
> =E2=80=9Ctrusted=E2=80=9D functions is provided by the author of their=
source code.
> - Standard and third party library functions are expected to be
> qualified. Legacy library functions known to be unsafe, such as strcpy=
,
> must be unqualified.
> - The qualification of the main entry point function doesn't imply
> qualification of constructors and destructors of static objects. They =
need
> to be qualified additionally.
>
> Useful tools
>
>
> For quality assurance of an application having large source code we need =
a
> tool for detecting changes on trusted source code, or addition of new
> trusted code. Quality assurance of the changed and added source code need
> to be done or redone.
>
> Digital signatures on code blocks (possibly in comments) can be used to
> proof that trusted source code parts has been quality assured by the auth=
or.
>
> Implementation notes
>
>
> The implementation of the new rules requires some changes in the linkage
> of functions. This change may affect the whole toolchain creating and
> processing object code.
>
>
> Safe and unsafe coding techniques
>
>
> This proposal at this level is not about defining, which C++ source code
> constructions are unsafe. However, at first thoughts, just some unsafe
> examples: pointer arithmetic, indexing of raw arrays, =E2=80=9CC=E2=80=9D=
style functions
> having variable number of arguments, but not including compile time
> verifiable formatted input/output. RAII for memory allocation can be
> enforced by considering =E2=80=9Cnew=E2=80=9D and =E2=80=9Cdelete=E2=80=
=9D keywords unsafe.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/245f1f1b-d168-4434-
> a605-f82bff4a99af%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/245f1f1b-d1=
68-4434-a605-f82bff4a99af%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BgtASzd-mQUT%2BThss328o7QCXAhJ5eENrhN9TnLvWT=
BJU_KfA%40mail.gmail.com.
--000000000000d5b43305675a8b1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think you are missing a very important aspect: the defin=
ition of safe (and unsafe). I don't think this is a common understandin=
g, so before we can think of what we can consider safe and unsafe you need =
to explain what you understand by that.</div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Wed, Mar 14, 2018 at 1:32 AM, Mikl=C3=B3s P=
=C3=A1l <span dir=3D"ltr"><<a href=3D"mailto:palmiklos@gmail.com" target=
=3D"_blank">palmiklos@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">
<h1>Hi All,</h1><p><br></p><p>Im sharing my idea about making C++ language =
more suitable for safer coding. This is not a new attempt to create a new s=
afe subset of the C++ language. This is more an attempt to take the benefit=
of both safety enforcements and unrestricted coding.</p><p><br></p><p><spa=
n id=3D"m_-6669556407961451545result_box" class=3D"m_-6669556407961451545sh=
ort_text" lang=3D"en"><span>Thanks in advance for your comments.</span></sp=
an></p><h1><br></h1><h1><span lang=3D"EN-US">The problem</span></h1><p><br>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Modern C++ standards
introduce more and more safe constructions, which can replace unsafe coding
techniques. However, C++ still allows these unsafe coding techniques for
compatibility. Unsafe techniques in large source code, maintained by many
people, makes software quality assurance difficult. The modern, so called
=E2=80=9Cinherently safe=E2=80=9D languages can answer this problem somehow=
, but unlike C++, they
can=E2=80=99t provide the direct control over the inherently unsafe hardwar=
e.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">Observati=
on</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We can
divide our source code into two parts:</span></p><p class=3D"MsoNormal"><sp=
an lang=3D"EN-US"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">1. Safe
part, which can be constructed using only safe coding techniques. This is
usually the largest part of the source code.</span></p><p class=3D"MsoNorma=
l"><span lang=3D"EN-US"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">2. Unsafe
part, in which we can=E2=80=99t avoid using unsafe techniques, but we can p=
roof the
safety of such solutions.</span><span lang=3D"EN-US"> </span><span lang=3D"=
EN-US">These can be very small and isolated code
parts. Usually these parts are the small building blocks of the safe part.<=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span></p><p class=3D"MsoN=
ormal"><span lang=3D"EN-US">Example:</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span></p><p class=3D"MsoN=
ormal"><span lang=3D"EN-US">We can use
a vector template class and its iterators safely throughout our source code=
,
instead of using unsafe arrays and pointers. But we need an implementation =
for
that vector class, which can only be built upon unsafe operations. The safe=
ty
of the whole code, regarding to the usage of our vector class, is provided =
by
the proof the correctness of that implementation.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">The propo=
sed solution</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We should
qualify the two parts of the source code mentioned above. Also we need to
define, which coding techniques we consider unsafe, and suppose that the
compiler can recognize them.</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Proposed
qualifiers:</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><br></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">=E2=80=9Csafe=E2=80=9D:
qualifies functions, where unsafe coding techniques are not allowed by the
compiler.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">=E2=80=9Ctrusted=E2=80=9D:
qualifies functions, where unsafe coding techniques are allowed, but their
correctness is proven by the author.</span></p><p class=3D"MsoNormal"><span=
lang=3D"EN-US"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Unqualified
code: functions, where unsafe coding techniques are allowed, and their
correctness is unknown.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-U=
S"><br></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We can
either add our qualifiers as new reserved words to the language, or we can =
use
other syntax such as attributes. At this level of this proposal, the syntax=
is
not decided.</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br></span></p><p class=3D"MsoN=
ormal"><span lang=3D"EN-US">We need to
allow these qualifiers on global and member functions, function pointers, a=
nd on
other language constructions related to function implementations and their
execution. Lambda functions may inherit the qualification of the function t=
hat they
are defined within.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><=
br></span></p>
<h1><span lang=3D"EN-US">Rules</span></h1><p></p>
<ul><li><span lang=3D"EN-US">Safe
functions shall not contain unsafe language constructions.</span></li><li><=
span lang=3D"EN-US">Trusted
and unqualified functions may contain unsafe language constructions.</span>=
</li><li><span lang=3D"EN-US">Safe and
trusted functions can call only safe and trusted functions.</span></li><li>=
<span lang=3D"EN-US">Unqualified
functions can call any functions.</span></li><li><span lang=3D"EN-US">Safe =
and
trusted function pointers shall be assigned from either safe or trusted fun=
ctions
or function pointers.</span></li><li><span lang=3D"EN-US">Unqualified
function pointers can be assigned from any functions or function pointers.<=
/span></li><li><span lang=3D"EN-US">Same
rules for initialization of references.</span></li></ul><h1><span lang=3D"E=
N-US">Usage</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Qualify all
the entry points of your application as safe. This results that the whole c=
all
tree of that application is enforced to consist of either safe or trusted f=
unctions.
Qualify as much of the source code as you can safe, and move the smallest u=
nsafe </span><span lang=3D"EN-US"></span></p><p class=3D"MsoNormal"><span l=
ang=3D"EN-US"><span style=3D"font-size:11.0pt;line-height:107%;font-family:=
"Calibri",sans-serif" lang=3D"EN-US">code
blocks </span> to trusted functions. Proof the correctness of these trusted
functions.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">Notes</sp=
an></h1><p></p>
<ul><li><span lang=3D"EN-US">The basic
idea behind the rules above is that safe and trusted functions are equally
safe. The difference between them is that the safety of =E2=80=9Csafe=E2=80=
=9D functions is provided
by the compiler, while the safety of =E2=80=9Ctrusted=E2=80=9D functions is=
provided by the author
of their source code.</span></li><li><span lang=3D"EN-US">Standard
and third party library functions are expected to be qualified. Legacy libr=
ary
functions known to be unsafe, such as strcpy, must be unqualified.</span></=
li><li><span lang=3D"EN-US">The
qualification of the main entry point function doesn't imply qualificat=
ion of
constructors and destructors of static objects. They need to be qualified
additionally.</span></li></ul><h1><span lang=3D"EN-US"></span></h1><h1><spa=
n lang=3D"EN-US">Useful tools</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">For quality
assurance of an application having large source code we need a tool for det=
ecting
changes on trusted source code, or addition of new trusted code. Quality
assurance of the changed and added source code need to be done or redone.</=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Digital
signatures on code blocks (possibly in comments) can be used to proof that =
trusted source code parts has
been quality assured by the author.</span></p>
<h1><br><span lang=3D"EN-US"></span></h1><h1><span lang=3D"EN-US">Implement=
ation notes</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The
implementation of the new rules requires some changes in the linkage of
functions. This change may affect the whole toolchain creating and processi=
ng
object code.</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><br></sp=
an></p>
<h1><span lang=3D"EN-US">Safe and unsafe coding
techniques</span></h1><p><br></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">This
proposal at this level is not about defining, which C++ source code constru=
ctions
are unsafe. However, at first thoughts, just some unsafe examples: pointer
arithmetic, indexing of raw arrays, =E2=80=9CC=E2=80=9D style functions hav=
ing variable number
of arguments, but not including compile time verifiable formatted input/out=
put.
RAII for memory allocation can be enforced by considering =E2=80=9Cnew=E2=
=80=9D and =E2=80=9Cdelete=E2=80=9D
keywords unsafe.</span></p><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/245f1f1b-d168-4434-a605-f82bff4a99af%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/245f=
1f1b-d168-4434-<wbr>a605-f82bff4a99af%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzd-mQUT%2BThss328o7QCXAhJ5eE=
NrhN9TnLvWTBJU_KfA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzd-m=
QUT%2BThss328o7QCXAhJ5eENrhN9TnLvWTBJU_KfA%40mail.gmail.com</a>.<br />
--000000000000d5b43305675a8b1b--
.
Author: =?UTF-8?B?TWlrbMOzcyBQw6Fs?= <palmiklos@gmail.com>
Date: Thu, 15 Mar 2018 01:38:32 +0100
Raw View
--001a113de04821ff74056768b611
Content-Type: text/plain; charset="UTF-8"
Hi, thank you all for your comments.
I understand, that defining what is safe and what is unsafe is essential,
but almost (?) impossible. Suppose that we make a software for a self
driving car using only safe code, but how safe the car will be in real
traffic? ;)
In my point of view, code safety is related to how quickly we can recognize
our mistakes in our code. 1: The best if we can find them in compile time.
2: Worse, but still acceptable if we can detect our mistakes run-time in a
debug build. Depends on test coverage. 3: The worst, when we are unable to
recognize our bugs for a long time, because the code appears to be working
fine.
Static analysers provide us a great job, they can recognize many bugs from
the second and third category without running the program.
Example: Pointer overrun in writing may not be recognized at all, if we
actually don't use the overwritten variable in our test cases. But if we
use iterators and test a debug build, we have a good chance to find the bug
easily. But if we overwrite an item within a collection by mistake, the bug
will not be recognized, even if we use iterators in debug mode. Good news,
coding will require intelligence later on too. ;)
I consider coding techniques unsafe, that:
1. In practice, frequently result errors belonging to the third category,
see above.
2. Standard provides safer alternate coding techniques, which make
detection of such errors possible in a debug build, while can provide high
performance in a release build.
I clearly see and agree that none of the safety enforcements can provide us
that the code will be absolutely safe.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHP9XZFoVV3V%3DQ0HgNFijY3RH7Cqv4LiGBt_myw30AJCXR_sUg%40mail.gmail.com.
--001a113de04821ff74056768b611
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>Hi, thank you all for your commen=
ts.<br></div><div><br>I understand, that defining what is safe and what is=
=20
unsafe is essential, but almost (?) impossible. Suppose that we make a soft=
ware for a self driving car using only safe code, but how safe the car will=
be in real traffic? ;)<br><br></div>In my point of view, code safety is re=
lated to how quickly we can recognize our mistakes in our code. 1: The best=
if we can find them in compile time. 2: Worse, but still acceptable if we =
can detect our mistakes run-time in a debug build. Depends on test coverage=
.. 3: The worst, when we are unable to recognize our bugs for a long time, b=
ecause the code appears to be working fine.<br><br>Static analysers provide=
us a great job, they can recognize many bugs from the second and third cat=
egory without running the program.<br><br></div>Example: Pointer overrun in=
writing may not be recognized at all, if we actually don't use the ove=
rwritten variable in our test cases. But if we use iterators and test a deb=
ug build, we have a good chance to find the bug easily. But if we overwrite=
an item within a collection by mistake, the bug will not be recognized, ev=
en if we use iterators in debug mode. Good news, coding will require intell=
igence later on too. ;)<br><br></div>I consider coding techniques unsafe, t=
hat:<br>1. In practice, frequently result errors belonging to the third cat=
egory, see above.<br></div>2. Standard provides safer alternate coding tech=
niques, which make detection of such errors possible in a debug build, whil=
e can provide high performance in a release build.<br><br></div>I clearly s=
ee and agree that none of the safety enforcements can provide us that the c=
ode will be absolutely safe.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHP9XZFoVV3V%3DQ0HgNFijY3RH7Cqv4LiGB=
t_myw30AJCXR_sUg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHP9XZFoVV3V%3=
DQ0HgNFijY3RH7Cqv4LiGBt_myw30AJCXR_sUg%40mail.gmail.com</a>.<br />
--001a113de04821ff74056768b611--
.