Sunday, April 19, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 2 topics

jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 02:17PM +0200

The new language "rust" promised memory safety and efficiency, making
for a great promise... that they can't keep.
 
A recent paper shows that Rust has the same problems as C or C++.
 
https://arxiv.org/pdf/2003.03296.pdf
 
jacob
Paavo Helde <eesnimi@osa.pri.ee>: Apr 19 03:39PM +0300

19.04.2020 15:17 jacobnavia kirjutas:
> for a great promise... that they can't keep.
 
> A recent paper shows that Rust has the same problems as C or C++.
 
> https://arxiv.org/pdf/2003.03296.pdf
 
This paper compares Rust with an hypothetical language called C/C++.
There is no such language in existence, which makes the whole paper a
bit suspect.
"Öö Tiib" <ootiib@hot.ee>: Apr 19 05:42AM -0700

On Sunday, 19 April 2020 15:17:51 UTC+3, jacobnavia wrote:
> for a great promise... that they can't keep.
 
> A recent paper shows that Rust has the same problems as C or C++.
 
> https://arxiv.org/pdf/2003.03296.pdf
 
I am maybe misunderstanding what I read again but huh.
Is it really article that states that stuff in Rust encapsulated in
unsafe{ ... } is unsafe? Is it really meant to distribute FUD
against Rust? Appearance of such clearly mud slinging articles
has always indicated that target is doing far stronger than I
thought and it is time to invest into it!
jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 03:21PM +0200

Le 19/04/2020 à 14:42, Öö Tiib a écrit :
 
>> A recent paper shows that Rust has the same problems as C or C++.
 
>> https://arxiv.org/pdf/2003.03296.pdf
 
> I am maybe misunderstanding what I read again but huh.
 
No, it is simply that your evangelical positions are getting upset.
 
> Is it really article that states that stuff in Rust encapsulated in
> unsafe{ ... } is unsafe?
 
Exactly. But why are those unsafe APIs necessary?
 
Because they are essential. And that means that Rust has the same
problems than C with usage after free() etc.
 
Is it really meant to distribute FUD
> against Rust?
 
No, it is an investigation of Rust's claims and its FUD about C.
 
 
> Appearance of such clearly mud slinging articles
> has always indicated that target is doing far stronger than I
> thought and it is time to invest into it!
 
Evangelist position noted...
jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 03:24PM +0200

Le 19/04/2020 à 14:39, Paavo Helde a écrit :
 
> This paper compares Rust with an hypothetical language called C/C++.
> There is no such language in existence, which makes the whole paper a
> bit suspect.
 
I have often seen he/she for instance. And I never supposed that a
"heshe" sex exists. The "/" is used as "either of" as you obviously know.
 
Unable to say anything of value, you just utter nonsense.
gazelle@shell.xmission.com (Kenny McCormack): Apr 19 01:28PM

In article <r7hgqu$e23$1@dont-email.me>,
 
>This paper compares Rust with an hypothetical language called C/C++.
>There is no such language in existence, which makes the whole paper a
>bit suspect.
 
Very funny! Ha Ha Ha!!!
 
Everybody knows what is meant by the term C/C++.
 
Yes, even you.
 
 
--
There are a lot of Wisconsin farmers right now who, despite having
themselves voted for Trump, are now wishing that their state's electors
had had the good sense to vote for the other candidate - thereby saving
them from their current predicament.
Richard Damon <Richard@Damon-Family.org>: Apr 19 09:31AM -0400

On 4/19/20 8:39 AM, Paavo Helde wrote:
 
> This paper compares Rust with an hypothetical language called C/C++.
> There is no such language in existence, which makes the whole paper a
> bit suspect.
 
But C and C++ are very related languages, so there IS a language family
that can be described as C/C++, and there is a common core that is
common between the two languages. C++ adds a number of features, that
when used can abstract out may of the things that cause one class of
memory errors, but at the same time adds a layer of complexity that
might enable others.
 
C++ also doesn't force you to use the abstractions that help eliminate
some of the memory problems, but allows you to do the low level
operations that open the door to memory access issues, and in fact the
abstractions tend to be based on using those lower level operations, its
just that the scope of those operations are tried to be kept smaller so
it is hopefully easier to reason that it is being done correctly.
Bart <bc@freeuk.com>: Apr 19 03:21PM +0100

On 19/04/2020 13:39, Paavo Helde wrote:
 
> This paper compares Rust with an hypothetical language called C/C++.
> There is no such language in existence, which makes the whole paper a
> bit suspect.
 
That hypothethical language to be supported by MS:
 
https://code.visualstudio.com/docs/languages/cpp
 
You might want to read here too:
 
https://simpleprogrammer.com/what-does-cc-mean/
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 19 03:55PM +0100

> for a great promise... that they can't keep.
 
> A recent paper shows that Rust has the same problems as C or C++.
 
> https://arxiv.org/pdf/2003.03296.pdf
 
The first line of the summary:
 
"Most memory-safety bugs are related to unsafe APIs or foreign
function interfaces (FFIs)."
 
An "unsafe API" is a technical term in this paper. It does not mean
buggy Rust, it means calling a library that can't provide Rust's memory
guarantees.
 
--
Ben.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 03:01PM


> A recent paper shows that Rust has the same problems as C or C++.
 
> https://arxiv.org/pdf/2003.03296.pdf
 
> jacob
 
Here is my spare time project in Rust about covid19:
https://github.com/bmaxa/covid19report
here is implementation of some binary trees:
https://github.com/bmaxa/trees_rust
I can tell you if rust closed possibility
for low level programming it would be useless.
They removed pointer arithmetic, and you have
to cast pointer to integer add then cast back.
Also you can implement it in library easilly :)
 
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Paavo Helde <eesnimi@osa.pri.ee>: Apr 19 06:04PM +0300

19.04.2020 16:24 jacobnavia kirjutas:
>> bit suspect.
 
> I have often seen he/she for instance. And I never supposed that a
> "heshe" sex exists. The "/" is used as "either of" as you obviously know.
 
"He/she" is used if there is no difference if there is a "he" or a "she".
 
Here, regarding the topic of the paper (memory management) using slash
would only have some merit if both sides of "either or" are at least
somewhat similar. In reality, this is one of the areas where C and C++
differ the most, memory allocation in C++ does not resemble or behave
anything like in C. To compare them to something without making
distinction just shows full ignorance.
Siri Cruise <chine.bleu@yahoo.com>: Apr 19 08:30AM -0700

In article <G7ZmG.124954$8W7.6293@fx13.am4>,
 
> https://simpleprogrammer.com/what-does-cc-mean/
 
It's how spanish sailors answer orders.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 19 12:14PM -0400

On 4/19/20 8:39 AM, Paavo Helde wrote:
 
> This paper compares Rust with an hypothetical language called C/C++.
> There is no such language in existence, which makes the whole paper a
> bit suspect.
 
The term "C/C++" can be used correctly to refer to both C and C++ in a
single statement. In particular, it can be correctly used to refer to
things that are true in the common subset of C and C++. C and C++ are
sufficiently closely related that their common subset is very nearly
(but not quite) the same as C. That paper uses the term a grand total of
three times:
 
"To elaborate, the culprits of buffer overflow bugs in Rust are very
similar to those in C/C++, which generally involve both logical errors
and arbitrary pointer operations that are allowed only by unsafe Rust."
While C++ provide tools that can be used to make it slightly easier to
avoid buffer overflows than C, it continues to support every feature of
C that makes it vulnerable to buffer overflows.
 
"Like C/C++, using unsafe APIs has no memory-safety promise, making Rust
programs vulnerable to memory-safety bugs." Is he wrong about that? Does
either language provide that kind of promise? If so, what precisely is
the wording of the promise.
 
"Since Rust has no magic in preventing logical errors, such as boundary
checking, using unsafe APIs is as vulnerable as C/C++ in buffer
overflow." While C++ has many features that make is less susceptible to
such problems than C is, but C++ still supports every feature of C that
that comment refers to.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 04:17PM

> overflow." While C++ has many features that make is less susceptible to
> such problems than C is, but C++ still supports every feature of C that
> that comment refers to.
 
Rust is ok regarding programming errors. Compiler is very picky and
descriptive. If you don't use * I don't know how you can get
buffer overruns in Rust.
Rust eg is compiler error if you use object that is being moved
and destructors are not called for moved objects...
 
 
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Richard Damon <Richard@Damon-Family.org>: Apr 19 01:59PM -0400

On 4/19/20 11:04 AM, Paavo Helde wrote:
> differ the most, memory allocation in C++ does not resemble or behave
> anything like in C. To compare them to something without making
> distinction just shows full ignorance.
 
Actually, at the fundamental level they do use very similar methods.
Most C++ implementations map new()/new[]() to malloc() (and delete to
free). The big difference is that much C++ code pushes those operations
to basic classes (smart pointers and collections) which C doesn't. Yes,
many of the flaws they talk about are hard to do in C++ than in C *IF*
you are using the higher level abstractions (correctly). C++ first does
not require you to use them, and there is still plenty of C++ code using
somewhat naked pointers with all those issues, and a lot of people will
also use some of those feature, but use them wrong and the just think
they are safe from the problems.
Paavo Helde <eesnimi@osa.pri.ee>: Apr 19 09:29PM +0300

19.04.2020 19:14 James Kuyper kirjutas:
> sufficiently closely related that their common subset is very nearly
> (but not quite) the same as C. That paper uses the term a grand total of
> three times:
 
Regarding memory allocation the common subset of C and C++ is almost
empty. Of course, C++ (almost) supports the C-style memory allocation
code, but it's still C code, not C++, because no sane C++ programmer
will allocate memory this way.
 
> While C++ provide tools that can be used to make it slightly easier to
> avoid buffer overflows than C, it continues to support every feature of
> C that makes it vulnerable to buffer overflows.
 
Yes, C++ supports unsafe code, this is a major selling point because of
C back-compatibility. But apparently, so does Rust. Using unsafe code or
unsafe API-s in any language (which supports this) is unsafe, so why
select two such languages and then pretend they are a single language?
 
The main reasons of buffer overflow bugs in C are:
 
- allocating a too short local buffer because dynamic allocation is
such a hassle.
- allocating a "big enough" dynamic buffer in advance because
resizing a buffer is such a hassle, and getting the needed size wrong.
- losing the actual size of the buffer because it was calculated from
another variable at the point of allocation, or the variable holding the
size gets mixed up or modified while passed to the usage point.
 
None of the above applies to C++ where allocating, resizing and
retrieving the size of a std::vector is trivial.
 
> programs vulnerable to memory-safety bugs." Is he wrong about that? Does
> either language provide that kind of promise? If so, what precisely is
> the wording of the promise.
 
I do not argue that C or C++ cannot be used in unsafe ways. I argue that
in the regard of memory safety topics they are two totally different
languages and should not be referred to as a single language.
 
 
> overflow." While C++ has many features that make is less susceptible to
> such problems than C is, but C++ still supports every feature of C that
> that comment refers to.
 
Yes, C++ supports writing unsafe C code. Howevere, C++ also supports
much safer ways to write code which are routinely used by any
half-decent C++ programmer, so in regard to the memory safety issues
these languages are very different and should not be referred to as a
single language.
 
An especially valid point about C++ is that using the safer approaches
like std::vector does not decrease the performance of the application,
contrary to Rust if I have understood correctly.
Daniel P <danielaparker@gmail.com>: Apr 19 12:27PM -0700

On Sunday, April 19, 2020 at 2:29:49 PM UTC-4, Paavo Helde wrote:
> size gets mixed up or modified while passed to the usage point.
 
> None of the above applies to C++ where allocating, resizing and
> retrieving the size of a std::vector is trivial.
 
But algorithms that write to output iterators can override the bounds of your
container, unless using "checked iterators" or back insert iterators.
 
Daniel
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 19 07:37PM

On Sun, 2020-04-19, Daniel P wrote:
>> retrieving the size of a std::vector is trivial.
 
> But algorithms that write to output iterators can override the bounds of your
> container, unless using "checked iterators" or back insert iterators.
 
Or you can accidentally use an invalidated iterator, and so on.
 
Maybe the main benefit of C++ in this area is that you're not tempted
to use fixed-size buffers for things with no fixed max size.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:04PM +0100

On Sun, 19 Apr 2020 21:29:36 +0300
 
> An especially valid point about C++ is that using the safer approaches
> like std::vector does not decrease the performance of the application,
> contrary to Rust if I have understood correctly.
 
But going back to your "this paper compares Rust with an hypothetical
language called C/C++. There is no such language in existence, which
makes the whole paper a bit suspect", what I think is more suspect is
(i) jacobnavia's opening conclusion, expressed in the heading to these
posts, that "Rust has the same memory problem as C and C++", and (ii)
the referenced paper's implicit "No" conclusion to the self-posed
question "Memory-Safety Challenge Considered Solved?"
 
Both propositions are hyperbolic. If you use the unsafe subset of Rust,
which you have to label explicitly as unsafe in your code, then
(surprise, surprise) it is unsafe. However if you do not explicitly do
so, then unsafe memory usage shouldn't compile.
 
Yes, C++ when used correctly is indeed more safe than C. However memory
safety is not enforced through its type system: it instead forms a
usage pattern. In Rust memory safety is enforced: that is what Rust's
affine/linear type system is supposed to be all about (together with
thread safety). That I think is a significant advance. Whether it is
sufficient of an advance in practice to make Rust a genuine competitor
to C++ in the future is something that time will tell.
 
The paper concluded that "Most of these bugs are related to unsafe APIs
or FFIs. It means that Rust is very effective in preventing
memory-safety bugs if using safe Rust only. On the other hand, using
unsafe Rust is as risky asother programming languages that mainly
relies on the developerto prevent memory-safety issues."
 
This is not a revelation of a great new truth. The Rust community would
say exactly the same, and do in their documentation. They would
however be concerned by the "Most of". If memory safety bugs exist in
safe Rust code, then there is a bug in Rust which they would want to
solve.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 08:16PM

> thread safety). That I think is a significant advance. Whether it is
> sufficient of an advance in practice to make Rust a genuine competitor
> to C++ in the future is something that time will tell.
 
I think that Rust is fine replacement for C++, only thing is that
it is not used much yet. But, C++ is industrial language and
has many implementations and tool support. It is long way before
it can be usefull as C++ in industry.
 
> however be concerned by the "Most of". If memory safety bugs exist in
> safe Rust code, then there is a bug in Rust which they would want to
> solve.
 
Memory safety is not problem in Rust, problem is that it has no
pointer arithmetic, no tail call recursion optimisation and
no way to disable bounds checking ;)
Check this out:
scimark2 gcc:
/.../forth/sci >>> ./scimarkgcc
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 2626.67
FFT Mflops: 2079.86 (N=1024)
SOR Mflops: 2039.68 (100 x 100)
MonteCarlo: Mflops: 514.70
Sparse matmult Mflops: 3005.40 (N=1000, nz=5000)
LU Mflops: 5493.73 (M=100, N=100)
 
now Rust:
~/.../rust/scimark2 >>> ./target/release/scimark2 ±[●][master]
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kernel
Composite Score: 1962.53
FFT Mflops: 1744.24 (N=1024)
SOR Mflops: 1284.64 (100 x 100)
MonteCarlo Mflops: 1431.66
Sparse matmult Mflops: 2621.44 (N=1000, nz=5000)
LU Nflops: 2730.67 (M=100, N=100)
 
This is of course mine interpretation, but if anyone can
do better?
just see this:
impl<T> Slice<T> {
fn new(t:&mut [T])->Self {
Slice{ptr:t.as_mut_ptr(),size:t.len()}
}
}
 
impl<T> IndexMut<usize> for Slice<T> {
fn index_mut(&mut self,i:usize)->&mut T{
// assert!(i<self.size);
unsafe {&mut *((self.ptr as usize + i*mem::size_of::<T>()) as *mut T)}
}
}
 
 
impl<T> Index<usize> for Slice<T> {
type Output = T;
fn index(&self,i:usize)->&T{
// assert!(i<self.size);
unsafe {&*((self.ptr as usize + i*mem::size_of::<T>()) as *const T)}
 
here is whole proggy:
https://github.com/bmaxa/scimark2rust
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:35PM +0100

On Sun, 19 Apr 2020 20:16:41 GMT
> Memory safety is not problem in Rust, problem is that it has no
> pointer arithmetic, no tail call recursion optimisation and
> no way to disable bounds checking ;)
 
It will never be able to implement tail call elimination effectively,
because it uses the same memory management techniques in its type
system as well written C++ code does by good practice, namely
destructors. Destructors are not in tail position.
 
In consequence, tou need garbage collection for effective iterative
recursion. That, I imagine, is why Rust describes itself as an
"expression language" rather than a functional language (it clearly is
very heavily influenced by ML in other respects).
 
A safe language shouldn't try to eliminate bounds checking or permit
pointer arithmetic either. If you want to do that, confess it openly,
label your code explicitly unsafe and take everything that is coming to
you if you get it wrong.
 
> Check this out:
[snip]
> This is of course mine interpretation, but if anyone can
> do better?
> just see this:
[snip]
 
I don't write Rust code. I am merely interested in its type system (as
are a number of other languages, now).
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:39PM +0100

On Sun, 19 Apr 2020 21:35:15 +0100
> Destructors are not in tail position.
 
Err, only the last destructor is in tail position and the recursive call
is not.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 08:40PM

> [snip]
 
> I don't write Rust code. I am merely interested in its type system (as
> are a number of other languages, now).
 
Heh in 2013 or so I submitted patch in Rust compiler to fix inheritance in Vtable
bug :P
 
 
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 19 04:53PM -0400

On 4/19/20 2:29 PM, Paavo Helde wrote:
>> three times:
 
> Regarding memory allocation the common subset of C and C++ is almost
> empty.
 
In C, memory can be allocated three ways, statically, automatically, and
dynamically. C provides four functions for dynamic memory allocation
malloc(), free(), realloc(), calloc(). Every memory allocation feature
of C is also a feature of C++, so the common subset is the same as the
entirety of C's memory allocation features. While that set is small, I
can't see any justification for calling that set almost empty. If it is
almost empty, then C's features for memory allocation are almost empty.
Would you be willing to accept that assertion?
 
...
>> C that makes it vulnerable to buffer overflows.
 
> Yes, C++ supports unsafe code, this is a major selling point because of
> C back-compatibility.
 
I was addressing only the reasonableness of using "C/C++" when writing a
document comparing those languages with Rust. I know nothing about Rust,
and have no interest in it, and in particular, no interest in discussing
how it compares with C/C++.
 
>> either language provide that kind of promise? If so, what precisely is
>> the wording of the promise.
 
> I do not argue that C or C++ cannot be used in unsafe ways.
 
That's not what he's saying - he's saying that C and C++ can both be
used in the same unsafe ways. That's certainly true, since you can write
well-formed C++ code that looks and behaves essentially the same as the
unsafe C code.
 
...
> Yes, C++ supports writing unsafe C code.
 
And that fact is sufficient to justify referring to defects of C/C++,
because both languages share those defects though their shared common
heritage.
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 19 12:22PM -0400

On 4/18/20 4:53 PM, Vir Campestris wrote:
>> and know how to deal with it.
 
> Interesting. I think I count myself as experienced - I've been writing C
> and C++ for nearly 40 years - and yet it's never bitten me.
 
I didn't say it was a big problem, either.
 
> auto minus = -plus;
> results in a 32 bit (or more!) size for minus is to me just another
> reason not to use auto where I can avoid it.
 
Well, the key reason why the integer promotions are generally not a
serious problems is that they are always value-preserving (unlike the
usual arithmetic conversions, where a negative value can sometimes end
up being converted to an unsigned type). That's what makes those
optimizations legal.
 
Still, there is one situation where the integral promotions can be
problematic. Expressions of unsigned type whose valid values are all
representable as 'int' will get promoted to a int. In itself that's not
a problem, but it can result in unexpected use of signed arithmetic on
values that started out as unsigned. That's why I so surprised to see
someone complain about the integral promotion of int16_t to int; I'd be
much less surprised to see a complaint about uint16_t being promoted to int.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: