Rust has the same memory problem as C and C++

[jacobnavia]

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]

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]

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]

Le 19/04/2020 à 14:42, Öö Tiib a écrit :
> On Sunday, 19 April 2020 15:17:51 UTC+3, jacobnavia wrote:
>> 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
>
> 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]

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.

[Kenny McCormack]

In article <r7hgqu$e23$1...@dont-email.me>,

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]

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]

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]

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]

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]

"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]

In article <G7ZmG.124954$8W7....@fx13.am4>,
Bart <b...@freeuk.com> wrote:

> 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]

On 4/19/20 8:39 AM, Paavo Helde wrote:

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]

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...

[Richard Damon]

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]

19.04.2020 19:14 James Kuyper kirjutas:
> On 4/19/20 8:39 AM, Paavo Helde wrote:
>> 19.04.2020 15:17 jacobnavia kirjutas:
>>> 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
>>
>> 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:

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.

> "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.

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.

>
> "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.

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.

> "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.

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]

On Sunday, April 19, 2020 at 2:29:49 PM UTC-4, Paavo Helde wrote:
>
> 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.
>

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]

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]

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]

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.

>
> 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.

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 po...@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 po...@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

[Chris Vine]

On Sun, 19 Apr 2020 20:16:41 GMT
Melzzzzz <Melz...@zzzzz.com> wrote:
> 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]

On Sun, 19 Apr 2020 21:35:15 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> Destructors are not in tail position.

Err, only the last destructor is in tail position and the recursive call
is not.

[Melzzzzz]

On 2020-04-19, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:

Heh in 2013 or so I submitted patch in Rust compiler to fix inheritance in Vtable
bug :P

[James Kuyper]

On 4/19/20 2:29 PM, Paavo Helde wrote:
> 19.04.2020 19:14 James Kuyper kirjutas:
>> On 4/19/20 8:39 AM, Paavo Helde wrote:
>>> 19.04.2020 15:17 jacobnavia kirjutas:
>>>> 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
>>>
>>> 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:
>
> 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?

...

>> "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.
>
> 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++.

>> "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.
>
> 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.

[Melzzzzz]

On 2020-04-19, James Kuyper <james...@alumni.caltech.edu> wrote:

There is no choice. If language requires portion of code to be written
in assembler that's not business. That is why ADA never took of ;)

[Richard Tobin]

In article <chine.bleu-C2A2E...@reader.eternal-september.org>,

Siri Cruise <chine...@yahoo.com> wrote:

>> https://simpleprogrammer.com/what-does-cc-mean/

>It's how spanish sailors answer orders.

The motto of the French navy: a l'eau, c'est l'heure.

-- Richard

[jacobnavia]

Le 19/04/2020 à 21:37, Jorgen Grahn a écrit :

> 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
>

If you use the C containers library you do not have to either. I wrote
that library and presented it to the C committee. They told me that C++
does that already. So, C was denied that path.

[Bonita Montero]

Don't discuss with idiots.

[Öö Tiib]

On Sunday, 19 April 2020 16:21:47 UTC+3, jacobnavia wrote:
> Le 19/04/2020 à 14:42, Öö Tiib a écrit :
> > On Sunday, 19 April 2020 15:17:51 UTC+3, jacobnavia wrote:
> >> 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
> >
> > I am maybe misunderstanding what I read again but huh.
>
> No, it is simply that your evangelical positions are getting upset.

What is my evangelical position?

>
> > Is it really article that states that stuff in Rust encapsulated in
> > unsafe{ ... } is unsafe?
>
> Exactly. But why are those unsafe APIs necessary?

World is full of unsafe APIs. Without ways to access operating systems
or other modules in your computer a programming language is just a toy in
its own sandbox and not a tool. That is obvious but somehow some morons
want to leave impression that Rust claims differently.

> Because they are essential. And that means that Rust has the same
> problems than C with usage after free() etc.

It has, nowhere is said that Rust by some wonder fixes MS Windows API
somehow. Just part of your own code can be safe. Claiming differently
is straw man building.

> Is it really meant to distribute FUD
> > against Rust?
>
> No, it is an investigation of Rust's claims and its FUD about C.

These were straw-man claims attributed to Rust and now it is fight
with those self built straw-men. Rust hasn't claimed that
calls marked unsafe are safe. What is Rust's 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...

How am I evangelical about Rust? I have barely had time to try it few
times for nothing serious. My impression of it is that it is immature
tool but interesting. Your article was crap, live with it. It is
surprising for me that Rust already deserves such low attacks.

[jacobnavia]

Le 20/04/2020 à 11:23, Öö Tiib a écrit :
> Your article was crap, live with it. It is
> surprising for me that Rust already deserves such low attacks.
>

Have you even read that article?
No.

It is "crap". That is enough to discard it... how easy!

I cite the paper:
<quote1>
This paper studies the question by surveying the bug reports collected
from two public datasets, Advisory- db and Trophy-cases, which contain
all existing CVEs (common vulnerability and exposures) of Rust. We
manually analyze each bug and extract their memory-safety issues and
culprits. Our results show that buffer overflow and dangling pointers
are still the major memory-safety issues in Rust, and most culprits are
related to unsafe Rust. Such security issues reveal that the security
cost of Rust to support unsafe functions is high.

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.

However, the culprits of dangling pointers in Rust have unique patterns,
especially those related to the vulnerability of Rust’s borrow checker
and lifetime checker. Based on these findings, we further suggest two
directions to improve the resilience of Rust against dangling pointers,
including recommending the best practice of some APIs to program
developers, as well as approaches to enhancing the borrow checker and
lifetime checker. Our work intends to raise more concerns regarding the
memory-safety promise of Rust and facilitates the maturity of the language.
<end quote>

Just "crap" of course. The point here is that to achieve the announced
speed of C++ or C you add to the language an "unsafe" feature. The whole
undertaking is then tainted with that problem!

How would you solve that?

What lessons could be used from the proposals for Rust to the patterns
of buffer overflows in C or C++?

That would need a rational discussion and a bit of effort from your
part. It is not as easy as just dismiss this work as CRAP without a
single rational argument. That is why I classify your attitude as
"evangelist" since NO ARGUMENTS ARE ADVANCED but just "CRAP"...

Incredible!

[Öö Tiib]

On Monday, 20 April 2020 13:05:18 UTC+3, jacobnavia wrote:
> Le 20/04/2020 à 11:23, Öö Tiib a écrit :
> > Your article was crap, live with it. It is
> > surprising for me that Rust already deserves such low attacks.
> >
>
> Have you even read that article?
> No.

I have, two times. It is crap but it wasn't only thing that I wrote.
You did chose not to respond to my points elaborating why it is crap.
Were you afraid? Screaming now instead?

So you discarded my response and now even quote that crappy straw-man
building how the Rust's unsafe API meant for communicating with other
modules in your computer can be misused for making memory-safety defects?
No one has *ever* denied that. It was named "unsafe" for purpose.
Surprised? Who is evangelical here? :D Pathetic.

> How would you solve that?

Solve what? That the world still needs hordes of software developers after
Rust like it did need before? There are no way to solve that. But reducing
pointless, hidden illusions that lurk everywhere, every feature full of
explicitly said out undefined behaviors plus couple defined behaviors
that do something surprising for majority is good idea to reduce indeed.
Rust attempts, maybe fails maybe succeeds future will tell. Mud slinging
shows that it is getting dangerously close.

> What lessons could be used from the proposals for Rust to the patterns
> of buffer overflows in C or C++?
>
> That would need a rational discussion and a bit of effort from your
> part. It is not as easy as just dismiss this work as CRAP without a
> single rational argument. That is why I classify your attitude as
> "evangelist" since NO ARGUMENTS ARE ADVANCED but just "CRAP"...
>
> Incredible!

Your debating style isn't inviting to rational discussion. It is
erasing responses to dodge those, then screaming dogmas and lying.
It looks like you are going foaming-from-mouth-mad there instead,
sorry.

[jacobnavia]

Le 20/04/2020 à 13:00, Öö Tiib a écrit :
> You did chose not to respond to my points elaborating why it is crap.
> Were you afraid? Screaming now instead?

You have posted 2 articles in this thread:
1:

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!

2:

In your second message, you do not put forward any arguments but just
vague dismissals. For instance:

I asked you:

> But why are those unsafe APIs necessary?

You answer:

<quote>

World is full of unsafe APIs. Without ways to access operating systems
or other modules in your computer a programming language is just a toy
in its own sandbox and not a tool. That is obvious but somehow some
morons want to leave impression that Rust claims differently.

<end quote>

The "some morons" qualifier is surely me, of course. That is why I
didn't even answer that. But OK, let's go in depth to your "argument".

If your new language accepts inline assembler, raw pointer usage, and
other goodies you are doing the same thing as C is doing for the sake of
PERFORMANCE!

It is absolutely NOT necessary, as you say, to use raw pointer in your
program to acces the operating system facilities as everyone here knows.
You can use the APIs of the operating system by providing an interface
to the raw OS calls that use bound checked arrays and hide the raw
pointer within containers and other language constructs.

Such a way would be 100% safe but it would take a 0.1% performance hit.
But Rust wants to take over C so it must offer at least the same speed,
and THERE IS THE WRONG DESIGN DECISION!

At the end Rust has the worst of both worlds because its insistence on
raw performance and sacrificing security to raw performance as C or C++
do. Then, you learn a new language for nothing.

[Chris Vine]

On Mon, 20 Apr 2020 12:05:07 +0200
jacobnavia <ja...@jacob.remcomp.fr> wrote:
[snip]

Actually, the arguments have been explained to you by at least 3 people
now.

The problem is that you have failed to understand the paper, which is
largely vacuous. That is evident in your original posting and in your
subsequent responses. You need to get off your high horse, get a little
less excited, and actually think about it before posting.

The point you have failed to understand is that unless operating
explicitly in unsafe mode Rust is memory safe. That is a significant
improvement over C and C++.

Of course if you choose to interface with C code using Rust's FFI, then
your code is only as safe as your C code. And if you explicitly choose
to use unsafe mode in Rust, which can be used to subvert Rust's safety
guarantees, then your code is only as safe as your ability to write
type-unsafe code.

That is not a new revelation. You can deduce this by going to the Rust
site and reading its manual. The authors of the paper could have done
the same. It definitely does not mean, as you claim, that "Rust has the
same memory problem as C and C++", which frankly is a ludicrous summary
of the issues.

[Öö Tiib]

It was indeed accusation since you seem to act like caught on sin
with it.

> If your new language accepts inline assembler, raw pointer usage, and
> other goodies you are doing the same thing as C is doing for the sake of
> PERFORMANCE!

Screaming lies does not make those truths. Raw pointer usage and inline
assembler are commonly unneeded "goodies". I see those extremely rarely
used even in C++ code bases despite pile of undefined behaviors of C++
tries to leave no other way out to achieve something defined at some
places. The main "goodie" from "unsafe" of Rust and its prime purpose
is need to interface with unsafe code and modules of third parties and
operating systems. You can keep running from that, brave sir Robin.

> It is absolutely NOT necessary, as you say, to use raw pointer in your
> program to acces the operating system facilities as everyone here knows.
> You can use the APIs of the operating system by providing an interface
> to the raw OS calls that use bound checked arrays and hide the raw
> pointer within containers and other language constructs.

Operating systems accept raw pointers as parameters and return raw
pointers, usage of those is unsafe, and so operating system calls
remain unsafe whatever you do until these become marked safe.

> Such a way would be 100% safe but it would take a 0.1% performance hit.
> But Rust wants to take over C so it must offer at least the same speed,
> and THERE IS THE WRONG DESIGN DECISION!

:D Why to scream such indoctrinated dogmas? 0.1% does matter next to
nowhere. I have couple times had my algorithms rewritten again in
Java and/or JavaScript for about 300-400% performance loss since
performance was sufficient anyway. More important was scalable time-
complexity while usage of mix of languages in project was perceived
as inconvenient fragility. Java and JavaScript are unsafe as whole
unlike Rust.

> At the end Rust has the worst of both worlds because its insistence on
> raw performance and sacrificing security to raw performance as C or C++
> do. Then, you learn a new language for nothing.

It is just life of engineer to study new tools. If all would sit and
mourn every of the promising tools and technologies that have come and
gone then there would be whole lake of pointless tears. Rust can fail
but the idea of it is anyway very impressive, worth to work on. And
your clumsy mud-slinging attacks that so pathetically miss the point
of its "unsafe" make it certainly stronger.

[Juha Nieminen]

In comp.lang.c++ Paavo Helde <ees...@osa.pri.ee> wrote:
> This paper compares Rust with an hypothetical language called C/C++.
> There is no such language in existence

As much as purists want to claim that C++ is its own independent
programming language that's completely separate and independent
from C, the fact is that in practice something like 99% of C is
valid C++ as-is, without modification.

(This especially if you follow recommended coding guidelines
in C. Like for example never using implicit casting between
incompatible pointer types but always making it explicit.
C++ doesn't allow implicitly casting between incompatible
pointer types while C does, but doing so in C is often frowned
upon in programming style guidelines.)

It can be argued that C++ is a mix of C and the additions that
C++ brings to the table. While not all C programs are valid C++
without modification, as said the vast majority of them are
(and the rest can usually be made valid C++ with minor corrections,
with the exception of a few major modern C features that absolutely
do not work in C++, such as VLAs.)

When someone uses the term "C/C++", he's usually referring to the
overlapping parts of those languages, as well as what both languages
share in terms of behavior. Such as for example memory allocation.
(In C++ the exact same memory allocation function can be used as
in C. C++ also provides its own memory allocation keywords which
don't differ in terms of memory management, only in terms of them
calling constructors and destructors. Both languages also share
the same caveats that memory can be leaked, the same memory freed
more than once, freed memory accessed, and out-of-bounds memory
also likewise accessed. (C++ may offer more tools to automatize
memory management, but it doesn't remove the fact that those
things can happen.)

Thus I don't think it's unreasonable to use the term "C/C++".
It doesn't refer to one singular programming language. It's
referring to two related programming languages as a pair, which share
similar behavior and features.

[jacobnavia]

Le 20/04/2020 à 15:05, Öö Tiib a écrit :
> Operating systems accept raw pointers as parameters and return raw
> pointers, usage of those is unsafe, and so operating system calls
> remain unsafe whatever you do until these become marked safe.

Again:

From your high level language you never call the OS directly. You call
a routine that calls the OS. That way you never leave the language
safety, and it is the routine that calls the OS that uses the raw
pointers, returning a high level object, that uses the raw pointers
returned by the OS but it is protected by the language.

[Bonita Montero]

> When someone uses the term "C/C++", he's usually referring to the
> overlapping parts of those languages, as well as what both languages
> share in terms of behavior. Such as for example memory allocation.

And when you talk about security-concerns iterators of overloaded
[]-operators aren't safer than raw pointers for release-builds.

[Öö Tiib]

But that is pure lie. Name me high level language that has support to
typical I/O like gyroscopes, GPS input, touch gestures, cameras,
microphones, speakers and so on inbuilt? No language comes even
close. The most mundane things like the std::filesystem have become
available on Apple platforms only recently. And this is C++ with
millions invested per year by every platform vendor and Apple is
maker of *major*, *large* platforms.

Demanding freelance Rust to have support for all of it safely at
high level is dishonest attempt to demand it to be born dead. And
it is funny how you run from that and erase my replies stating it.
Why you behave as someone who is caught on crime? :D

[James Kuyper]

On 4/20/20 9:20 AM, Juha Nieminen wrote:
> In comp.lang.c++ Paavo Helde <ees...@osa.pri.ee> wrote:
>> This paper compares Rust with an hypothetical language called C/C++.
>> There is no such language in existence
>
> As much as purists want to claim that C++ is its own independent
> programming language that's completely separate and independent
> from C, the fact is that in practice something like 99% of C is
> valid C++ as-is, without modification.
>
> (This especially if you follow recommended coding guidelines
> in C. Like for example never using implicit casting between
> incompatible pointer types but always making it explicit.
> C++ doesn't allow implicitly casting between incompatible
> pointer types while C does, but doing so in C is often frowned
> upon in programming style guidelines.)

<pedantic>A cast is a particular piece of syntax. That syntax in the
source causes the implementation to generate code which implements the
corresponding conversion. That syntax is not always required in order
for the conversion to occur. When that is the case, it's called an
implicit conversion, not an implicit cast - because it isn't a cast
without that syntax, but it is still a conversion.</pedantic>

Your wording could be interpreted as implying that incompatibility is
not a barrier to C pointer conversions. In fact, in most cases it is a
barrier. Such a conversion is allowed only if one of the two types is
void*. Many people consider this an advantage - creating that advantage
was one of the purposes behind the invention of "void*", though Bjarne
clearly disagreed. Those people write programming style guidelines that
reflect that opinion.

[Guillaume]

Le 19/04/2020 à 14:39, Paavo Helde a écrit :

> 19.04.2020 15:17 jacobnavia kirjutas:

>> 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
>

> 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.

It also irritates me to no end when I see "C/C++".

Still, that doesn't automatically mean the paper's content is worthless.
You can assume that they are talking about the problems that are common
to both C and C++. Yeah, still looks like HR bullshit, but hey.

Anyway, I read it. It's not that bad. But to sum it up, conclusion is
that the "unsafe" parts of Rust are as unsafe as C or C++. What a
surprise. Not sure we learned a lot here.

Now the question is, if Rust can't really be used in real-life projects
without at least some parts written as "unsafe" code, the concern is
valid. But I think the whole point is to use as little unsafe code as
possible, and kind of isolate it. Whether the end result in a given
application is objectively safer would be a more interesting study than
what I read in this paper.

[Ben Bacarisse]

Juha Nieminen <nos...@thanks.invalid> writes:

> In comp.lang.c++ Paavo Helde <ees...@osa.pri.ee> wrote:
>> This paper compares Rust with an hypothetical language called C/C++.
>> There is no such language in existence
>
> As much as purists want to claim that C++ is its own independent
> programming language that's completely separate and independent
> from C, the fact is that in practice something like 99% of C is
> valid C++ as-is, without modification.
>
> (This especially if you follow recommended coding guidelines
> in C. Like for example never using implicit casting between
> incompatible pointer types but always making it explicit.

A cast is an explicit conversion so "implicit cast" sounds odd to some
people. You are referring, I think, to a conversion without a cast
operator.

> C++ doesn't allow implicitly casting between incompatible
> pointer types while C does, but doing so in C is often frowned
> upon in programming style guidelines.)

C++ does not use C's definition of compatible types so there is no
obvious and unambiguous meaning for this statement. C++ defines two
kinds of type compatibility but neither is directly related to the rules
about pointer conversions.

However, C++ does allow some pointer conversions between types that
would probably be considered "incompatible" by most reasonable meanings
of the word. For example:

struct s { int x; } s;
void *p = &s;

Of course you might mean that being able to assign the pointers is what
you mean by "compatible" in C++, in which case, yes!

--
Ben.

[jacobnavia]

Le 20/04/2020 à 16:02, Öö Tiib a écrit :
> Demanding freelance Rust to have support for all of it safely at
> high level is dishonest attempt to demand it to be born dead.

Surely not. It is just a matter of doing it automatically.

Given a .h file with the C prototypes of the OS API you can parse that
and generate a rust definitions file, and generate automatically the
interface functions. The only thing you need to do is a mapping from the
C types to the Rust types.

I have done that and is absolutely doable...

[Keith Thompson]

Juha Nieminen <nos...@thanks.invalid> writes:
> In comp.lang.c++ Paavo Helde <ees...@osa.pri.ee> wrote:
>> This paper compares Rust with an hypothetical language called C/C++.
>> There is no such language in existence
>
> As much as purists want to claim that C++ is its own independent
> programming language that's completely separate and independent
> from C,

I don't recall anyone making that extreme claim.

> the fact is that in practice something like 99% of C is
> valid C++ as-is, without modification.

I wouldn't try to guess the percentage. Yes, a lot of C code
is valid C++. A smaller percentage of C programs are valid C++
programs. Some (probably small) percentage of C programs are valid
C++ programs with different semantics. And very little *good*
C code is good C++ code.

> (This especially if you follow recommended coding guidelines
> in C. Like for example never using implicit casting between
> incompatible pointer types but always making it explicit.
> C++ doesn't allow implicitly casting between incompatible
> pointer types while C does, but doing so in C is often frowned
> upon in programming style guidelines.)

(I'm probably going to repeat some of what others have said.)

There's no such thing as "implicit casting". There are *conversions*,
which can be either implicit or explicit. An explicit conversion
is a cast.

Other than cases involving void*, C doesn't allow implicit
conversions between incompatible pointer types. It's easy to think
that it does because some compilers allow such implicit conversions
by default, perhaps with a warning. For example:

double d;
double *dp = &d;
int *ip = dp; // constraint violation

The conversion in the initialization of ip is a constraint violation
in C, requiring a diagnostic. gcc, by default, issues a non-fatal
warning -- which is permitted by the standard. I suppose you could
say that C "permits" the conversion in the sense that it doesn't
require the compiler to reject it -- but the same is true of syntax
errors, or anything not involving a #error directive.

As far as I know, the only difference between C and C++ in this area
involves void* conversions. g++, unlike gcc, treats the conversion
in the code above as a fatal error by default, but that's not a
difference between the languages.

[...]

> When someone uses the term "C/C++", he's usually referring to the
> overlapping parts of those languages, as well as what both languages
> share in terms of behavior.

[...]

My problem with the term "C/C++" is that you can never be sure just what
it means. It could mean "C and C++", "C or C++", "C xor C++", "the
common subset of C and C++", or "the person writing this job description
doesn't understand the relationship between the languages".

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Alf P. Steinbach]

He was surely referring to the paper's authors, claiming that they're
attacking a constructed straw-man.

My take: I just skimmed the article but I don't think they're doing an
attack or claiming anything improper about what Rust claim. I could have
overlooked some detail though. Or, I could have failed to see a larger
scale implication from context that I'm not familiar with.

Anyway, research that validates the obvious can be valuable. This
research validates the obvious that unsafe features are unsafe. However,
research that addresses non-obvious things can be /much more valuable/,
like a zintillion orders of magnitude more valuable, so that the money
used on this research could probably have been better spent.


> [snip]

- Alf

[Chris Vine]

Rust already has an FFI for C. It doesn't need another. The point is
that if you call into C code then your Rust code cannot be any safer
than your C code.

[Melzzzzz]

C/C++ programmers are ones that program C++ like C ;)
That means they are not using safe features of C++...

>


--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

[Melzzzzz]

In Rust, you barry unsafe code in library, and then do all the
work in safe level. If library has a bug it has a bug ;)

[Chris Vine]

On Mon, 20 Apr 2020 20:16:57 GMT
Melzzzzz <Melz...@zzzzz.com> wrote:
> On 2020-04-20, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> > On Mon, 20 Apr 2020 18:08:18 +0200
> > jacobnavia <ja...@jacob.remcomp.fr> wrote:
> >> Le 20/04/2020 à 16:02, Öö Tiib a écrit :
> >> > Demanding freelance Rust to have support for all of it safely at
> >> > high level is dishonest attempt to demand it to be born dead.
> >>
> >> Surely not. It is just a matter of doing it automatically.
> >>
> >> Given a .h file with the C prototypes of the OS API you can parse that
> >> and generate a rust definitions file, and generate automatically the
> >> interface functions. The only thing you need to do is a mapping from the
> >> C types to the Rust types.
> >>
> >> I have done that and is absolutely doable...
> >
> > Rust already has an FFI for C. It doesn't need another. The point is
> > that if you call into C code then your Rust code cannot be any safer
> > than your C code.
>
> In Rust, you barry unsafe code in library, and then do all the
> work in safe level. If library has a bug it has a bug ;)

Well, that's what you do in Haskell and other "safe" languages with a
C FFI. In Rust you can do some of it in unsafe Rust.

Of course if the posting which began all this is correct, then "Haskell
has the same memory problem as C and C++". After all, as a minimum it
has to call into services provided by the OS with (in Unix-like OSes) C
linkage. Errrr ... .

[Melzzzzz]

ADA has same problem as well...

[Chris M. Thomasson]

Indeed! Well... Check this crap out, using C++ like a C...

https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp

Can you get it to run and produce a rendering? ct_plane.ppm

[Melzzzzz]

That compiles as C ;)
I meant for programs that compile as C++ only :)

[Melzzzzz]

On 2020-04-20, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:

Oh you used complex ;)

[Öö Tiib]

Each kind of safety takes following certain policies and obeying
certain constraints. When the foreign code does not do that then calls
of it are potentially as unsafe, leaky, vulnerable and frail as from
any other language. The foreign code does not start to obey those
policies and constrains because you automatically generated some
kind of interface wrapper layer from C header files. Therefore your
claims are from field of science fiction, not software engineering.

[Christian Gollwitzer]

Am 20.04.20 um 16:02 schrieb Öö Tiib:

> On Monday, 20 April 2020 16:30:53 UTC+3, jacobnavia wrote:
>> Le 20/04/2020 à 15:05, Öö Tiib a écrit :
>>> Operating systems accept raw pointers as parameters and return raw
>>> pointers, usage of those is unsafe, and so operating system calls
>>> remain unsafe whatever you do until these become marked safe.
>>
>> Again:
>>
>> From your high level language you never call the OS directly. You call
>> a routine that calls the OS. That way you never leave the language
>> safety, and it is the routine that calls the OS that uses the raw
>> pointers, returning a high level object, that uses the raw pointers
>> returned by the OS but it is protected by the language.
>
> But that is pure lie. Name me high level language that has support to
> typical I/O like gyroscopes, GPS input, touch gestures, cameras,
> microphones, speakers and so on inbuilt? No language comes even
> close.

JavaScript run in the browser. Not to dismiss your other points, though.

Christian

[Öö Tiib]

How that JavaScript is special? My experience is different.

For example I can use the chrome.bluetooth API from C++ (Wasm) or
JavaScript if my target browser is Google Chrome ran on OS X, Windows
or Chrome OS.
<https://developer.chrome.com/apps/bluetooth>

It is no way feature of JavaSript any more than Win32 Bluetooth API
is feature of C somehow.
<https://docs.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-start-page>

[Dan Cross]

In article <r7hfh7$3rq$1...@dont-email.me>,

jacobnavia <ja...@jacob.remcomp.fr> wrote:
>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

"Unsafe code is unsafe; film at 11."

There's not much to see in this paper. It's
well-known that Rust gives you an unsafe superset
of the language that gives you access to dangerous
features; use of that superset is even preceded
by the `unsafe` keyword, so the notion of unsafety
is built into the language at the syntactic level.

"Unsafe" in Rust means two things: first, it allows
the compiler to relax its automated checking of
some of Rust's guarantees, under the assumption
that it's up to the programmer to enforce those
guarantees. Second, it's a note to future
programmers that, "there be dragons here."

In all cases pointed out by this paper, the code
in question violated Rust's rules through misuse
of `unsafe`. In other words, the programmers
messed up.

While certainly problems, it's not clear how
this is the language's fault. If the programmers
could have restricted themselves to the safe
subset of the language, it's not clear that any
of these bugs would have been arisen. Can Rust
do better _in the unsafe superset_? Probably,
but I don't think anyone disputes that. Rust
helps, but doesn't absolve programmers from
knowing what they are doing.

FWIW, I do see lots of beginning Rust programmers
misusing `unsafe`; in particular, it's often
over-used by those getting working with the
language for the first time.

- Dan C.

[Chris M. Thomasson]

bingo! Therefore its C++... ;^)

[jacobnavia]

The point is that you can use Bluetooth from java script without using
inline asm or C or other non java script stuff.

The problem with Rust is that you are forced to use procedures declared
as "unsafe" for doing that, leaving the promises of the Rust language of
safe memory operations.

The solution for Rust would be to drop "unsafe" and stick with its
language throughout. A FFI would provide the interface to any API
declared for C or C++.

But that would have a cost in performance since you would have to go
through an interface, and the designers decided against it, for
performance's sake. And that is the problem.

They opened the Pandora box.

jacob

[Juha Nieminen]

In comp.lang.c++ Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>> C/C++ programmers are ones that program C++ like C ;)
>>>> That means they are not using safe features of C++...
>>>
>>> Indeed! Well... Check this crap out, using C++ like a C...
>>>
>>> https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp
>>>
>>> Can you get it to run and produce a rendering? ct_plane.ppm
>>
>> Oh you used complex ;)
>
> bingo! Therefore its C++... ;^)

Hey, at least it doesn't use "typedef struct whatever { ... } whatever;"

Also, I'm not sure it's completely valid C++ either, since it uses "sin" and
"cos" without the namespace specifier and without a <cmath>/<math.h> include.

(If I understand correctly those names are guaranteed to be in the global
namespace only if you #include <math.h>, which is not done here. I'm not sure
those names are guaranteed to be defined at all without <math.h> or <cmath>.
I don't know if #include <complex> guarantees <cmath>.)

[jacobnavia]

Le 22/04/2020 à 22:52, Dan Cross a écrit :
> In article <r7hfh7$3rq$1...@dont-email.me>,
> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> 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
>
> "Unsafe code is unsafe; film at 11."
>
> There's not much to see in this paper. It's
> well-known that Rust gives you an unsafe superset
> of the language that gives you access to dangerous
> features; use of that superset is even preceded
> by the `unsafe` keyword, so the notion of unsafety
> is built into the language at the syntactic level.
>

The problem with Rust is then, that to do anything like bluetooth or low
level i/o you have to use "unsafe". Then, you are in your own and all
the problems of C and C++ appear, eliminating any advantage of Rust over
those languages, the point I wanted to make with the article where I
started this thread.

> "Unsafe" in Rust means two things: first, it allows
> the compiler to relax its automated checking of
> some of Rust's guarantees, under the assumption
> that it's up to the programmer to enforce those
> guarantees. Second, it's a note to future
> programmers that, "there be dragons here."
>

No checks, yes. I am used to it since I program in C. My point is,
what's the point of learning Rust since I have to do the same thing as
in C...

> In all cases pointed out by this paper, the code
> in question violated Rust's rules through misuse
> of `unsafe`. In other words, the programmers
> messed up.
>

Of course the programmers messed up. Just like in C I mess up sometimes.

> While certainly problems, it's not clear how
> this is the language's fault. If the programmers
> could have restricted themselves to the safe
> subset of the language, it's not clear that any
> of these bugs would have been arisen.

The point being here, is that they CAN'T RESTRICT THEMLSEVES TO THAT
SAFE PART because they have to do things that are necessary and not
possible within the safe part!

Can Rust
> do better _in the unsafe superset_? Probably,
> but I don't think anyone disputes that. Rust
> helps, but doesn't absolve programmers from
> knowing what they are doing.
>

I.E. the added value of Rust is zero.

> FWIW, I do see lots of beginning Rust programmers
> misusing `unsafe`; in particular, it's often
> over-used by those getting working with the
> language for the first time.
>
> - Dan C.
>

In the article they point out to bugs in the standard library of Rust,
i.e. programmers that should be fairly advanced...

I do not blame them. Programming is hard. I just wanted to point out
that there is NO magic bullet, no language that will be of help, unless
the language takes a performance hit by checking everything.

I wrote a container library for C. Should I check everything? Should all
functions check for NULL values or wrong parameters? That slows down the
library...

And I decided against performance. We have now machines that run at
incredible speeds with vast amounts of memory and ressources and we
still hesitate to make that NULL check?

This obsession with performance is what I question in Rust. They should
never allow "unsafe". The whole point of a new language disappears then.

[Öö Tiib]

The <complex> guarantees overloads like std::cos(const std::complex<T>& x).
The lookup rules quarantee looking cos up in std namespace when argument
std::complex is in that namespace.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
>> Also, I'm not sure it's completely valid C++ either, since it uses "sin" and
>> "cos" without the namespace specifier and without a <cmath>/<math.h> include.
>>
>> (If I understand correctly those names are guaranteed to be in the global
>> namespace only if you #include <math.h>, which is not done here. I'm not sure
>> those names are guaranteed to be defined at all without <math.h> or <cmath>.
>> I don't know if #include <complex> guarantees <cmath>.)
>
> The <complex> guarantees overloads like std::cos(const std::complex<T>& x).
> The lookup rules quarantee looking cos up in std namespace when argument
> std::complex is in that namespace.

In this case sin() and cos() are being called with double type parameters.

[Öö Tiib]

The overloads that take fundamental parameters are not guaranteed by
<complex> and also the namespace lookup does not work with those.
It is another lousy thing with those textual inclusions ...
implementation "may". So it is likely that on some
platforms additional #includes and/or qualification is needed.

[Melzzzzz]

On 2020-04-23, jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Le 22/04/2020 à 22:52, Dan Cross a écrit :
>> In article <r7hfh7$3rq$1...@dont-email.me>,
>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> 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
>>
>> "Unsafe code is unsafe; film at 11."
>>
>> There's not much to see in this paper. It's
>> well-known that Rust gives you an unsafe superset
>> of the language that gives you access to dangerous
>> features; use of that superset is even preceded
>> by the `unsafe` keyword, so the notion of unsafety
>> is built into the language at the syntactic level.
>>
>
> The problem with Rust is then, that to do anything like bluetooth or low
> level i/o you have to use "unsafe". Then, you are in your own and all
> the problems of C and C++ appear, eliminating any advantage of Rust over
> those languages, the point I wanted to make with the article where I
> started this thread.

It is not problem if you sepparate unsafe and safe code.
Small portions written in unsafe code and well tested...

>
>> "Unsafe" in Rust means two things: first, it allows
>> the compiler to relax its automated checking of
>> some of Rust's guarantees, under the assumption
>> that it's up to the programmer to enforce those
>> guarantees. Second, it's a note to future
>> programmers that, "there be dragons here."
>>
>
> No checks, yes. I am used to it since I program in C. My point is,
> what's the point of learning Rust since I have to do the same thing as
> in C...

Point is that you don't have to program in unsafe blocks
all the time...

[Dan Cross]

In article <r7rfb2$bsu$1...@dont-email.me>,

jacobnavia <ja...@jacob.remcomp.fr> wrote:
>Le 22/04/2020 à 22:52, Dan Cross a écrit :
>> "Unsafe code is unsafe; film at 11."
>>
>> There's not much to see in this paper. It's
>> well-known that Rust gives you an unsafe superset
>> of the language that gives you access to dangerous
>> features; use of that superset is even preceded
>> by the `unsafe` keyword, so the notion of unsafety
>> is built into the language at the syntactic level.
>
>The problem with Rust is then, that to do anything like bluetooth or low
>level i/o you have to use "unsafe". Then, you are in your own and all
>the problems of C and C++ appear, eliminating any advantage of Rust over
>those languages, the point I wanted to make with the article where I
>started this thread.

That's simply not true, or rather, not true to the extent
the paper's authors make it out to be. I've written three
kernels in Rust now, including doing lots of "low-level i/o"
and you'd be really surprised how far you can push safe code.

>> "Unsafe" in Rust means two things: first, it allows
>> the compiler to relax its automated checking of
>> some of Rust's guarantees, under the assumption
>> that it's up to the programmer to enforce those
>> guarantees. Second, it's a note to future
>> programmers that, "there be dragons here."
>
>No checks, yes. I am used to it since I program in C. My point is,
>what's the point of learning Rust since I have to do the same thing as
>in C...

Seat belts don't save all lives, so what's the point of
wearing a seat belt? A blade guard on a table saw can't
stop you from _ever_ cutting off your fingers, so why
bother?

Rust can't prevent _all_ bugs; but that's axiomatic. But
like all sorts of safety apparatus, it can cut out a lot
of them.

You may have to do some, or even many things the same way
you do them in C. But many bugs that would be runtime
failures in C will be compile-time errors in Rust.

>> In all cases pointed out by this paper, the code
>> in question violated Rust's rules through misuse
>> of `unsafe`. In other words, the programmers
>> messed up.
>
>Of course the programmers messed up. Just like in C I mess up sometimes.

Obviously it won't prevent you from _ever_ messing up.
It just dramatically decreases the possible error surface.

>> While certainly problems, it's not clear how
>> this is the language's fault. If the programmers
>> could have restricted themselves to the safe
>> subset of the language, it's not clear that any
>> of these bugs would have been arisen.
>
>The point being here, is that they CAN'T RESTRICT THEMLSEVES TO THAT
>SAFE PART because they have to do things that are necessary and not
>possible within the safe part!

I find this argument specious at best. I've written a
lot of Rust code in the last two years and more often
than not, _most_ programmers _can_ restrict themselves
to that safe subset. Where they cannot, the interface
can be tightly controlled. I've written a lot _more_
C code over three decades. The things you can do in
Rust with respect to safetly are things you simply
cannot do in C or C++.

>> Can Rust
>> do better _in the unsafe superset_? Probably,
>> but I don't think anyone disputes that. Rust
>> helps, but doesn't absolve programmers from
>> knowing what they are doing.
>>
>
>I.E. the added value of Rust is zero.

I'm sorry, but that's ridiculous. Have you ever actually
written anything in Rust?

>> FWIW, I do see lots of beginning Rust programmers
>> misusing `unsafe`; in particular, it's often
>> over-used by those getting working with the
>> language for the first time.
>

>In the article they point out to bugs in the standard library of Rust,
>i.e. programmers that should be fairly advanced...

Certainly there are bugs. Now compare the number
of bugs in the Rust standard library to the number
of bugs in, e.g., glibc.

>I do not blame them. Programming is hard. I just wanted to point out
>that there is NO magic bullet, no language that will be of help, unless
>the language takes a performance hit by checking everything.

I don't think anyone suggest that Rust is a silver bullet.

Also, I think you probably haven't written much if anything
in Rust. Much of the burden of the types of checks you
describe are shifted to compile time in the safe subset.
The properties of the language allow the compiler to make
assertions that just cannot be made in, say, a C program.

In many ways, Rust is more restrictive, but that's a
tradeoff: one trades permissiveness for safety without
a runtime penalty.

>I wrote a container library for C. Should I check everything? Should all
>functions check for NULL values or wrong parameters? That slows down the
>library...
>
>And I decided against performance. We have now machines that run at
>incredible speeds with vast amounts of memory and ressources and we
>still hesitate to make that NULL check?

If I can create a situation where I _know_ that, say, a
pointer _cannot_ be NULL, then why would i check it for
NULL?

static const char *foo = "hi";
if (foo != NULL) {
if (strcmp(foo, "hi") == 0)
printf("Hi!\n");

Here, the check for `NULL` is obviously superflous; the
programmer could omit it without sacrificing correctness
or safety.

In Rust, the semantics of the language are such that the
compiler can often make this determination _at compile
time_ (note that even a C compiler can do this for this
particular, contribed example).

>This obsession with performance is what I question in Rust. They should
>never allow "unsafe". The whole point of a new language disappears then.

`unsafe` exists for situations where you need `unsafe`: that
sounds tautological, but the safe subset of the language is
_sometiems_ too restrictive. The seatbelt in my car prevents
me from flying through the windshield should I get into a
crash. That's good, but it also precents me from picking
something up from the floor at the other seat if I'm stopped.

I don't care to do it, but if I'm stopped at e.g. a traffic
light I have occasionally taken the car out of gear,
unbuckled the seatbelt, reached over, and retrieved
something that fell, then re-buckled my seatbelt and put
the car back into gear. I don't think anyone would argue
that that renders seatbelts "useless". That's the analogous
situation with Rust's `unsafe` superset.

- Dan C.

[Christian Gollwitzer]

Am 22.04.20 um 13:52 schrieb Öö Tiib:

> On Wednesday, 22 April 2020 12:56:33 UTC+3, Christian Gollwitzer wrote:
>> Am 20.04.20 um 16:02 schrieb Öö Tiib:

>>> But that is pure lie. Name me high level language that has support to
>>> typical I/O like gyroscopes, GPS input, touch gestures, cameras,
>>> microphones, speakers and so on inbuilt? No language comes even
>>> close.
>>
>> JavaScript run in the browser. Not to dismiss your other points, though.
>
> How that JavaScript is special? My experience is different.
>
> For example I can use the chrome.bluetooth API from C++ (Wasm) or
> JavaScript if my target browser is Google Chrome ran on OS X, Windows
> or Chrome OS.
> <https://developer.chrome.com/apps/bluetooth>
>
> It is no way feature of JavaSript any more than Win32 Bluetooth API
> is feature of C somehow.
> <https://docs.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-start-page>

The point was, if I understood you correctly, that for access of I/O
devices like camera, microphone, acceleration, fancy graphics etc. you
call out to unsafe APIs, and that in most high level languages (with no
direct access to memory) you need to interface in an unsafe way with C
APIs, which means that to be useful, a language must provide a unsafe
FFI to support C APIs - or otherwise can do only "boring" programs like
numerical calculations.

JavaScript in the browser is a counterexample because many - if not all
- of the things you mentioned are wrapped in a safe way and
standardized. It is impossible from JavaScript to execute arbitrary
native code, for security reasons, and still you can write very useful
software in it, because the standard library provides safe access to all
those features. E.g. there are videoconferencing systems written in
JavaScript, you can write games, etc. Plus all of this is moderately
portable across OSes and to some extent across browsers.

Christian

[Chris M. Thomasson]

On 4/23/2020 12:04 AM, Juha Nieminen wrote:
> In comp.lang.c++ Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>>> C/C++ programmers are ones that program C++ like C ;)
>>>>> That means they are not using safe features of C++...
>>>>
>>>> Indeed! Well... Check this crap out, using C++ like a C...
>>>>
>>>> https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp
>>>>
>>>> Can you get it to run and produce a rendering? ct_plane.ppm
>>>
>>> Oh you used complex ;)
>>
>> bingo! Therefore its C++... ;^)
>
> Hey, at least it doesn't use "typedef struct whatever { ... } whatever;"
>
> Also, I'm not sure it's completely valid C++ either, since it uses "sin" and
> "cos" without the namespace specifier and without a <cmath>/<math.h> include.

Yup! I totally forgot to add std:: to many function calls! Damn. I was
quickly porting this from C over to C++, and it slipped my mind. ;^o

[Chris M. Thomasson]

On 4/23/2020 1:49 PM, Chris M. Thomasson wrote:
> On 4/23/2020 12:04 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Chris M. Thomasson <chris.m.t...@gmail.com>
>> wrote:
>>>>>> C/C++ programmers are ones that program C++ like C ;)
>>>>>> That means they are not using safe features of C++...
>>>>>
>>>>> Indeed! Well... Check this crap out, using C++ like a C...
>>>>>
>>>>> https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp
>>>>>
>>>>>
>>>>> Can you get it to run and produce a rendering? ct_plane.ppm
>>>>
>>>> Oh you used complex ;)
>>>
>>> bingo! Therefore its C++... ;^)
>>
>> Hey, at least it doesn't use "typedef struct whatever { ... } whatever;"
>>
>> Also, I'm not sure it's completely valid C++ either, since it uses
>> "sin" and
>> "cos" without the namespace specifier and without a <cmath>/<math.h>
>> include.
>
> Yup! I totally forgot to add std:: to many function calls! Damn. I was
> quickly porting this from C over to C++, and it slipped my mind. ;^o

I forgot <cmath> as well. Missed it when everything compiled right up
with just <complex>. double damn! ;^o

[Alf P. Steinbach]

On 23.04.2020 22:49, Chris M. Thomasson wrote:
> On 4/23/2020 12:04 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Chris M. Thomasson <chris.m.t...@gmail.com>
>> wrote:
>>>>>> C/C++ programmers are ones that program C++ like C ;)
>>>>>> That means they are not using safe features of C++...
>>>>>
>>>>> Indeed! Well... Check this crap out, using C++ like a C...
>>>>>
>>>>> https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp
>>>>>
>>>>>
>>>>> Can you get it to run and produce a rendering? ct_plane.ppm
>>>>
>>>> Oh you used complex ;)
>>>
>>> bingo! Therefore its C++... ;^)
>>
>> Hey, at least it doesn't use "typedef struct whatever { ... } whatever;"
>>
>> Also, I'm not sure it's completely valid C++ either, since it uses
>> "sin" and
>> "cos" without the namespace specifier and without a <cmath>/<math.h>
>> include.
>
> Yup! I totally forgot to add std:: to many function calls! Damn. I was
> quickly porting this from C over to C++, and it slipped my mind. ;^o

Always compile with at least 2 compilers, if possible.


> [snip]

- Alf

[Juha Nieminen]

In comp.lang.c++ Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> Yup! I totally forgot to add std:: to many function calls! Damn. I was
>> quickly porting this from C over to C++, and it slipped my mind. ;^o
>
> I forgot <cmath> as well. Missed it when everything compiled right up
> with just <complex>. double damn! ;^o

While you are at it, maybe change the calloc() to a std::vector?
Much simpler, and shouldn't have much of an impact on performance.

[Tim Rentsch]

Juha Nieminen <nos...@thanks.invalid> writes:

> In comp.lang.c++ Paavo Helde <ees...@osa.pri.ee> wrote:
>
>> This paper compares Rust with an hypothetical language called C/C++.
>> There is no such language in existence
>

> in practice something like 99% of C is valid C++ as-is, without
> modification.

It may be that 99% of C constructs are valid C++ as is.

Certainly it is not the case that 99% of C programs are valid C++
programs. That number is closer to 0%.

[Tim Rentsch]

Richard Damon <Ric...@Damon-Family.org> writes:

> On 4/19/20 8:39 AM, Paavo Helde wrote:

>
>> 19.04.2020 15:17 jacobnavia kirjutas:
>>
>>> 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
>>

>> 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. [...]

Already too small to be practicable in any serious project,
and getting smaller by the hour.

[Juha Nieminen]

Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> Certainly it is not the case that 99% of C programs are valid C++
> programs. That number is closer to 0%.

Can you explain why? I can't immediately think of a reason why no
C program would be valid C++ without modification (especially now
that the standardization committee decided that standard headers
inherited from C with names in the form of <name.h> are valid and
will put everything in the global namespace.)

[Jorgen Grahn]

I'm more interested in why people /care/. This topic generates a lot
of heat, over and over again ... but as I see it, pretty much
everyone[0] has a C compiler and a C++ compiler, and will compile
their C code with the former and their C++ code with the latter.

The ability to use C libraries from C++ (without any glue) matters
though.

/Jorgen

[0] Not everyone.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Keith Thompson]

One common reason is that C code typically doesn't cast the result
of malloc(), but C++ does not permit implicit conversion from void*
to (other) object pointer types.

Another is that C++ string literals are const, so this:
char *s = "hello";
is invalid C++.

A less common reason might be C code that uses C++ keywords as
identifiers. (I've occasionally done this deliberately.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Chris M. Thomasson]

Big time. It would be nice to have a destructor in there to
automatically destruct the vector, ahh shit!, std::vector. ;^)

[Chris M. Thomasson]

Indeed! I was only working with GCC. Iirc, MSVC might compile it as well.

[red floyd]

On 4/25/20 3:15 PM, Keith Thompson wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
>>> Certainly it is not the case that 99% of C programs are valid C++
>>> programs. That number is closer to 0%.
>>
>> Can you explain why? I can't immediately think of a reason why no
>> C program would be valid C++ without modification (especially now
>> that the standardization committee decided that standard headers
>> inherited from C with names in the form of <name.h> are valid and
>> will put everything in the global namespace.)
>
> One common reason is that C code typically doesn't cast the result
> of malloc(), but C++ does not permit implicit conversion from void*
> to (other) object pointer types.
>
> Another is that C++ string literals are const, so this:
> char *s = "hello";
> is invalid C++.
>
> A less common reason might be C code that uses C++ keywords as
> identifiers. (I've occasionally done this deliberately.)
>

And one highly unlikely scenario (May apply to C90 only):

x = y //* divided by */ z;

[Alf P. Steinbach]

Even more unlikely, that someone would use complex numbers in C.

- Alf

[James Kuyper]

On 4/25/20 11:01 PM, Alf P. Steinbach wrote:
...

> Even more unlikely, that someone would use complex numbers in C.

<https://searchcode.com/?q=%22%3Ccomplex.h%3E%22&lan=28>

[David Brown]

Indeed. Mostly you want C /headers/ to be useable from C++, with the
usual conditional extern "C" part. It's rare that you need to have the
C implementation file be valid C++ (with the same semantics).

I've had occasional customers ask that the C files be valid C++, in case
they later want to change the files to being C++ - it is not an onerous
requirement. But I don't think it is a common one.

[Juha Nieminen]

Keith Thompson <Keith.S.T...@gmail.com> wrote:
> Another is that C++ string literals are const, so this:
> char *s = "hello";
> is invalid C++.

Wouldn't that be UB even in C?

(Ok, using a non-const pointer to point to a string literaly is not in
itsef UB, but if you ever try to modify it...)

I believe that most competent C programmers would never use non-const
char*'s to handle string literals (and most competent C compilers will
give a huge-ass warning about it).

[James Kuyper]

On 4/27/20 8:06 AM, Juha Nieminen wrote:
> Keith Thompson <Keith.S.T...@gmail.com> wrote:
>> Another is that C++ string literals are const, so this:
>> char *s = "hello";
>> is invalid C++.
>
> Wouldn't that be UB even in C?

No, it's code with perfect well-defined behavior. "hello" has the type
char[6], and in this context gets implicitly converted into a char*
pointing at the first element of that array. In C++, it has the type
const char[6], and gets implicitly converted to const char*. Assigning a
const char* value to a char* object would violate the rules of either
language, but it isn't a const char* in C.

> (Ok, using a non-const pointer to point to a string literaly is not in
> itsef UB, but if you ever try to modify it...)

Correct - any attempt to modify that string has undefined behavior. But
if no such attempt is made, the behavior is well-defined (though such
code is a potential trap for future maintainers of the code).

> I believe that most competent C programmers would never use non-const
> char*'s to handle string literals (and most competent C compilers will
> give a huge-ass warning about it).

A lot of people don't bother with that; they may not qualify as
"competent", but they're quite numerous, and a lot of them seem to be
currently earning money writing C code, so it is important to look out
for such problems.

[Tim Rentsch]

Juha Nieminen <nos...@thanks.invalid> writes:

> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
>
>> Certainly it is not the case that 99% of C programs are valid C++
>> programs. That number is closer to 0%.
>
> Can you explain why? I can't immediately think of a reason why no

> C program would be valid C++ without modification [...]

There are a lot of ways that C code doesn't work as C++. If a C
program violates even one of these ways it is no longer a valid C++
program. As programs get larger, and as more third-party libraries
are used, the chance of using one of the non-C++ forms gets bigger;
asymptotically the ratio of C++-valid C programs to C programs goes
to zero.

I'm sure you know many of the ways that C code can fail to be
valid C++, but probably there are some you haven't thought of.
Certainly there are ones I didn't think of until just recently
when I ran a piece of C code through a C++ compiler. Some of
the obvious problems:

use of C++ keywords
use of _Bool
use of restrict
string literal not const
conversion of void* without a cast

Several items related to enumerated types:

mismatch of type chosen for enumerated types
overflow in implicit constant conversion
invalid conversion (basic integer type to enumerated type)

Some C constructs that are either not supported or not completely
supported in C++:

designated initializers
compound literals
anonymous structs
parameter declarators (related to variable length arrays)
uninitialized const (forward/"tentative" definition)

Some C++ constraints are not satisfied by the C code:

narrowing conversion
comparison of distinct pointer types (eg, int(*)[3] == int(*)[])
no user-provided default constructor (I'm not sure what
caused this error but the C code compiles without
problem)

Some error messages I didn't understand (I didn't spend time
trying to track these down; it's possible they are cascaded
errors):

redefinition of type (?)
name redeclared as a different kind of symbol (?)

All of the above errors were produced compiling a single C
translation unit, encompassing about 3000 lines of source
(include non-system header includes). The C++ compiles were done
using g++, as C++14, and again as C++17 (the C++17 was done as
a sanity check to see if some particular errors might have
disappeared; AFAICS none did).

Besides the problems that show up as compile errors, there are
semantic differences. These incompatibilities are worse than the
ones that get compiler warnings, as there may silently produce
different behavior or be undefined behavior. I haven't tried to
do an exaustive search for these, but there are at least three:

inline functions - semantic differences between C and C++.
unions - C allows type punning, C++ does not.
"common initial sequence" - the rules for which members
belong to the common initial sequence are (I think)
the same in C and C++, but how those members may be
used is different in C and C++. In particular, some
cases that have defined behavior in C are undefined
behavior in C++.

Of course, it is possible to avoid all of these incompatibilities
if one is determined to do so. But people who are writing C
don't do that, partly because it's a big pain in the ass to try
to do it, and partly because there is no particular incentive to
do so. There isn't anything especially exotic about the C code
I used for my C++ test compilations; probably some of the error
conditions shown above are a product of less common usages, but
certainly not all of them were. Given the number and variety of
differences between the two languages, the chance of any given C
program of any size also being a valid C++ program seems rather
remote. But don't take my word for it - take any open source C
program and try compiling it as C++. What results do you see?

[Tim Rentsch]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> On Sat, 2020-04-25, Juha Nieminen wrote:
>
>> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
>>
>>> Certainly it is not the case that 99% of C programs are valid C++
>>> programs. That number is closer to 0%.
>>
>> Can you explain why? I can't immediately think of a reason why no
>> C program would be valid C++ without modification (especially now
>> that the standardization committee decided that standard headers
>> inherited from C with names in the form of <name.h> are valid and
>> will put everything in the global namespace.)
>
> I'm more interested in why people /care/. This topic generates a lot
> of heat, over and over again ... but as I see it, pretty much

> everyone has a C compiler and a C++ compiler, and will compile

> their C code with the former and their C++ code with the latter.

Speaking for myself, I am not bothered at all that C and C++ are
different languages. In fact I think it's good that they are, and
they should be free to go their separate ways. It would be better
for both languages to give up on the idea of "harmonizing" C and
C++, which is a pointless fiction (or worse, a way of making C be
more like C++, without C++ changing in any significant way). I
would much rather see two clearly delineated choice points than
some sort of muddled middle ground. If and when I want to take
the C++ view, I write C++; if and when I want to take the C view,
I write C. I see no reason to confuse the issue by pretending
there is some sort of significant common ground between them.
Thirty years ago there was, but now there isn't, and it's time to
move on.

[Juha Nieminen]

Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> Speaking for myself, I am not bothered at all that C and C++ are
> different languages. In fact I think it's good that they are, and
> they should be free to go their separate ways. It would be better
> for both languages to give up on the idea of "harmonizing" C and
> C++, which is a pointless fiction (or worse, a way of making C be
> more like C++, without C++ changing in any significant way). I
> would much rather see two clearly delineated choice points than
> some sort of muddled middle ground. If and when I want to take
> the C++ view, I write C++; if and when I want to take the C view,
> I write C. I see no reason to confuse the issue by pretending
> there is some sort of significant common ground between them.
> Thirty years ago there was, but now there isn't, and it's time to
> move on.

At a very minimum enough compatibility would be good to maintain that
C libraries can be used directly from C++ (with a simple extern "C" {}
declaration of the C stuff).

Since C libraries often use more than just function declarations,
C++ still needs to support eg. C style structs, typedefs, etc.
Breaking compatibility with C libraries would be a huge setback.

[Juha Nieminen]

Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> I'm sure you know many of the ways that C code can fail to be
> valid C++, but probably there are some you haven't thought of.
> Certainly there are ones I didn't think of until just recently
> when I ran a piece of C code through a C++ compiler. Some of
> the obvious problems:

One curious difference between C and C++, which I only learned the
details of recently, is the difference in semantics of a const
variable at the global scope.

For example, if you have this in one compilation unit:

extern const char* const gName;

and this in another compilation unit:

const char* const gName = "Name";

and try to use that gName in that first compilation unit, in C it will
compile fine, but in C++ you'll get a linker error about "gName" not
being found.

The reason for this is that in C a const at the global scope has
external linkage by default, while in C++ it has internal linkage.
In other words, in C++

const char* const gName = "Name";

is the same thing as

static const char* const gName = "Name";

while in C it's not. In order to define that variable with external
linkage in C++ you have to say it explicitly:

extern const char* const gName = "Name";

(The same is true for consts inside a namespace. In this case "global scope"
also means "namespace scope".)

[David Brown]

Yes. But this is easily solved by the common practice of declaring any
data that needs external linkage with an "extern" declaration in a
header file, and including that header both from the file that defines
the object, and any file that uses it.

(IMHO both C and C++ should have made internal linkage the default for
all data and functions from the start, and required an explicit "extern"
for external linkage, but it's far too late to fix that!)

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> (IMHO both C and C++ should have made internal linkage the default for
> all data and functions from the start, and required an explicit "extern"
> for external linkage, but it's far too late to fix that!)

I think that there's a slight problem with that in that if you define a
const variable in a header file, if it has internal linkage by default,
it will be duplicated in every compilation unit where it's used (unless
the compiler can "inline" it).

This *is* actually a slight problem in C++, IMO. It's easy to put
something like

namespace MySpace
{
const std::vector<int> values = { 1, 2, 3, 4 };
}

in a header file without realizing that the vector will be duplicated in
all compilation units where it's used, and thus duplicated that many times
in the executable binary (unless the compiler somehow optimizes this).

Of course nowadays we can declare it as 'inline' which solves the problem,
but that has to be explicitly specified, and it needs compiler support.

[Melzzzzz]

What's difference if `inline`?


--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

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

[David Brown]

On 30/04/2020 08:19, Juha Nieminen wrote:
> David Brown <david...@hesbynett.no> wrote:
>> (IMHO both C and C++ should have made internal linkage the default for
>> all data and functions from the start, and required an explicit "extern"
>> for external linkage, but it's far too late to fix that!)
>
> I think that there's a slight problem with that in that if you define a
> const variable in a header file, if it has internal linkage by default,
> it will be duplicated in every compilation unit where it's used (unless
> the compiler can "inline" it).
>

You put const definitions in a header if you are happy to have them
duplicated - if not, you put the definition and initialisation in a
single file and make the "const" external. The C++ "default to static"
rule for const is so that you can easily use "const int noOfThings = 4;"
instead of C-style "#define noOfThings 4". The expectation is that the
const objects defined in a header have less than zero cost - they don't
take up space, they don't require run-time initialisation, and they get
folded into code just like a literal constant.

If you are putting large "const" data in headers, then surely you /know/
that this will may take duplicate space?

It can still be a useful thing that people want to do - hence the trick
of using static members in a template, and then the much nicer step of
adding inline variables to the language.

> This *is* actually a slight problem in C++, IMO. It's easy to put
> something like
>
> namespace MySpace
> {
> const std::vector<int> values = { 1, 2, 3, 4 };
> }
>
> in a header file without realizing that the vector will be duplicated in
> all compilation units where it's used, and thus duplicated that many times
> in the executable binary (unless the compiler somehow optimizes this).

Do people do this sort of thing without realising the consequences?

[Jorgen Grahn]

On Thu, 2020-04-30, David Brown wrote:
> On 30/04/2020 08:19, Juha Nieminen wrote:

...

>> This *is* actually a slight problem in C++, IMO. It's easy to put
>> something like
>>
>> namespace MySpace
>> {
>> const std::vector<int> values = { 1, 2, 3, 4 };
>> }
>>
>> in a header file without realizing that the vector will be duplicated in
>> all compilation units where it's used, and thus duplicated that many times
>> in the executable binary (unless the compiler somehow optimizes this).
>
> Do people do this sort of thing without realising the consequences?

Looks like something I might easily do. I'm weak in this area (but
not weaker than my coworkers, I think).

/Jorgen

[David Brown]

Perhaps it is just that for my type of work, I think about such
efficiencies all the time - and thus don't make that kind of mistake.
(I make other mistakes instead :-) )

[Tim Rentsch]

Juha Nieminen <nos...@thanks.invalid> writes:

> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
>
>> I'm sure you know many of the ways that C code can fail to be
>> valid C++, but probably there are some you haven't thought of.
>> Certainly there are ones I didn't think of until just recently
>> when I ran a piece of C code through a C++ compiler. Some of
>> the obvious problems:
>
> One curious difference between C and C++, which I only learned the
> details of recently, is the difference in semantics of a const

> variable at the global scope. [elaboration]

Right. I did actually think of this one, but it didn't
pop up in my test compiles so I forgot to include it.

[Tim Rentsch]

What I would like to see is for C++ to define how extern "C" blocks
work so that inside extern "C" { ... } what is accepted is C syntax,
and for that part of the source uses C semantics. If this were
done it is then trivial to write C headers that C++ can #include,
and guaranteed that what they do in C++ is the same as what they do
in C. Since it is C++ that wants to include C headers, and not the
other way around, it is C++ that should more of the heavy lifting
needed to get that to happen.

[Tim Rentsch]

Postscript: I wouldn't mind adding a construct in C so that

extern "C" {
...
}

were accepted as C source, with the same effect as leaving off
the enclosing tokens. Surely it is almost no effort to add such
a rule to the language, and it would make writing C++-compatible
headers even easier. This idea, coupled with the suggestion
given in my other posting, is all that is needed to "harmonize"
C and C++ as far as headers are concerned.

[Jorgen Grahn]

That's surely part of it: I work with large and old programs where the
worst inefficiencies are in the I/O, and the other inefficiencies are
lost in the background noise.

(Although in a recent hobby project, I kicked out std::regex when I noticed
it doubled the code segment size.)

> (I make other mistakes instead :-) )

[Keith Thompson]

Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
[...]

> What I would like to see is for C++ to define how extern "C" blocks
> work so that inside extern "C" { ... } what is accepted is C syntax,
> and for that part of the source uses C semantics. If this were
> done it is then trivial to write C headers that C++ can #include,
> and guaranteed that what they do in C++ is the same as what they do
> in C. Since it is C++ that wants to include C headers, and not the
> other way around, it is C++ that should more of the heavy lifting
> needed to get that to happen.

Interesting idea, but I'm not convinced that requiring C++ compilers to
handle
extern "C" {
int *class = malloc(sizeof 'A');
}
would be worth the implementation effort.

[James Kuyper]

Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
[...]

> What I would like to see is for C++ to define how extern "C" blocks
> work so that inside extern "C" { ... } what is accepted is C syntax,
> and for that part of the source uses C semantics. If this were
> done it is then trivial to write C headers that C++ can #include,
> and guaranteed that what they do in C++ is the same as what they do
> in C. Since it is C++ that wants to include C headers, and not the
> other way around, it is C++ that should more of the heavy lifting
> needed to get that to happen.

Interesting - that would turn a popular misconception into reality,
which might qualify as an argument in favor of the idea.

However, code inside an extern "C" {} block has had C++ semantics for at
least as long as those semantics have been different from C semantics
(early versions of C++ were simply "C with classes" - the semantics
weren't very different at that time). As a result, a fair amount of code
has been written that either accidentally or intentionally depends upon
that fact. As a result, such a change would probably break a fair amount
of existing code.

There's another closely related problem. I get the impression that
you're thinking primarily in terms of using extern "C" function
declarations in C++ code to give that C++ code the ability to call
functions implemented in C. However, you're also allowed to provide
extern "C" definitions for C++ functions that are callable from C. I'm
assuming, in particular, that "C semantics" would prohibit calling
functions declared with other language linkages. If that's not the case,
you need to more precisely specify what you mean by "C semantics".

If the C++ standard were modified as you describe, how could such code
be re-written?

[Richard Damon]

On 4/30/20 5:18 PM, Keith Thompson wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
> [...]
>> What I would like to see is for C++ to define how extern "C" blocks
>> work so that inside extern "C" { ... } what is accepted is C syntax,
>> and for that part of the source uses C semantics. If this were
>> done it is then trivial to write C headers that C++ can #include,
>> and guaranteed that what they do in C++ is the same as what they do
>> in C. Since it is C++ that wants to include C headers, and not the
>> other way around, it is C++ that should more of the heavy lifting
>> needed to get that to happen.
>
> Interesting idea, but I'm not convinced that requiring C++ compilers to
> handle
> extern "C" {
> int *class = malloc(sizeof 'A');
> }
> would be worth the implementation effort.
>

Wouldn't that be illegal as C code, as C requires file scope
initializers to be constants, so we never get to the type of 'A';

Now make that

extern "C" {
extern int foo[sizeof 'A'];
}

and you have a different problem.