- Regal eagle / American cloud - 2 Updates
- "2020-02 Prague ISO C++ Committee Trip Report ??? C++20 is Done" - 2 Updates
| woodbrian77@gmail.com: Feb 27 08:19PM -0800 On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. Thomasson wrote: > > reduced by switching from TCP to SCTP. Thanks in advance. > Iirc, you require a user to "register" by sending you an email with > their password in the clear? I plan to use Wireguard for encryption so it could be done after we have that set up. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 28 04:50PM >> their password in the clear? > I plan to use Wireguard for encryption so it > could be done after we have that set up. You don't understand how passwords work do you? You should NEVER be storing user's passwords whether they are encrypted or not on your servers: you should be HASHING the user password on the user's machine and sending that over an encrypted link. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 28 12:42AM -0500 Chris Vine wrote: > You keep going on about reinterpret_cast. To remind you, the code in > question which you previously said had undefined behaviour, and you now > seem to say has implementation defined behaviour, Please do not put your words in my mouth. I am saying that it is ok for C++ Standard Library "to use the compiler implementation-specific behavior" (removing possessive case but all same words). From the below definition of undefined behavior: 3.28 [defns.undefined] undefined behavior behavior for which this document imposes no requirements [Note 1 to entry: Undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, *to behaving during translation or program execution in a documented manner characteristic of the environment* (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. Evaluation of a constant expression never exhibits behavior explicitly specified as undefined in Clause 4 through Clause 15 of this document (7.7). — end note] the compiler implementation-specific behavior means exactly that compiler behaves "during translation or program execution in a documented manner characteristic of the environment". As long as no requirements on this behavior is imposed by the Standard ("this document"), it is also undefined behavior simply by definition. > Y* q = new(&s) Y{2}; > const int h = std::launder(reinterpret_cast<Y*>(&s))->z; > So just what behaviour do you think is implementation-defined here? Where did I say that "here" had implementation-defined behavior (for the record, I think it may or may not have that, depending on a specific implementation)? I did say that [the reinterpret_cast expression above] had undefined behavior because I cannot see where the Standard imposes any requirements on that expression (in plain English, it never tells me what the result of this expression shall be). Hence I have no other choice than to conclude it has undefined behavior by definition (and believe me I am not enjoying it a little bit: I have tons of code using reinterpret_cast in similar manner -- although some of it is protected by compiler-specific #ifdefs but mainly for different reasons). > (the mapping of pointer to integer, and the effect of conversions > between object pointer and function pointer) but these are not relevant > here. That was exactly my point: even if reinterpret_cast of some mappings is defined by a _particular_ compiler and therefore the C++ Standard Library could use it in its implementation of std::allocator -- which gcc-9.2 Library does not do -- the reinterpret_cast behavior for the above code snippet would still be undefined -- again, regardless of whether some particular implementation documents it. > Just repeating yourself does not make what you say true. Exactly. In particular, repeating that I am wrong does not make me wrong. > Let's have a > proper explanation, preferably with reference to some authoritative > work[1]. If the text of the latest Draft n4849 is not authoritative enough I am sorry, I do not have the official text of C++17. Although, reinterpret_cast above would be UB even according to C++11 -- whose official text I do have if that satisfies you. Or do you believe there is a higher authority on the Standard then the Standard itself? > global placement new operator return by reference to the address of its > void* argument). Unfortunately you are on the wrong side of that one > also. Not again, please. I thought you wanted to give a "proper explanation, preferably with reference to some authoritative work"? Also, my being wrong would not be unfortunate? I don't mind standing corrected, it just has not happened so far in this particular discussion. -Pavel |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 28 02:44PM On Fri, 28 Feb 2020 00:42:15 -0500 > Chris Vine wrote: [snip] > bit: I have tons of code using reinterpret_cast in similar manner -- although > some of it is protected by compiler-specific #ifdefs but mainly for different > reasons). This helpfully identifies the source of your thinking. I am somewhat reluctant to continue this because I think from our previous exchanges it is likely to be fruitless, but here are the main provisions of the C++17 standard which define the behaviour of this code. I would have hoped that it would have been apparent from my earlier posts, but here it is in extenso: §4.5/3 (a complete object may be constructed in storage comprising an array of unsigned char or of std::byte) §6.8/10 (an object may be accessed through a glvalue of, and therefore aliased by a pointer to, its dynamic type or amongst other things a char, unsigned char or std::byte type) §8.2.9/1 (static_cast<T>(v) converts the expression v to type T, where it is one of the cases covered by §8.2.9) §8.2.9/13 (the expression static_cast<T*>(static_cast<void*>(p1)) returns the pointer value unchanged (except as to type) where, as in our case, the type of p1 and T* are not pointer-interconvertible, provided that the alignment requirement of type T is met). §8.2.10/7 (an object pointer can be converted by reinterpret_cast to an object pointer of a different type: reinterpret_cast<cv T*>(v) is equivalent to static_cast<cv T*>(static_cast<cv void*>(v))) §8.3.6/1 ((alignof T) yields the alignment requirement of type T) §10.6.2/3 (alignas(T) is the same as (alignas (alignof T)), and results in its operand meeting the alignment requirement of T) §21.6.2.3/1 (the return value of the placement new operator for single objects is its placement pointer value unchanged, and that operator performs no other action than return it) §21.6.4 (std::launder permits access to an object that is within its lifetime and whose storage is located at the address given by its operand - say, in an array of unsigned char or std::byte, as the corollary of §4.5/3). You will I suspect be inclined to dismiss all this. If so, can I invite you to consider three additional points. First, as I have previously pointed out, the authors of cppreference.com think the code is correct and I suspect they know more about it than you do. Secondly, as I have also pointed out, Stroustrup's TC++PL contains a similar example (using std::uninitialized_copy()) and I suspect he knows more about it than you do. Thirdly you might then respond "that's an argument ad verecundiam", and indeed it is, although I have also given you the argument on the facts. Let me alternatively appeal to common sense and give an example of a case where you cannot feasibly directly use the return value of placement new (as opposed to the buffer value passed to it) in the way you have previously suggested. This is the very common idiom of using an array of unsigned char or std::byte to construct an uninitialized buffer for objects of class type T, let's say to make a fixed-size circular buffer of up to 100 T elements. For circular buffers you would commonly construct an element in the buffer using placement new, and then, when you subsequently copy/move the element from the buffer, destroy the buffer element by calling its destructor explicitly. You could not however store the pointer value returned by the application of placement new without keeping a separate array of T* pointers to shadow each of the possible 100 or less T elements in the array of unsigned char at any one time. That would be a ridiculous waste of memory and even if you doubt the competence of cppreference.com and/or Stroustrup, you must surely think that the authors of the C++ standard would have taken the effort to cover this, particularly given that the standard explicitly permits the construction of objects in arrays of unsigned char or std::byte. |
| 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