- More about arabs.. - 2 Updates
- Regal eagle / American cloud - 3 Updates
- More about my posts.. - 1 Update
- "2020-02 Prague ISO C++ Committee Trip Report ??? C++20 is Done" - 4 Updates
| queequeg@trust.no1 (Queequeg): Mar 02 02:24PM > " IQ scores typically reflect the quality of education " > For example, if you were never taught how to read, you will score > extremely badly on a standardized test. The issue is multidimensional and complicated, but the bottom line is that there ARE differences in average IQ between human races and societies. -- https://www.youtube.com/watch?v=9lSzL1DqQn0 |
| Vir Campestris <vir.campestris@invalid.invalid>: Mar 02 09:31PM On 02/03/2020 14:24, Queequeg wrote: > The issue is multidimensional and complicated, but the bottom line is that > there ARE differences in average IQ between human races and societies. While there may be small differences between races these are dwarfed by the differences within races. Andy |
| red floyd <no.spam@its.invalid>: Mar 01 10:14PM -0800 On 3/1/20 1:47 PM, David Brown wrote: > good TLS implementation and let people who know what they are doing > implement the security. (The authors of such software are not > infallible either, so track updates and fixes for the software.) Crypto is hard. Really hard. Do not -- repeat DO NOT -- attempt to write your own crypto. Use something like OpenSSL, LibreSSL, or Guttman's Cryptlib for the crypto and secure channel. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 02 01:21PM -0800 On 3/1/2020 1:47 PM, David Brown wrote: >> Actually, DH key exchange can be very dangerous. One needs to know how >> to use it. Large secure primes come to mind. > Friendly reminder - it was /you/ who brought up DH! Indeed I did. It was simply meant for the OP to take a look at; study. Imvvvho, its a good algorihtm to learn, at least. > good TLS implementation and let people who know what they are doing > implement the security. (The authors of such software are not > infallible either, so track updates and fixes for the software.) Fwiw, I have an experimental symmetric cipher. If you get some really free time perhaps you can take a look at it: https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion http://funwithfractals.atspace.cc/ct_cipher https://pastebin.com/raw/feUnA3kP (C version with hardcoded secret key) I can get it to work with traditional HMAC, however its way too slow. Using an optimized HMAC that can take a digest without destroying its internal state makes things go a lot faster. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 02 01:24PM -0800 On 3/2/2020 1:21 PM, Chris M. Thomasson wrote: > I can get it to work with traditional HMAC, however its way too slow. > Using an optimized HMAC that can take a digest without destroying its > internal state makes things go a lot faster. Fwiw, the folks over on sci.crypt are telling me that its beyond their experience to properly perform crypto analysis on. Perhaps you can help tear it apart!? |
| queequeg@trust.no1 (Queequeg): Mar 02 03:50PM > Every sane poster should care that people interested in C++ see > walls of non-topical nonsense from Amine Moulay Ramdane > and so go search for some other forum. And every sane newcomer will, probably, see that these posts are nothing more than manure, killfile the moron and participate in other topics... -- https://www.youtube.com/watch?v=9lSzL1DqQn0 |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Mar 01 06:58PM -0500 Chris Vine wrote: >> I addressed the insignificance of the difference for the matter in hand in my >> previous point. > I don't think so. Your version has undefined behaviour. It is and that was the point. If the source pointer to an array or unsigned char or std:byte, it still would have undefined behavior. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 02 12:44AM On Sun, 1 Mar 2020 18:58:00 -0500 > > I don't think so. Your version has undefined behaviour. > It is and that was the point. If the source pointer to an array or unsigned char > or std:byte, it still would have undefined behavior. You are going round in circles. If the source was an array of unsigned char or std:byte, it would not have undefined behaviour if you used reinterpret_cast with std::launder. The standard is clear on the point. You prove nothing by producing code which we both agree has undefined behaviour. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Mar 01 09:11PM -0500 Chris Vine wrote: > The C++ standard does very definitely guarantee that the pointer values > are the same - §8.2.9/13 of C++17 read with the other provisions to > which I have referred. I said this much right in the beginning of the post to which I am responding. I really hate citing myself and sorry I did not assign a an anchor to that statement, but now I am fixing that: " (k) To the contrary, I think that the closest thing to the above that the Standard guarantees is that the "pointer values" of p1 and p2 are same. " Were the types to be pointer-interconvertible a > cppreference.com is right about that and my complaints on that were > wrong). §21.6.4 directly covers this case. It prevents the kind of > optimization to which you refer. You know, that is actually an interesting argument to which I almost agreed. To be intellectually honest and maybe convince you to change your mind I have to address it at length. std::launder definition uses a term that is not explicitly defined by the Standard, namely "a pointer value that points to an object". This term seems to be used a couple of times in the Standard in a sense "a pointer that represents the address of a storage location where the object is located" as opposed to "a pointer that points to the object". So I originally was about to assume that std::launder could magically fix the cast between non-pointer-interconvertible objects in addition to its declared purpose. Then I looked through all the WG21 working papers on std::launder I could find: 1. Motivating example from 5/31/13: https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/93ebFsxCjvQ/myxPG6o_9pkJ 2. The original defect report #1776 from 2013-09-24 1776. Replacement of class objects containing reference member http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1776 3. The final C++14 "comment status" ruling to not include the fix to defect #1776 to C++14 but validating it to be left open for fixing in the future versions of the Standard http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3903.html#FI15 4. The defect reports that are supposed to be resolved resolved as by-products of resolving defect #1776 1404. Object reallocation in unions http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1404 636. Dynamic type of objects and aliasing http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#636 2182. Pointer arithmetic in array-like containers http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2182 1116. Aliasing of union members http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1116 5. The original text of the solution, with explanatory example from 2014-11-21: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4303.html 6. The final text of the solution, (that by the way had to introduce interconvertible pointers and put restrictions on what reinterpret_cast could do) from 2016-06-23: Core Issue 1776: Replacement of class objects containing reference members http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html (l) *nowhere* in the above proceedings was std::launder: - used; or - claimed to be useful for; or - motivated by a justification of its use for; or - illustrated by an example accessing a C++ object (say, `o2') via a result of reinterpet_cast (or an equivalent sequence of static_casts) of a pointer to another object (say, `o1') not pointer-interconvertible with `o2', to the pointer to the `o2'. In fact the only complaint to std::launder known to me filed after C++17 adoption, "On std::launder" (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0532r0.pdf), presented, among the others, the complaint similar to yours on non-practicality of always stashing the value returned by placement operator new -- but nowhere did it refer to using std::launder for the purpose mentioned above in (l) that you claim it can fulfill. Never in its (rather voluminous) text (containing several examples) was such casting mentioned even once. All the above makes me believe that the use of an under-defined term "a pointer value that points to an object" in std::launder definition is simply an oversight and that the authors intended to use a (much better defined) term "a pointer that points to an object" that sneaked in a series of revisions of std::launder proposal made since the original 2014-11-21 revision where same requirement was formulated as (obviously, incorrectly) "p represents the address A of a byte in memory". > placement new within char arrays constructed on free store and then > accessing them with reinterpret_cast and std::launder is the only > technically correct way (m) So you are changing the subject from Undefined behavior to (also undefined) "technically correct way" and make an unsubstantiated statement about it. Nice trick! > you can construct containers which allocate > their memory dynamically, including implementing std::vector: > https://stackoverflow.com/questions/60465235/does-stdunitialized-copy-have-undefined-behavior (n) anyone willing to actually follow your reference will find that neither the answer nor even the question (!) mentions reinterpret_cast. > I am satisfied that you are wrong and everyone else is right. let's mark the above statement (o) :-) > Try to trim your posts to a reasonable size. I will consider trimming them to zero size because (m), (n) and especially (o) above seem to indicate that you are arguing for the sake of arguing -- which ironically may make one of your previous statements correct -- specifically that this discussion was not going to be fruitful. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Mar 01 09:22PM -0500 Chris Vine wrote: > You are going round in circles. If the source was an array of > unsigned char or std:byte, it would not have undefined behaviour if you > used reinterpret_cast with std::launder. That code explicitly came contained this disclaimer " let's pretend that launder and aliasing do not exist; we may have separate disagreement about these but IMHO they are irrelevant here " Does it really feel good to take things out of context? > The standard is clear on the > point. You prove nothing by producing code which we both agree has > undefined behaviour. It's good we both agreed to that although for different reasons. Your delusions about std::launder are explicitly addressed in another sub-branch of this thread; of course given your own admission in that branch it is probably too long for your to read it in full. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment