"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 30 03:12AM +0100
On 29.01.2020 15:47, Bonita Montero wrote:
> x
> PA_i
> Does anyone know how to make gcc more expressive like MSVC?
If you're only interested in understanding the short output of a little
g++ test program, then you can use the `c++filt -t` command.
A clean type name utility needs to clean up not only the g++ result but
also the Visual C++ result, and maybe also other schemes used by other
compilers.
Code for the two mentioned compilers can go like the following, which is
available at <url:
https://github.com/alf-p-steinbach/cppx-core-language/blob/master/source/cppx-core-language/type-checking/type_name_from.hpp>:
#pragma once // Source encoding: UTF-8 with BOM (π is a lowercase
Greek "pi").
#include <cppx-core-language/assert-cpp/is-c++17-or-later.hpp>
#include <cppx-core-language/syntax/collection-util/Sequence_.hpp> //
cppx::Sequence_
#include <cppx-core-language/syntax/types/type-builders.hpp> //
cppx::Type_
#include <cppx-core-language/syntax/declarations.hpp> //
CPPX_USE_...
#include <cppx-core-language/text/ascii-character-util.hpp> //
cppx::ascii::*
#include <cppx-core-language/tmp/Type_carrier_.hpp> //
cppx::Type_carrier_
#include <cppx-core-language/tmp/type-modifiers.hpp> //
cppx::As_referent_
#include <functional> // std::invoke
#include <stdlib.h> // free
#include <string> // std::string
#include <typeinfo> // std::type_info
#include <utility> // std::forward
#ifdef __GNUC__
# include <cxxabi.h>
Bonita Montero <Bonita.Montero@gmail.com>: Jan 29 03:47PM +0100
With this:
#include <iostream>
#include <typeinfo>
using namespace std;
int main()
{
int A, C;
float B;
long long D;
int (*E)[];
cout << typeid(A + B).name() << endl;
cout << typeid(A + C).name() << endl;
cout << typeid(A + D).name() << endl;
cout << typeid(E).name() << endl;
}
... I get ...
float
int
__int64
int (* __ptr64)[0]
... with MSVC.
With g++ I get ...
f
i
x
PA_i
Does anyone know how to make gcc more expressive like MSVC?
| red floyd <no.spam@its.invalid>: Jan 29 06:58AM -0800
On 1/29/20 6:47 AM, Bonita Montero wrote:
> x
> PA_i
> Does anyone know how to make gcc more expressive like MSVC?
You probably can't. The value of std::type_info.name() is
implementation defined.
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 29 03:59PM +0100
>> Does anyone know how to make gcc more expressive like MSVC?
> You probably can't. The value of std::type_info.name() is
> implementation defined.
I know, but probably there's a compiler-switch.
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 29 04:44PM +0100
That's a workaround:
#include <iostream>
#include <typeindex>
#include <typeinfo>
#include <unordered_map>
#include <string>
using namespace std;
int main()
{
unordered_map<type_index, string> typeMappings;
typeMappings[type_index( typeid(char) )] = "char";
typeMappings[type_index( typeid(unsigned char) )] = "unsigned
char";
typeMappings[type_index( typeid(signed char) )] = "signed char";
typeMappings[type_index( typeid(short) )] = "short";
typeMappings[type_index( typeid(unsigned short) )] = "unsigned
short";
typeMappings[type_index( typeid(int) )] = "int";
typeMappings[type_index( typeid(unsigned int) )] = "unsigned
int";
typeMappings[type_index( typeid(long) )] = "long";
typeMappings[type_index( typeid(unsigned long) )] = "unsigned
long";
typeMappings[type_index( typeid(long long) )] = "long long";
typeMappings[type_index( typeid(unsigned long long) )] = "unsigned
long long";
typeMappings[type_index( typeid(float) )] = "float";
typeMappings[type_index( typeid(double) )] = "double";
typeMappings[type_index( typeid(long double) )] = "long double";
int a, c;
float b;
long long d;
cout << typeMappings[type_index( typeid(a + b) )] << endl;
cout << typeMappings[type_index( typeid(a + c) )] << endl;
cout << typeMappings[type_index( typeid(a + d) )] << endl;
}
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 29 04:05PM
>> You probably can't. The value of std::type_info.name() is
>> implementation defined.
> I know, but probably there's a compiler-switch.
I can't remember but there is function to demangle typeid name...
--
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
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 29 04:08PM
>>> implementation defined.
>> I know, but probably there's a compiler-switch.
> I can't remember but there is function to demangle typeid name...
Here it is:
https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html
--
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
| boltar@nowhere.org: Jan 29 05:16PM
On Wed, 29 Jan 2020 15:47:43 +0100
>x
>PA_i
>Does anyone know how to make gcc more expressive like MSVC?
Its compiler dependant so no.
FWIW Clang gives the same output as gcc.
| boltar@nowhere.org: Jan 29 05:17PM
On Wed, 29 Jan 2020 16:44:15 +0100
>That's a workaround:
Not sure you'd define creating a map with the long format as a "workaround" :)
| Juha Nieminen <nospam@thanks.invalid>: Jan 29 07:51AM
>> Crap. "Similiar" mathematical techniques were first published in the
>> 17th century. CORDIC itself wasn't even conceived until the 20th.
> Are you autistic and don't understand emoticons ?
It's a smiley, not an "emoticon" (which would be a picture. No pictures
here).
Anyway, a smiley in such a message is extremely ambiguous. It could
quite well mean that you aren't saying the thing seriously, or it
could also mean that you are mocking the other person. It's impossible
to tell which, from the smiley alone.
Consider, for example, these two sentences:
"That's what she said. ;-)"
"Yeah, whatever you say, pal. And the Moon is made of cheese. ;-)"
One is jestful. The other is mockery. In this case it's clearer which is
which. However, it's not always so clear-cut.
| "Öö Tiib" <ootiib@hot.ee>: Jan 29 12:58AM -0800
On Wednesday, 29 January 2020 09:52:08 UTC+2, Juha Nieminen wrote:
> It's a smiley, not an "emoticon" (which would be a picture. No pictures
> here).
Interesting ... why people do not use emoticons in Usenet? 🤔 😝
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 29 10:34AM +0100
>> Are you autistic and don't understand emoticons ?
> It's a smiley, not an "emoticon" (which would be a picture. No pictures
> here).
https://en.wikipedia.org/wiki/Emoticon#/media/File:Emoticon_Smile_Face.svg
> Anyway, a smiley in such a message is extremely ambiguous.
Maybe for autists, but normal people recognize the meaning,
even more with an additional "hrhr".
|
Robert Wessel <robertwessel2@yahoo.com>: Jan 27 07:37PM -0600
>// endofouterloop:
>the statements will jump to completely different points. The break
>actually goes to an implicit statement after the loop.
I think the slight oddity of target location when the label is used
for both a break/continue and a goto is pretty minor. I suppose we
could come up with some alternative way to specify a "statement name",
but I don't see a big advantage. If we can have a dozen meanings of
static, why not this.
>as it pinpoints exactly where the code will end up next. With loads of
>nested }s floating around, many nothing to do with the loops, the end of
>the desired loop is not always easy to find.
I think that's the wrong principle. If you want to target a specific
location, use a goto. The idea is to break/continue a loop/switch, so
it should be the *loop/switch* that should be identified.
| Robert Wessel <robertwessel2@yahoo.com>: Jan 27 09:06PM -0600
On Sun, 26 Jan 2020 22:15:06 +0100, David Brown
>author). As you say, the context of that paper is different from the
>situation now, and I think we can all agree that spaghetti programming
>is a bad idea.
Let me emphasize, I didn't intend to accuse you of that sort of closed
mindedness, and if it came across that way, I apologize. There are
many people, though, who have heard a rule, and gosh darn it, they're
going to apply it, no matter what. Unfortunately it seems to be
prevalent with people who are in charge of writing and enforcing
coding standards.
That being said, I don't think we're really disagreeing on all that
much.
>or perhaps you need to change the problem.
>I am sure there are some types of coding situations where goto is
>considered a reasonable choice - I just don't meet these situations.
Different people will disagree about issues of style and clarity.
That's inevitable. Take the endless brace-style discussions
(please!).
But if I come work on one of your projects, I'll follow your project's
standards. And perhaps I might struggle a bit in some of the
(occasional) cases where I might consider a goto, or if your standards
for routine length might be a bit shorter than ours, or whatever,
simply because that somewhat changes the idioms I'm used to using
every day.
And if you come work on one of mine, I'll trust you not to run off and
refactor everything that doesn't meet your preferences.
And we can both (good naturedly) grumble about the wrong-headedness of
the other approach at the water cooler.
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 27 07:15PM -0800
> On Mon, 27 Jan 2020 21:38:26 +0000, Bart <bc@freeuk.com> wrote:
[...]
> I think that's the wrong principle. If you want to target a specific
> location, use a goto. The idea is to break/continue a loop/switch, so
> it should be the *loop/switch* that should be identified.
Personally, I like the way Ada does this. You can apply a label to a
loop, and it's the name of the loop ("--" introduces a comment):
OUTER: while condition loop
INNER: while condition loop
-- do stuff
if Done_With_Outer then
exit OUTER; -- "exit" is Ada for "break"
elsif Done_With_Inner then
exit INNER;
end if;
-- do more stuff
end loop INNER;
end loop OUTER;
"exit OUTER" is best thought of as an operation that applies to the loop
named "OUTER" rather than as a branch to a particular location.
Loops that are the targets of goto statements have a different syntax,
one that was designed to stand out:
<<LABEL>>
...
goto LABEL;
On the other hand, Perl does something similar, but uses the same syntax
for loop names and goto labels. This does mean that seeing a named loop
raises the possibility that somewhere there's a goto that targets it,
but that's not much of a problem in practice.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Jan 28 11:45AM +0100
Op 27.jan..2020 om 22:38 schreef Bart:
> as it pinpoints exactly where the code will end up next. With loads of
> nested }s floating around, many nothing to do with the loops, the end of
> the desired loop is not always easy to find.
Maybe, but for a "continue outerloop;" a label at the beginning would be
more appropriate, or even better, inside the loop.
| David Brown <david.brown@hesbynett.no>: Jan 28 01:08PM +0100
On 28/01/2020 04:06, Robert Wessel wrote:
>> is a bad idea.
> Let me emphasize, I didn't intend to accuse you of that sort of closed
> mindedness, and if it came across that way, I apologize.
I didn't think you did accuse me of closed mindedness (other people
have, at times, and they have sometimes done so fairly. I can be rather
rigid in my opinions, or the way I express them). I was just trying to
clarify a little.
> going to apply it, no matter what. Unfortunately it seems to be
> prevalent with people who are in charge of writing and enforcing
> coding standards.
With coding standards, as with any other set of rules, there is always a
balance between having a clear and consistent rule set and having
flexibility. Sometimes the consistency outweighs the details of the
rule, other times the rule might be too strict. Usually in coding
standards it is a good idea to have different levels (you /must/ do
this, and /should/ do that) and to have procedures for breaking the
rules ("should" rules can be broken but you must comment the break in
code, breaks of "must" rules need written permission from the program
manager).
> That being said, I don't think we're really disagreeing on all that
> much.
Agreed. I think we are both against banning "goto" merely because it is
trendy to hate it, or because Djikstra wrote a paper against it. We are
both looking for ways to write the code in a clear, logical and
maintainable fashion, and we are both expecting to use good tools and
newer language standards in order to get that without a cost in
efficiency. We just disagree a little on when "goto" might boost code
clarity, and when it is a detriment - and that is likely to be from
different experiences and different types of code.
> Different people will disagree about issues of style and clarity.
> That's inevitable. Take the endless brace-style discussions
> (please!).
Yes. There is one correct way, that I use, and a number of wrong ways
that some other people use :-)
> every day.
> And if you come work on one of mine, I'll trust you not to run off and
> refactor everything that doesn't meet your preferences.
Indeed. Consistency is very important.
There are times when a big refactoring is appropriate, but you need good
reason for it - changing brace style, for example, is not such a reason.
> And we can both (good naturedly) grumble about the wrong-headedness of
> the other approach at the water cooler.
Yes - and I view c.l.c. and c.l.c++ as virtual water coolers!
|
aminer68@gmail.com: Jan 27 10:56AM -0800
Hello,
Priority Queueing Simulation
A round-robin queuing scheduler allows tasks to
have equal access to the processor. The addition of
priority levels allows more important tasks to be
completed first. However this scenario could result in
lower level tasks never gaining access to the
processor. This situation is known as starvation.
Here is two Strategies to Prevent Starvation:
Read more here:
https://www.nku.edu/~mcguffeej1/Franzen_poster.pdf
Thank you,
Amine Moulay Ramdane.
| Wisdom90 <d@d.d>: Jan 27 12:15PM -0500
Hello,
About Java and Delphi and Freepascal..
I have just read the following webpage:
Java is not a safe language
https://lemire.me/blog/2019/03/28/java-is-not-a-safe-language/
But as you have noticed the webpage says:
- Java does not trap overflows
But Delphi and Freepascal do trap overflows.
And the webpage says:
- Java lacks null safety
But Delphi has null safety since i have just posted about it by saying
the following:
Here is MyNullable library for Delphi and FreePascal that brings null
safety..
Java lacks null safety. When a function receives an object, this object
might be null. That is, if you see 'String s' in your code, you often
have no way of knowing whether 's' contains an actually String unless
you check at runtime. Can you guess whether programmers always check?
They do not, of course, In practice, mission-critical software does
crash without warning due to null values. We have two decades of
examples. In Swift or Kotlin, you have safe calls or optionals as part
of the language.
Here is MyNullable library for Delphi and FreePascal that brings null
safety, you can read the html file inside the zip to know how it works,
and you can download it from my website here:
https://sites.google.com/site/scalable68/null-safety-library-for-delphi-and-freepascal
And the webpage says:
- Java allows data races
But for Delphi and Freepascal i have just written about how to prevent
data races by saying the following:
Yet more precision about the invariants of a system..
I was just thinking about Petri nets , and i have studied more
Petri nets, they are useful for parallel programming, and
what i have noticed by studying them, is that there is two methods
to prove that there is no deadlock in the system, there is the
structural analysis with place invariants that you have to
mathematically find, or you can use the reachability tree, but we have
to notice that the structural analysis of Petri nets learns you more,
because it permits you to prove that there is no deadlock in the system,
and the place invariants are mathematically calculated by the following
system of the given Petri net:
Transpose(vector) * Incidence matrix = 0
So you apply the Gaussian Elimination or the Farkas algorithm to
the incidence matrix to find the Place invariants, and as you will
notice those place invariants calculations of the Petri nets look
like Markov chains in mathematics, with there vector of probabilities
and there transition matrix of probabilities, and you can, using
Markov chains mathematically calculate where the vector of probabilities
will "stabilize", and it gives you a very important information, and
you can do it by solving the following mathematical system:
Unknown vector1 of probabilities * transition matrix of probabilities =
Unknown vector1 of probabilities.
Solving this system of equations is very important in economics and
other fields, and you can notice that it is like calculating the
invariants , because the invariant in the system above is the
vector1 of probabilities that is obtained, and this invariant,
like in the invariants of the structural analysis of Petri nets,
gives you a very important information about the system, like where
market shares will stabilize that is calculated this way in economics.
About reachability analysis of a Petri net..
As you have noticed in my Petri nets tutorial example (read below),
i am analysing the liveness of the Petri net, because there is a rule
that says:
If a Petri net is live, that means that it is deadlock-free.
Because reachability analysis of a Petri net with Tina
gives you the necessary information about boundedness and liveness
of the Petri net. So if it gives you that the Petri net is "live" , so
there is no deadlock in it.
Tina and Partial order reduction techniques..
With the advancement of computer technology, highly concurrent systems
are being developed. The verification of such systems is a challenging
task, as their state space grows exponentially with the number of
processes. Partial order reduction is an effective technique to address
this problem. It relies on the observation that the effect of executing
transitions concurrently is often independent of their ordering.
Tina is using "partial-order" reduction techniques aimed at preventing
combinatorial explosion, Read more here to notice it:
http://projects.laas.fr/tina/papers/qest06.pdf
About modelizations and detection of race conditions and deadlocks
in parallel programming..
I have just taken further a look at the following project in Delphi
called DelphiConcurrent by an engineer called Moualek Adlene from France:
https://github.com/moualek-adlene/DelphiConcurrent/blob/master/DelphiConcurrent.pas
And i have just taken a look at the following webpage of Dr Dobb's journal:
Detecting Deadlocks in C++ Using a Locks Monitor
https://www.drdobbs.com/detecting-deadlocks-in-c-using-a-locks-m/184416644
And i think that both of them are using technics that are not as good
as analysing deadlocks with Petri Nets in parallel applications ,
for example the above two methods are only addressing locks or mutexes
or reader-writer locks , but they are not addressing semaphores
or event objects and such other synchronization objects, so they
are not good, this is why i have written a tutorial that shows my
methodology of analysing and detecting deadlocks in parallel
applications with Petri Nets, my methodology is more sophisticated
because it is a generalization and it modelizes with Petri Nets the
broader range of synchronization objects, and in my tutorial i will add
soon other synchronization objects, you have to look at it, here it is:
https://sites.google.com/site/scalable68/how-to-analyse-parallel-applications-with-petri-nets
You have to get the powerful Tina software to run my Petri Net examples
inside my tutorial, here is the powerful Tina software:
http://projects.laas.fr/tina/
Also to detect race conditions in parallel programming you have to take
a look at the following new tutorial that uses the powerful Spin tool:
https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
This is how you will get much more professional at detecting deadlocks
and race conditions in parallel programming.
And about memory safety of Delphi and Freepascal, here is what i said:
I have just read the following webpage about memory safety:
Microsoft: 70 percent of all security bugs are memory safety issues
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
And it says:
"Users who often read vulnerability reports come across terms over and
over again. Terms like buffer overflow, race condition, page fault, null
pointer, stack exhaustion, heap exhaustion/corruption, use after free,
or double free --all describe memory safety vulnerabilities."
So as you will notice below, that the following memory safety problems
has been solved in Delphi:
And I have just read the following webpage about "Fearless Security:
Memory safety":
https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/
Here is the memory safety problems:
1- Misusing Free (use-after-free, double free)
I have solved this in Delphi and Freepascal by inventing a "Scalable"
reference counting with efficient support for weak references. Read
below about it.
2- Uninitialized variables
This can be detected by the compilers of Delphi and Freepascal.
3- Dereferencing Null pointers
I have solved this in Delphi and Freepascal by inventing a "Scalable"
reference counting with efficient support for weak references. Read
below about it.
4- Buffer overflow and underflow
This has been solved in Delphi by using madExcept, read here about it:
http://help.madshi.net/DebugMm.htm
You can buy it from here:
http://www.madshi.net/
There remains also the stack exhaustion memory safety problem,
and here is how to detect it in Delphi:
Call the function "DoStackOverflow" below once from your code and you'll
get the EStackOverflow error raised by Delphi with the message "stack
overflow", and you can print the line of the source code where
EStackOverflow is raised with JCLDebug and such:
----
function DoStackOverflow : integer;
begin
result := 1 + DoStackOverflow;
end;
---
About my scalable algorithms inventions..
I am a white arab, and i am a gentleman type of person,
and i think that you know me too by my poetry that i wrote
in front of you and that i posted here, but i am
also a more serious computer developer, and i am also
an inventor who has invented many scalable algorithms, read about
them on my writing below:
Here is my last scalable algorithm invention, read
what i have just responded in comp.programming.threads:
About my LRU scalable algorithm..
On 10/16/2019 7:48 AM, Bonita Montero on comp.programming.threads wrote:
> in locked mode in very rare cases. And as I said inserting and
> flushing is conventional locked access.
> So the quest is for you: Can you guess what I did?
And here is what i have just responded:
I think i am also smart, so i have just quickly found a solution that is
scalable and that is not your solution, so it needs my hashtable that is
scalable and it needs my fully scalable FIFO queue that i have invented.
And i think i will not patent it. But my solution is not Lockfree, it
uses locks like in a Lock striping manner and it is scalable.
And read about my other scalable algorithms inventions on my writing below:
About the buffer overflow problem..
I wrote yesterday about buffer overflow in Delphi and Freepascal..
I think there is a "higher" abstraction in Delphi and Freepascal
that does the job very well of avoiding buffer overflow, and it is
the TMemoryStream class, since it behaves also like a pointer
and it supports reallocmem() and freemem() on the pointer but
with a higher level abstraction, look for example at my
following example in Delphi and Freepascal, you will notice
that contrary to pointers , that the memory stream is adapting with
writebuffer() without the need of reserving the memory, and this is why
it avoids the buffer overflow problem, read the following example to
notice how i am using it with a PAnsichar type:
========================================
Program test;
uses system.classes,system.sysutils;
var P: PAnsiChar;
Begin
P:='Amine';
mem:=TMemorystream.create;
mem.position:=0;
mem.writebuffer(pointer(p)^,6);
mem.position:=0;
writeln(PAnsichar(mem.memory));
end.
===================================
So since Delphi and Freepascal also detect the buffer overflow on
dynamic arrays , so i think that Delphi and Freepascal are powerful
tools.
Read my previous thoughts below to understand more:
And I have just read the following webpage about "Fearless Security:
Memory safety":
https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/
Here is the memory safety problems:
1- Misusing Free (use-after-free, double free)
I have solved this in Delphi and Freepascal by inventing a "Scalable"
reference counting with efficient support for weak references. Read
below about it.
2- Uninitialized variables
This can be detected by the compilers of Delphi and Freepascal.
3- Dereferencing Null pointers
I have solved this in Delphi and Freepascal by inventing a "Scalable"
reference counting with efficient support for weak references. Read
below about it.
4- Buffer overflow and underflow
This has been solved in Delphi by using madExcept, read here about it:
http://help.madshi.net/DebugMm.htm
You can buy it from here:
http://www.madshi.net/
And about race conditions and deadlocks problems and more, read my
following thoughts to understand:
I will reformulate more smartly what about race conditions detection in
Rust, so read it carefully:
You can think of the borrow checker of Rust as a validator for a locking
system: immutable references are shared read locks and mutable
references are exclusive write locks. Under this mental model, accessing
data via two independent write locks is not a safe thing to do, and
modifying data via a write lock while there are readers alive is not
safe either.
So as you are noticing that the "mutable" references in Rust follow the
Read-Write Lock pattern, so this is not good, because it is not like
more fine-grained parallelism that permits us to run the writes in
"parallel" and gain more performance from parallelizing the writes.
Read more about Rust and Delphi and my inventions..
I think the spirit of Rust is like the spirit of ADA, they are
especially designed for the very high standards of safety, like those
of ADA, "but" i don't think we have to fear race conditions that Rust
solve, because i think that race conditions are not so difficult to
avoid when you are a decent knowledgeable programmer in parallel
programming, so you have to understand what i mean, now we have to talk
about the rest of the safety guaranties of Rust, there remain the
problem of Deadlocks, and i think that Rust is not solving this problem,
but i have provided you with an enhanced DelphiConcurrent library for
Delphi and Freepascal that detects deadlocks, and there is also the
Memory Safety guaranties of Rust, here they are:
1- No Null Pointer Dereferences
2- No Dangling Pointers
3- No Buffer Overruns
But notice that I have solved the number 1 and number 2 by inventing my
scalable reference counting with efficient support for weak references
for Delphi and Freepascal, read below to notice it, and for number 3
read my following thoughts to understand:
More about research and software development..
I have just looked at the following new video:
Why is coding so hard...
https://www.youtube.com/watch?v=TAAXwrgd1U8
I am understanding this video, but i have to explain my work:
I am not like this techlead in the video above, because i am also an
"inventor" that has invented many scalable algorithms and there
implementions, i am also inventing effective abstractions, i give you an
example:
Read the following of the senior research scientist that is called Dave
Dice:
Preemption tolerant MCS locks
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
As you are noticing he is trying to invent a new lock that is preemption
tolerant, but his lock lacks some important characteristics, this is why
i have just invented a new Fast Mutex that is adaptative and that is
much much better and i think mine is the "best", and i think you will
not find it anywhere, my new Fast Mutex has the following characteristics:
1- Starvation-free
2- Good fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance (it has the same performance as the
scalable MCS lock when there is contention.)
5- And it has a decent preemption tolerance.
this is how i am an "inventor", and i have also invented other scalable
algorithms such as a scalable reference counting with efficient support
for weak references, and i have invented a fully scalable Threadpool,
and i have also invented a Fully scalable FIFO queue, and i have also
invented other scalable algorithms and there inmplementations, and i
think i will sell some of them to Microsoft or to
Google or Embarcadero or such software companies.
Read my following writing to know me more:
More about computing and parallel computing..
The important guaranties of Memory Safety in Rust are:
| aminer68@gmail.com: Jan 27 09:16AM -0800
Hello,
About Java and Delphi and Freepascal..
I have just read the following webpage:
Java is not a safe language
https://lemire.me/blog/2019/03/28/java-is-not-a-safe-language/
But as you have noticed the webpage says:
- Java does not trap overflows
But Delphi and Freepascal do trap overflows.
And the webpage says:
- Java lacks null safety
But Delphi has null safety since i have just posted about it by saying the following:
Here is MyNullable library for Delphi and FreePascal that brings null safety..
Java lacks null safety. When a function receives an object, this object might be null. That is, if you see 'String s' in your code, you often have no way of knowing whether 's' contains an actually String unless you check at runtime. Can you guess whether programmers always check? They do not, of course, In practice, mission-critical software does crash without warning due to null values. We have two decades of examples. In Swift or Kotlin, you have safe calls or optionals as part of the language.
Here is MyNullable library for Delphi and FreePascal that brings null safety, you can read the html file inside the zip to know how it works, and you can download it from my website here:
https://sites.google.com/site/scalable68/null-safety-library-for-delphi-and-freepascal
And the webpage says:
- Java allows data races
But for Delphi and Freepascal i have just written about how to prevent data races by saying the following:
Yet more precision about the invariants of a system..
I was just thinking about Petri nets , and i have studied more
Petri nets, they are useful for parallel programming, and
what i have noticed by studying them, is that there is two methods
to prove that there is no deadlock in the system, there is the
structural analysis with place invariants that you have to mathematically find, or you can use the reachability tree, but we have to notice that the structural analysis of Petri nets learns you more, because it permits you to prove that there is no deadlock in the system, and the place invariants are mathematically calculated by the following
system of the given Petri net:
Transpose(vector) * Incidence matrix = 0
So you apply the Gaussian Elimination or the Farkas algorithm to
the incidence matrix to find the Place invariants, and as you will
notice those place invariants calculations of the Petri nets look
like Markov chains in mathematics, with there vector of probabilities
and there transition matrix of probabilities, and you can, using
Markov chains mathematically calculate where the vector of probabilities
will "stabilize", and it gives you a very important information, and
you can do it by solving the following mathematical system:
Unknown vector1 of probabilities * transition matrix of probabilities = Unknown vector1 of probabilities.
Solving this system of equations is very important in economics and
other fields, and you can notice that it is like calculating the
invariants , because the invariant in the system above is the
vector1 of probabilities that is obtained, and this invariant,
like in the invariants of the structural analysis of Petri nets,
gives you a very important information about the system, like where
market shares will stabilize that is calculated this way in economics.
About reachability analysis of a Petri net..
As you have noticed in my Petri nets tutorial example (read below),
i am analysing the liveness of the Petri net, because there is a rule
that says:
If a Petri net is live, that means that it is deadlock-free.
Because reachability analysis of a Petri net with Tina
gives you the necessary information about boundedness and liveness
of the Petri net. So if it gives you that the Petri net is "live" , so
there is no deadlock in it.
Tina and Partial order reduction techniques..
With the advancement of computer technology, highly concurrent systems
are being developed. The verification of such systems is a challenging
task, as their state space grows exponentially with the number of processes. Partial order reduction is an effective technique to address this problem. It relies on the observation that the effect of executing transitions concurrently is often independent of their ordering.
Tina is using "partial-order" reduction techniques aimed at preventing
combinatorial explosion, Read more here to notice it:
http://projects.laas.fr/tina/papers/qest06.pdf
About modelizations and detection of race conditions and deadlocks
in parallel programming..
I have just taken further a look at the following project in Delphi
called DelphiConcurrent by an engineer called Moualek Adlene from France:
https://github.com/moualek-adlene/DelphiConcurrent/blob/master/DelphiConcurrent.pas
And i have just taken a look at the following webpage of Dr Dobb's journal:
Detecting Deadlocks in C++ Using a Locks Monitor
https://www.drdobbs.com/detecting-deadlocks-in-c-using-a-locks-m/184416644
And i think that both of them are using technics that are not as good
as analysing deadlocks with Petri Nets in parallel applications ,
for example the above two methods are only addressing locks or mutexes
or reader-writer locks , but they are not addressing semaphores
or event objects and such other synchronization objects, so they
are not good, this is why i have written a tutorial that shows my
methodology of analysing and detecting deadlocks in parallel applications with Petri Nets, my methodology is more sophisticated because it is a generalization and it modelizes with Petri Nets the broader range of synchronization objects, and in my tutorial i will add soon other synchronization objects, you have to look at it, here it is:
https://sites.google.com/site/scalable68/how-to-analyse-parallel-applications-with-petri-nets
You have to get the powerful Tina software to run my Petri Net examples
inside my tutorial, here is the powerful Tina software:
http://projects.laas.fr/tina/
Also to detect race conditions in parallel programming you have to take
a look at the following new tutorial that uses the powerful Spin tool:
https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
This is how you will get much more professional at detecting deadlocks
and race conditions in parallel programming.
And about memory safety of Delphi and Freepascal, here is what i said:
I have just read the following webpage about memory safety:
Microsoft: 70 percent of all security bugs are memory safety issues
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
And it says:
"Users who often read vulnerability reports come across terms over and over again. Terms like buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free --all describe memory safety vulnerabilities."
So as you will notice below, that the following memory safety problems has been solved in Delphi:
And I have just read the following webpage about "Fearless Security: Memory safety":
https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/
Here is the memory safety problems:
1- Misusing Free (use-after-free, double free)
I have solved this in Delphi and Freepascal by inventing a "Scalable" reference counting with efficient support for weak references. Read below about it.
2- Uninitialized variables
This can be detected by the compilers of Delphi and Freepascal.
3- Dereferencing Null pointers
I have solved this in Delphi and Freepascal by inventing a "Scalable" reference counting with efficient support for weak references. Read below about it.
4- Buffer overflow and underflow
This has been solved in Delphi by using madExcept, read here about it:
http://help.madshi.net/DebugMm.htm
You can buy it from here:
http://www.madshi.net/
There remains also the stack exhaustion memory safety problem,
and here is how to detect it in Delphi:
Call the function "DoStackOverflow" below once from your code and you'll get the EStackOverflow error raised by Delphi with the message "stack overflow", and you can print the line of the source code where EStackOverflow is raised with JCLDebug and such:
----
function DoStackOverflow : integer;
begin
result := 1 + DoStackOverflow;
end;
---
About my scalable algorithms inventions..
I am a white arab, and i am a gentleman type of person,
and i think that you know me too by my poetry that i wrote
in front of you and that i posted here, but i am
also a more serious computer developer, and i am also
an inventor who has invented many scalable algorithms, read about
them on my writing below:
Here is my last scalable algorithm invention, read
what i have just responded in comp.programming.threads:
About my LRU scalable algorithm..
On 10/16/2019 7:48 AM, Bonita Montero on comp.programming.threads wrote:
> in locked mode in very rare cases. And as I said inserting and
> flushing is conventional locked access.
> So the quest is for you: Can you guess what I did?
And here is what i have just responded:
I think i am also smart, so i have just quickly found a solution that is scalable and that is not your solution, so it needs my hashtable that is scalable and it needs my fully scalable FIFO queue that i have invented. And i think i will not patent it. But my solution is not Lockfree, it uses locks like in a Lock striping manner and it is scalable.
And read about my other scalable algorithms inventions on my writing below:
About the buffer overflow problem..
I wrote yesterday about buffer overflow in Delphi and Freepascal..
I think there is a "higher" abstraction in Delphi and Freepascal
that does the job very well of avoiding buffer overflow, and it is
the TMemoryStream class, since it behaves also like a pointer
and it supports reallocmem() and freemem() on the pointer but
with a higher level abstraction, look for example at my
following example in Delphi and Freepascal, you will notice
that contrary to pointers , that the memory stream is adapting with writebuffer() without the need of reserving the memory, and this is why it avoids the buffer overflow problem, read the following example to notice how i am using it with a PAnsichar type:
========================================
Program test;
uses system.classes,system.sysutils;
var P: PAnsiChar;
Begin
P:='Amine';
mem:=TMemorystream.create;
mem.position:=0;
mem.writebuffer(pointer(p)^,6);
mem.position:=0;
writeln(PAnsichar(mem.memory));
end.
===================================
So since Delphi and Freepascal also detect the buffer overflow on dynamic arrays , so i think that Delphi and Freepascal are powerful
tools.
Read my previous thoughts below to understand more:
And I have just read the following webpage about "Fearless Security: Memory safety":
https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/
Here is the memory safety problems:
1- Misusing Free (use-after-free, double free)
I have solved this in Delphi and Freepascal by inventing a "Scalable" reference counting with efficient support for weak references. Read below about it.
2- Uninitialized variables
This can be detected by the compilers of Delphi and Freepascal.
3- Dereferencing Null pointers
I have solved this in Delphi and Freepascal by inventing a "Scalable" reference counting with efficient support for weak references. Read below about it.
4- Buffer overflow and underflow
This has been solved in Delphi by using madExcept, read here about it:
http://help.madshi.net/DebugMm.htm
You can buy it from here:
http://www.madshi.net/
And about race conditions and deadlocks problems and more, read my following thoughts to understand:
I will reformulate more smartly what about race conditions detection in Rust, so read it carefully:
You can think of the borrow checker of Rust as a validator for a locking system: immutable references are shared read locks and mutable references are exclusive write locks. Under this mental model, accessing data via two independent write locks is not a safe thing to do, and modifying data via a write lock while there are readers alive is not safe either.
So as you are noticing that the "mutable" references in Rust follow the Read-Write Lock pattern, so this is not good, because it is not like more fine-grained parallelism that permits us to run the writes in "parallel" and gain more performance from parallelizing the writes.
Read more about Rust and Delphi and my inventions..
I think the spirit of Rust is like the spirit of ADA, they are especially designed for the very high standards of safety, like those of ADA, "but" i don't think we have to fear race conditions that Rust solve, because i think that race conditions are not so difficult to avoid when you are a decent knowledgeable programmer in parallel programming, so you have to understand what i mean, now we have to talk about the rest of the safety guaranties of Rust, there remain the problem of Deadlocks, and i think that Rust is not solving this problem, but i have provided you with an enhanced DelphiConcurrent library for Delphi and Freepascal that detects deadlocks, and there is also the Memory Safety guaranties of Rust, here they are:
1- No Null Pointer Dereferences
2- No Dangling Pointers
3- No Buffer Overruns
But notice that I have solved the number 1 and number 2 by inventing my
scalable reference counting with efficient support for weak references
for Delphi and Freepascal, read below to notice it, and for number 3 read my following thoughts to understand:
More about research and software development..
I have just looked at the following new video:
Why is coding so hard...
https://www.youtube.com/watch?v=TAAXwrgd1U8
I am understanding this video, but i have to explain my work:
I am not like this techlead in the video above, because i am also an "inventor" that has invented many scalable algorithms and there implementions, i am also inventing effective abstractions, i give you an example:
Read the following of the senior research scientist that is called Dave Dice:
Preemption tolerant MCS locks
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
As you are noticing he is trying to invent a new lock that is preemption tolerant, but his lock lacks some important characteristics, this is why i have just invented a new Fast Mutex that is adaptative and that is much much better and i think mine is the "best", and i think you will not find it anywhere, my new Fast Mutex has the following characteristics:
1- Starvation-free
2- Good fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance (it has the same performance as the
scalable MCS lock when there is contention.)
5- And it has a decent preemption tolerance.
this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support for weak references, and i have invented a fully scalable Threadpool, and i have also invented a Fully scalable FIFO queue, and i have also invented other scalable algorithms and there inmplementations, and i think i will sell some of them to Microsoft or to
Google or Embarcadero or such software companies.
Read my following writing to know me more:
More about computing and parallel computing..
The important guaranties of Memory Safety in Rust are:
1- No Null Pointer Dereferences
2- No Dangling Pointers
3- No Buffer Overruns
I think i have solved Null Pointer Dereferences and also solved | Bonita Montero <Bonita.Montero@gmail.com>: Jan 27 06:49PM +0100
> About my LRU scalable algorithm..
Your LRU-algorithm ? Where is it ?
>> So the quest is for you: Can you guess what I did?
> And here is what i have just responded:
> I think i am also smart, ...
Then show me your LRU-code.
| aminer68@gmail.com: Jan 27 05:49AM -0800
Hello,
Yet more precision about the invariants of a system..
I was just thinking about Petri nets , and i have studied more
Petri nets, they are useful for parallel programming, and
what i have noticed by studying them, is that there is two methods
to prove that there is no deadlock in the system, there is the
structural analysis with place invariants that you have to mathematically find, or you can use the reachability tree, but we have to notice that the structural analysis of Petri nets learns you more, because it permits you to prove that there is no deadlock in the system, and the place invariants are mathematically calculated by the following
system of the given Petri net:
Transpose(vector) * Incidence matrix = 0
So you apply the Gaussian Elimination or the Farkas algorithm to
the incidence matrix to find the Place invariants, and as you will
notice those place invariants calculations of the Petri nets look
like Markov chains in mathematics, with there vector of probabilities
and there transition matrix of probabilities, and you can, using
Markov chains mathematically calculate where the vector of probabilities
will "stabilize", and it gives you a very important information, and
you can do it by solving the following mathematical system:
Unknown vector1 of probabilities * transition matrix of probabilities = Unknown vector1 of probabilities.
Solving this system of equations is very important in economics and
other fields, and you can notice that it is like calculating the
invariants , because the invariant in the system above is the
vector1 of probabilities that is obtained, and this invariant,
like in the invariants of the structural analysis of Petri nets,
gives you a very important information about the system, like where
market shares will stabilize that is calculated this way in economics.
About reachability analysis of a Petri net..
As you have noticed in my Petri nets tutorial example (read below),
i am analysing the liveness of the Petri net, because there is a rule
that says:
If a Petri net is live, that means that it is deadlock-free.
Because reachability analysis of a Petri net with Tina
gives you the necessary information about boundedness and liveness
of the Petri net. So if it gives you that the Petri net is "live" , so
there is no deadlock in it.
Tina and Partial order reduction techniques..
With the advancement of computer technology, highly concurrent systems
are being developed. The verification of such systems is a challenging
task, as their state space grows exponentially with the number of processes. Partial order reduction is an effective technique to address this problem. It relies on the observation that the effect of executing transitions concurrently is often independent of their ordering.
Tina is using "partial-order" reduction techniques aimed at preventing
combinatorial explosion, Read more here to notice it:
http://projects.laas.fr/tina/papers/qest06.pdf
About modelizations and detection of race conditions and deadlocks
in parallel programming..
I have just taken further a look at the following project in Delphi
called DelphiConcurrent by an engineer called Moualek Adlene from France:
https://github.com/moualek-adlene/DelphiConcurrent/blob/master/DelphiConcurrent.pas
And i have just taken a look at the following webpage of Dr Dobb's journal:
Detecting Deadlocks in C++ Using a Locks Monitor
https://www.drdobbs.com/detecting-deadlocks-in-c-using-a-locks-m/184416644
And i think that both of them are using technics that are not as good
as analysing deadlocks with Petri Nets in parallel applications ,
for example the above two methods are only addressing locks or mutexes
or reader-writer locks , but they are not addressing semaphores
or event objects and such other synchronization objects, so they
are not good, this is why i have written a tutorial that shows my
methodology of analysing and detecting deadlocks in parallel applications with Petri Nets, my methodology is more sophisticated because it is a generalization and it modelizes with Petri Nets the broader range of synchronization objects, and in my tutorial i will add soon other synchronization objects, you have to look at it, here it is:
https://sites.google.com/site/scalable68/how-to-analyse-parallel-applications-with-petri-nets
You have to get the powerful Tina software to run my Petri Net examples
inside my tutorial, here is the powerful Tina software:
http://projects.laas.fr/tina/
Also to detect race conditions in parallel programming you have to take
a look at the following new tutorial that uses the powerful Spin tool:
https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
This is how you will get much more professional at detecting deadlocks
and race conditions in parallel programming.
Thank you,
Amine Moulay Ramdane.
|
|
