Thursday, June 15, 2023

Digest for comp.lang.c++@googlegroups.com - 20 updates in 6 topics

David Brown <david.brown@hesbynett.no>: Jun 15 10:02AM +0200

On 15/06/2023 00:27, James Kuyper wrote:
> the code to be inefficient, but to actually malfunction. On such a
> platform, if p_bytes is not correctly aligned to store a uint64_t, then
> the code will malfunction in the reinterpret_cast<>.
 
And in case anyone has doubts, such platforms do exist. I have used
embedded microcontrollers in which an unaligned access might mean access
to the address rounded down (i.e., a 16-bit store to 0x2001 actually
stores 16 bits at 0x2000). The stored data may or may not be
byte-swapped - the behaviour is undefined, and I don't think it was
consistent between different generations of the processor.
 
There are also big processors which will fault on unaligned accesses.
Even if there are OS services in place to simulate the access, the
process is so massively slower than normal accesses that it could be
considered a software malfunction for performance critical code.
David Brown <david.brown@hesbynett.no>: Jun 15 10:06AM +0200

On 14/06/2023 21:46, Alf P. Steinbach wrote:
 
> So for the separately compiled function it does not matter technically,
> except possibly for performance, whether it uses clear, concise, safe
> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
 
Code that relies on limited optimisation or separate compilation for
correct behaviour, is an extremely bad idea - it is fragile and a hidden
bug waiting to explode in the future. Shortcuts now will cost dearly
later on. Take pride in your work, and code responsibly - do what you
can to make your code /correct/, rather than relying on weak tools!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 15 01:50AM -0700

On 6/14/2023 4:01 PM, Chris M. Thomasson wrote:
> [...]
 
> What about some code that crosses a L2 cache line boundary and causes
> the damn processor to assert a bus lock... Argh!
 
CMPXCHG on an address that points to data that straddles a l2 cache line
should do it... I cannot remember for sure if the LOCK prefix _has_ to
be present here... Cannot remember right that detail right now, damn!
Fwiw, XCHG should assert bus lock as well wrt the "bad" location, and
LOCK is automatically implied in XCHG to begin with.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 15 01:55AM -0700

On 6/15/2023 1:50 AM, Chris M. Thomasson wrote:
> be present here... Cannot remember right that detail right now, damn!
> Fwiw, XCHG should assert bus lock as well wrt the "bad" location, and
> LOCK is automatically implied in XCHG to begin with.
 
I also cannot remember if it only asserts the bus lock when there is
"contention" on a LOCK'ed atomic RMW using an address that goes to data
that straddles a l2 cache line on Intel. Its been a while since I have
worked with raw x86 asm. I am sure some of my work is up on the way back
machine. Let me check...
 
I found some of my old asm work!
 
This is MASM:
 
http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html
 
This should be GAS:
 
http://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html
 
;^)
Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 12:06PM +0200

Am 14.06.2023 um 23:28 schrieb David Brown:
 
>> but not in C++.
 
> <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>
> <https://en.cppreference.com/w/cpp/types/byte>
 
There never will be an upcoming CPU where CHAR_BIT is not eight.
Even Posix requires that.
 
 
> Finally you have managed to check it, ...
 
I've checked it long before the posting of you before.
 
> No, it is still the wrong type regardless of the memory flatness.
 
You're paranoid.
David Brown <david.brown@hesbynett.no>: Jun 15 03:05PM +0200

On 15/06/2023 12:06, Bonita Montero wrote:
>> <https://en.cppreference.com/w/cpp/types/byte>
 
> There never will be an upcoming CPU where CHAR_BIT is not eight.
> Even Posix requires that.
 
To the nearest percent, 0% of all cpus shipped are used in POSIX systems.
 
CPUs are made all the time that don't have 8-bit char. Just because you
have a limited view, does not mean C, C++ or all other programmers do so.
 
Of course, none of that matters in the slightest here - nothing about
std::byte, type aliasing, or accessing via char types relies on char
being 8-bit.
 
 
> > Finally you have managed to check it, ...
 
> I've checked it long before the posting of you before.
 
Either you are lying in an attempt to look less incompetent, or you are
incompetent, or you wrote a poorly considered "optimisation" that
doesn't work at all in a major use-case and were so proud of your
half-arsed solution that you hoped no one would notice.
 
>> No, it is still the wrong type regardless of the memory flatness.
 
> You're paranoid.
 
No, understanding the point of basic language types is not paranoia.
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Jun 15 06:28AM -0700

On Wednesday, June 14, 2023 at 11:26:01 AM UTC-4, Bonita Montero wrote:
...
> In C you can alias anything as a char array and a char array as
> anything so it would be safe to alias anything as anything with
> double-casting (I guess that's correctly supported by the compilers).
 
C's anti-alasing rules are asymmetric. It distinguishes between the effective type of a object (which is the same as it'declared type, if it has one) and the typeof the league used to access it. Aliasing an object with an effect8ve type of uint64_t using an lvalue of character type is allowed by the following clause:
 
"An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
...
- a character type" (6.5p7)
 
Accessing an object with an effective type that is a character type (or an array thereof) using an lvalue with a type of uint64_t is not allowed by any of the cases listed in that paragraph unless they are members of the same union, (or if uint64_t is a character type, which is pretty unlikely, but permitted).
Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 03:35PM +0200

Am 15.06.2023 um 15:05 schrieb David Brown:
 
> To the nearest percent, 0% of all cpus shipped are used in POSIX systems.
 
> CPUs are made all the time that don't have 8-bit char.  Just because you
> have a limited view, does not mean C, C++ or all other programmers do so.
 
CPUs with CHAR_BIT != 8 are rare and there won't be any further
in the future.
 
 
>>  > Finally you have managed to check it, ...
 
>> I've checked it long before the posting of you before.
 
> Either you are lying in an attempt to look less incompetent, ...
 
I checked it, you didn't.
 
 
>>> No, it is still the wrong type regardless of the memory flatness.
 
>> You're paranoid.
 
> No, understanding the point of basic language types is not paranoia.
 
I would never run into problems with that.
Your opinion is compulsive.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 03:42PM +0200

> ...
> - a character type" (6.5p7)
 
> Accessing an object with an effective type that is a character type (or an array thereof) using an lvalue with a type of uint64_t is not allowed by any of the cases listed in that paragraph unless they are members of the same union, (or if uint64_t is a character type, which is pretty unlikely, but permitted).
 
In C you can alias anything as a char-array and a a char-array as
anything. And you can alias signed, defaulted (char) or unsigned
entities as their counterparts. That's all.
Since aliasing with a union is very common all compiler support
that, although there's no guarantee from the standard for that.
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Jun 15 07:38AM -0700

On Thursday, June 15, 2023 at 9:43:04 AM UTC-4, Bonita Montero wrote:
> In C you can alias anything as a char-array and a a char-array as
> anything. And you can alias signed, defaulted (char) or unsigned
> entities as their counterparts. That's all.
 
Citation, please?
6,5p7 is a complete and exhaustive list of the situations where an object can be accessed with defined behaviorusing an lvaue with a type that is different from the effective type of that object. It starts with a "shall", so violations have undefined behavior. Please identify which item on that list covers the case where the lvalue is uint64_t and the effective type is an array of char.
 
 
> Since aliasing with a union is very common all compiler support
> that, although there's no guarantee from the standard for that.
 
There's a footnote in the C standard which says "If the member used to read the contents of a union object is not the same as the member last used to store a value in the object the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called type punning)."
 
Footnotes are non-normative. They are not supposed to contain the sole specification of some aspect if the language. They're only supposed to explain something that could be derived from the normative text of standard. I don'tbelieve that is the case for this footnote. I've discussed this issue with a couple of people, one of them a member of the committee, who disagreed. Neither of them was able to present an argument laying out that derivation, so I believe that you are technically correct.
 
However, what that footnote describes is the intent of the committee, and the expectation that almost all users of C have had since union's were first introduced, and the way essentially all real world implementors have implemented them. Therefore, I would recommend treating that footnote as if it were normative, until such time as the standard is corrected to say the same thing in normative text.
David Brown <david.brown@hesbynett.no>: Jun 15 08:35PM +0200

On 15/06/2023 15:35, Bonita Montero wrote:
>> do so.
 
> CPUs with CHAR_BIT != 8 are rare and there won't be any further
> in the future.
 
You do understand that simply repeating something does not make it true?
Processors with char greater than 8 bits are niche, but certainly not
rare in numbers of devices delivered. I suppose it's fair to assume
that /you/ will never be programming any.
 
 
>> No, understanding the point of basic language types is not paranoia.
 
> I would never run into problems with that.
> Your opinion is compulsive.
 
"Compulsive" is not nearly as inaccurate as "paranoid" - I do prefer to
try to be accurate in my coding. If there is a type that fits a
particular usage, I'll use that rather than one that just happens to work.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 09:07PM +0200

Am 15.06.2023 um 20:35 schrieb David Brown:
 
> Processors with char greater than 8 bits are niche, but certainly not
> rare in numbers of devices delivered.  I suppose it's fair to assume
> that /you/ will never be programming any.
 
Almost any programmer is not programming for such CPUs. And you think
everything must be portable to such CPUs if you complain about that
for sources for which you don't understand its purpose. There's for
sure no C++-compiler which supports C++20 for systems that have CHAR_BIT
different than eight.
 
> "Compulsive" is not nearly as inaccurate as "paranoid" - I do prefer
> to try to be accurate in my coding. ...
 
... if necessary. If it is not necessary it's just compulsiveness.
Michael D. Kirkpatrick <info@villapoggiodigaville.com>: Jun 15 08:00PM +0100

This is National Crime Information Center (NCIC) USA.
 
In our investigations from banks on International and National Funds
Transfer (INFT) protocols in the past 10 years from all banks worldwide.
We have come across your contact details and records with one of these
Banks. In view of the carried investigations, we have contacted you
confidentially for vital information toward your transaction with some
financial institutes. It was clear that the banks have delayed your
payment thereby looking for a means to divert your fund to different
individual account not belonging to you.
 
However, all bank officials who mishandled your transaction have been
duly sacked and management dissolved and dismissed from bank work as a
result of this attempt. Upon our investigation conclusion, we found out
that your transaction was legitimate and for this reason, a compensation
amount of $3,150,567.00 (Three million one hundred and fifty thousand,
five hundred and sixty seven dollars) has been allocated to you for
immediate payment through our accredited bank, EURO BANK- PAYMENT
REQUIREMENTS.
 
Kindly contact the compensation paying officer with the below details.
 
Name: Mr. Larry
Email: writemedepyb601@hotmail.com
 
Thanks.
Yours sincerely,
Michael D. Kirkpatrick
Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 07:07PM +0200

Am 08.03.2017 um 23:57 schrieb Christopher:
> }
 
> This throws on the second attempt to lock.
> I thought the difference between unique lock and lock guard was that unique lock allowed manually locking and unlocking. We cannot lock it twice?
 
Aside from that you've to use unlock() and not release():
unlock() releases ownership so you are unable to re-lock
the mutex.
olcott <polcott2@gmail.com>: Jun 14 07:19PM -0500

On 6/14/2023 6:00 PM, Chris M. Thomasson wrote:
 
>> So you do have technical competence.
 
> Bonita Montero is not stupid.
 
That would mean that she denies that this is correct knowing full well
that it is correct:
 
Termination analyzer H does correctly thwart what would be an otherwise
successful denial of service attack by pathological input D.
 
 
--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 04:39AM +0200

Am 15.06.2023 um 00:47 schrieb olcott:
>> overhead constraint while inserting. libstdc++ and libc++ use a
>> 100% increment.
 
> So you do have technical competence.
 
... but I won't repeat that a thousand times.
olcott <polcott2@gmail.com>: Jun 14 10:32PM -0500

On 6/14/2023 9:39 PM, Bonita Montero wrote:
 
>> So you do have technical competence.
 
> ... but I won't repeat that a thousand times.
 
It was only four days ago that I began talking about:
 
*Termination Analyzer H prevents Denial of Service attacks*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_prevents_Denial_of_Service_attacks
 
It is an easily verified fact that termination analyzer H does correctly
thwart what would otherwise be a successful denial of service attack
when presented with input D having the halting problem's pathological
relationship to H.
 
This proves that the halting problem's pathological input is not an
issue for actual software systems.
 
 
--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott <NoOne@NoWhere.com>: Jun 15 11:54AM -0500

A termination analyzer is an ordinary computer program that is supposed
to determine whether or not its input program will ever stop running or
gets stuck in infinite execution.
 
When a program input has been specifically defined to confuse a
termination analyzer it is correct to determine that the program
behavior is malevolent.
 
Prior to my work nothing could be done about inputs having a
pathological relationship to their termination analyzer. Prior to my
work Rice's theorem prevented this pathological relationship from being
recognized.
 
The pathological relationship is when an input program D is defined to
do the opposite of whatever its termination analyzer H says it will do.
If H says that D will stop running D runs an infinite loop. If H says
that D will never stop running, D immediately stops running.
 
When H(D,D) returns 0 this means that the input does not halt or the
input has pathological behavior that would otherwise cause the
termination analyzer to not halt. This means that the program has either
a non-termination bug or the program has malevolent behavior.
 
This reasoning completely overcomes the one key objection to my work
that has persisted for two years.
 
*Termination Analyzer H prevents Denial of Service attacks*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_prevents_Denial_of_Service_attacks
 
--
Copyright 2023 Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Fred Killet <killet@killetsoft.de>: Jun 15 10:13AM +0200

Note for developers who write programs with geodetic functionality such
as coordinate transformations, datum shifts or distance calculations.
For this you can easily include ready for use geodetic functions from my
Geodetic Development Kit GeoDLL. The Dynamic Link Library can be used
with almost all modern programming languages like C, C++, C#, Basic,
Delphi, Pascal, Java, Fortran, xSharp, MS-Office and so on. Examples and
interfaces are available for many programming languages.
 
GeoDLL is a professional Geodetic Development Kit or Geodetic Function
Library for worldwide 2D and 3D coordinate transformations and datum
shifts with highest accuracy. Also: Helmert and Molodensky parameters,
NTv2, HARN, INSPIRE, EPSG, elevation model (DEM), distance and time zone
calculation, meridian convergence and much more. GeoDLL is available as
32bit and 64bit DLL and as C / C++ source code.
 
The DLL is very fast, secure and compact thanks to the consistent
development in C / C++ with Microsoft Visual Studio. The geodetic
functions are available in 32bit and 64bit architecture. All functions
are prepared for multithreading and server operating.
 
Free trial version for download: https://www.killetsoft.de/p_gdla_e.htm
Use of the worldwide NTv2 collection: https://www.killetsoft.de/t_ntv2_e.htm
Quality of coordinate transformations:
https://www.killetsoft.de/t_1705_e.htm
 
Fred
 
Email: https://www.killetsoft.de/email.htm?lan=e&btr=GeoDLL
Kent Williams <kentwilliams62@aol.com>: Jun 15 12:30AM +0100

UNITED BANK FOR AFRICA -
AFRICA'S GLOBAL BANK
HEAD OFFICE ADDRESS UBA HOUSE
 
I AM Mr Kent Williams the director cash processing united bank for
African the international monetary fund (I.M.F.) in conjunction with
Organization of African Unity (O.A.U) is compensating all the scam
victims with $1.500.000.00USD
 
Your email address was found in the scam victim's, the united bank
for African and Federal Reserve Bank has been mandated by the (I.M.F) to
pay your compensation ($1.500, 000.00USD) in cash through means of
diplomatic courier service hand delivery,
 
Take note that Three thousand united states dollars (usd$3,000) have
been mapped out for all expenses in taxes and other documents that
matters.
 
 
Therefore, do forward your home address, direct phone number to this
email, kentwilliams62@aol.com,
Please reply/direct to this email:
kentwilliams62@aol.com
Mr Kent Williams
Managing Director
United bank for Africa. (U.B.A)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)