1

Topic: Whether safely to appropriate one pointer to another?.

Greetings! How think, whether it is possible in a C or a C ++ to receive any ghost effect during assignment of one pointer to another? I.e.,  speaking, whether the program on performance of a simple construction of type x = y can fall? We consider that x and y are the most normal "crude" pointers, i.e. not a smart-pointery, not classes with the redefined assignment statement and anything such, and simply most normal pointers: SomeType * x; AnotherType * y;////here a lot of the different code.//x and y any values are appropriated,//and can and are not appropriated...//x = y; Or such assignment is always safe, even if pointers contain null or "garbage"?

2

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> As think, whether it is possible in a C or a C ++ to receive any ghost effect during O> assignment of one pointer to another? Races?

3

Re: Whether safely to appropriate one pointer to another?.

Hello, Ops, you wrote: Ops> Races? Races of whom with whom?

4

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> Races of whom with whom? O> the pointer is not obliged chitatsja/be written , and in any case the context can switch, and 2nd part re-record in other flow.

5

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> we Consider that x and y are the most normal O> "crude" pointers, i.e. not a smart-pointery, not classes with redefined operator O> assignment and anything such, and simply most normal pointers: O> O> SomeType * x; O> AnotherType * y; O> O> Or such assignment is always safe, even if pointers contain null or "garbage"? If "not a smart-pointery, not classes with the redefined assignment statement" it is possible to speak about char* x; char* y;? Then it is precisely safe. Otherwise - in what a difference?

6

Re: Whether safely to appropriate one pointer to another?.

Hello, VladFein, you wrote: VF> if "not a smart-pointery, not classes with the redefined assignment statement" it is possible to speak about VF> VF> char* x; VF> char* y; VF> VF>? Yes. And instead of char there can be any other type. VF> then it is precisely safe. Apprx. Just in case we wait still for answers...

7

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> As think, whether it is possible in a C or a C ++ to receive any ghost effect during O> assignment of one pointer to another? I.e.,  speaking, whether the program O> on performance of a simple construction of type x = y can fall? We consider that x and y are the most normal O> "crude" pointers, i.e. not a smart-pointery, not classes with redefined operator O> assignment and anything such, and simply most normal pointers: assignment statement Redefinition - here NOT in a subject (pointers, instead of objects are appropriated all the same) - so it it is not necessary to be afraid. O> O> SomeType * x; O> AnotherType * y; O>//O>//here a lot of the different code. O>//x and y any values are appropriated, O>//and can and are not appropriated... O>//O> x = y; O> O> Or such assignment is always safe, even if pointers contain null or "garbage"? Here a main point: How are connected among themselves SomeType and AnotherType??? If it is absolutely different types (in any way  inheritance) - that it  not safely in general, I would make so: if (dynamic_cast <SomeType *> (y)) {x = y;} All problem that if SomeType and AnotherType are not connected in any way among themselves on class hierarchy in itself assignment of the pointer certainly transits, but he will specify in object of ABSOLUTELY other type (by the further operation pointerful "x" welcome to world UB)...

8

Re: Whether safely to appropriate one pointer to another?.

Not safely in   already answered

9

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> As think, whether it is possible in a C or a C ++ to receive any ghost effect during assignment of one pointer to another? If strongly it is necessary, it is possible struct A {int *x, *y; void fn () {x=y;}}; int main (int argc, char ** argv) {A *a=0; a-> fn (); return 0;} And generally a madhouse with these UB. Soon wrong amount of gaps will be UB. Thus the compiler in case of UB silently will try to generate as much as possible unexpected code.

10

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> Or such assignment is always safe, even if pointers contain null or "garbage"? I would not began to appropriate non-initialized garbage because tools of static analysis of the code have the right twice . At first, we use value of unassigned variable. Secondly, we then do not dereference the target pointer, so? Here and not used appropriated value. That to legality from the point of view of / ++. There is such piece, as signaling NaN. It can lead to that following assignment falls: float f1; float f2; f2 = f1; If under it there is "a legislative basis" in / ++, that, probably, it is applicable and to pointers.

11

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> Or such assignment is always safe, even if pointers contain null or "garbage"? With garbage UB, if there not char. And so, still it is possible with pointers on methods to burn slightly in the theory.

12

Re: Whether safely to appropriate one pointer to another?.

O> x = y; Hypothetically, the pointer can represent pair :. And besides, hypothetically, y can be a variable  in storage, and x - the compiler decides to allocate in registers "directly ". And further we read here: If the destination operand is a segment register (DS, ES, FS, GS, or SS), the source operand must be a valid segment selector. In protected mode, moving a segment selector into a segment register automatically causes the segment descriptor information associated with that segment selector to be loaded into the hidden (shadow) part of the segment register. While loading this information, the segment selector and segment descriptor information is validated (see the "Operation" algorithm below)... That is, assignment  to the value register  the selector (segment registers contain selectors in the protected mode) causes falling. But as hardly more than almost all axes working in the protected mode, give to process one plane address space to store value of the selector in a variable-index of sense are not present, therefore pointer assignment not . But basically there can be more other architecture at which for example all storage accesses can become only through what a thread . The register - the pointer and which for example can accept only aligned for the size  value, and assignment attempt to such register of not aligned value causes a protection error.

13

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> Greetings! O> O> SomeType * x; O> AnotherType * y; O>//O>//here a lot of the different code. O>//x and y any values are appropriated, O>//and can and are not appropriated... O>//O> x = y; O> O> Or such assignment is always safe, even if pointers contain null or "garbage"? For some reason nobody marked the most obvious - attempts  any of pointers this violation strict aliasing, i.e. in  total UB (if not  separately).

14

Re: Whether safely to appropriate one pointer to another?.

Hello, Alexander G, you wrote: AG> Hello, okman, you wrote: O>> Or such assignment is always safe, even if pointers contain null or "garbage"? AG> I would not began to appropriate non-initialized garbage because tools of static analysis of the code have the right twice . AG> At first, we use value of unassigned variable. AG> Secondly, we then do not dereference the target pointer, so? Here and not used appropriated value. AG> that to legality from the point of view of / ++. AG> There is such piece, as signaling NaN. AG> It can lead to that following assignment falls: AG> AG> float f1; AG> float f2; AG> f2 = f1; AG> AG> If under it there is "a legislative basis" in / ++, that, probably, it is applicable and to pointers. I always considered that assignment of one pointer to another is always safe, even if pointers specify "in anywhere". But here came across approximately such code it (is strongly simplified): #include <cstdio> struct Base {virtual ~Base () {}}; struct X1: public virtual Base {}; struct X2: public virtual Base {}; struct Child: public X1, public X2 {}; int main () {X1 * p1 = new X1 (); delete p1; Base * p2; p2 = p1; printf ("p2 = %p\r\n", (void *) p2); return 0;} At start on VS2015 or VS2008 in mode Debug the program falls at line ' p2 = p1 ': "Exception thrown at [...] in MyProgram.exe: 0xC0000005: Access violation reading location [...] ". Online compilers similarly behave: codepad (a C ++) - Segmentation fault http://codepad.org/ZdbdFm98 ideone (a C ++ 14) - Runtime error https://ideone.com/HRCX3A rextester (a C ++ gcc) - Invalid memory reference (SIGSEGV) http://rextester.com/XKG97608 rextester (a C ++ clang) - Invalid memory reference (SIGSEGV) http://rextester.com/GAKSE23949 the Key moment - the virtual inheritance X1 and X2 from Base. It would be desirable to understand, how much such behavior (i.e. dereferencing of the pointer, probably trailing, at performance of coercions of types on inheritance hierarchy) legally from the point of view of the C standard ++. Or it especially implementation-defined?.

15

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> It would be desirable to understand, how much such behavior (i.e. dereferencing of the pointer, probably trailing, O> at performance of coercions of types on inheritance hierarchy) legally from the point of view of the C standard ++. O> Or it especially implementation-defined?. Links to the standard I will not result, but purely logically falling is justified, since there is a reversal on  to the address which OS can be already returned.

16

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> struct X1: public virtual Base {}; O> struct X2: public virtual Base {}; O> struct Child: public X1, public X2 {}; O> int main () O> {O> X1 * p1 = new X1 (); O> delete p1; O> Base * p2; O> p2 = p1; O> printf ("p2 = %p\r\n", (void *) p2); O> return 0; O>} O> [/cpp] O> the Key moment - the virtual inheritance X1 and X2 from Base. Here therefore also write in the book "a C ++ for teapots": Always initialize pointers in designers and always nullify the pointer after storage clearing in which he specifies. These actions superfluous do not happen.

17

Re: Whether safely to appropriate one pointer to another?.

Hello, zaufi, you wrote: Z> for some reason nobody marked the most obvious - attempts  any of pointers this violation strict aliasing, i.e. in  total UB (if not  separately). And  there dereference? We only appropriated.

18

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> Greetings! O> as think, whether it is possible in a C or a C ++ to receive any ghost effect during O> assignment of one pointer to another? I.e.,  speaking, whether the program O> on performance of a simple construction of type x = y can fall? We consider that x and y are the most normal O> "crude" pointers, i.e. not a smart-pointery, not classes with redefined operator O> assignment and anything such, and simply most normal pointers: O> O> SomeType * x; O> AnotherType * y; O>//O>//here a lot of the different code. O>//x and y any values are appropriated, O>//and can and are not appropriated... O>//O> x = y; O> O> Or such assignment is always safe, even if pointers contain null or "garbage"? And if it is pointers on methods? Somewhere heard that the pointer on a method it is far not (void *). If someone can - throw the link to a distinct explanation.

19

Re: Whether safely to appropriate one pointer to another?.

Hello, Alexander G, you wrote: AG> Hello, zaufi, you wrote: Z>> for some reason nobody marked the most obvious - attempts  any of pointers this violation strict aliasing, i.e. in  total UB (if not  separately). AG> And  there dereference? We only appropriated. Well in the given code not to see certainly... But pointers after all appropriate that when-nibudt  %)

20

Re: Whether safely to appropriate one pointer to another?.

Hello, SaZ, you wrote: SaZ> And if it is pointers on methods? Somewhere heard that the pointer on a method it is far not (void *). If someone can - throw the link to a distinct explanation. We tell so: it is far not (void *), and more difficult type - here is how the first parameter in _beginthread: https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx For the sake of justice: the first parameter in _beginthread - the pointer on global function or on a static method of a class. Simply at the time of ANSI the C, the pointer on void was considered as analog of the general-purpose pointer. Here an example of function of sorting and transmission to it of the pointer on "comparator": https://www.tutorialspoint.com/c_standa … _qsort.htm And about pointers on methods - here is more detailed: https://www.codeguru.com/cpp/cpp/articl … nction.htm Here still something useful on the given subject: https://toster.ru/q/240698

21

Re: Whether safely to appropriate one pointer to another?.

O> But here came across approximately such code it (is strongly simplified): Precisely falls in assignment?? Here for example does not want to fall http://coliru.stacked-crooked.com/a/8d2dea8e83a98c19 and even so http://coliru.stacked-crooked.com/a/4e8c07ee945250e9

22

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> It would be desirable to understand, how much such behavior (i.e. dereferencing of the pointer, probably trailing, O> at performance of coercions of types on inheritance hierarchy) legally from the point of view of the C standard ++. O> Or it especially implementation-defined?. If I correctly understood, you came across indefinite behavior at conversion of pointers: With ++ 14 12.7 Construction and destruction 3. To explicitly or implicitly convert a pointer (a glvalue) referring to an object of class X to a pointer (reference) to a direct or indirect base class B of X, the construction of X and the construction of all of its direct or indirect bases that directly or indirectly derive from B shall have started and the destruction of these classes shall not have completed, otherwise the conversion results in undefined behavior. To form a pointer to (or access the value of) a direct non-static member of an object obj, the construction of obj shall have started and its destruction shall not have completed, otherwise the computation of the pointer value (or accessing the member value) results in undefined behavior. [Example: struct A {}; struct B: virtual A {}; struct A C: B {}; struct D: virtual A {D (A *);}; struct X {X (A *);} ; struct E: a C, D, X {//undefined: upcast from E* to A* E (): D (this),//might use path E* -> D* -> A*//but D is not constructed//D ((a C *) this),//defined://E* -> C* defined because E () has started//and C* -> A* defined because//a C fully constructed X (this) {//defined: upon construction of X,}//C/B/D/A sublattice is fully constructed}; - end example] That is for your case at first it is necessary to make conversion (assignment) while the object is not destroyed, and only then to delete object: Base * p2; p2 = p1; delete p1; printf ("p2 = %p\r\n", (void *) p2);//Ok

23

Re: Whether safely to appropriate one pointer to another?.

Hello, okman, you wrote: O> O>#include <cstdio> O> struct Base O> {O> virtual ~Base () {} O>}; O> struct X1: public virtual Base {}; O> struct X2: public virtual Base {}; O> struct Child: public X1, public X2 {}; O> int main () O> {O> X1 * p1 = new X1 (); O> delete p1; O> Base * p2; O> p2 = p1; O> printf ("p2 = %p\r\n", (void *) p2); O> return 0; O>} O> O> At start on VS2015 or VS2008 in mode Debug the program falls at line ' p2 = p1 ': At me also (on VS2015) the set example falls at line ' p2 = p1 ' Then I changed an example so: #include <cstdio> struct Base {virtual ~Base () {}}; struct X1: public virtual Base {}; struct X2: public virtual Base {}; struct Child: public X1, public X2 {}; int main () {X1 * p1 = new X1 (); delete p1; X1 * p2;//This line is changed!!! p2 = p1; printf ("p2 = ... And all falling stopped! O> or it especially implementation-defined?. +100500  it is similar to it.

24

Re: Whether safely to appropriate one pointer to another?.

25

Re: Whether safely to appropriate one pointer to another?.

Hello, Croessmah, you wrote:> If I correctly understood a C, you came across indefinite behavior at conversion of pointers: a C>... Thanks, this citation explain all: To explicitly or implicitly convert a pointer (a glvalue) referring to an object of class X to a pointer (reference) to a direct or indirect base class B of X, the construction of X and the construction of all of its direct or indirect bases that directly or indirectly derive from B shall have started and the destruction of these classes shall not have completed, otherwise the conversion results in undefined behavior. A C> That is for your case conversion (assignment) at first is necessary to make while the object is not destroyed, and only then to delete object: a C>... It seems that developers of libraries in course about this nuance. Here found in source codes Boost 1.66.0 following comment (/boost/smart_ptr/weak_ptr.hpp): ////The "obvious" converting constructor implementation:////template <class Y>//weak_ptr (weak_ptr <Y> const and r): px (r.px), pn (r.pn)//{//}////has a serious problem.////r.px may already have been invalidated. The px (r.px)//conversion may require access to *r.px (virtual inheritance).////It is not possible to avoid spurious access violations since//in multithreaded programs r.px may be invalidated at any point.//Apparently, they imply about such case: shared_ptr <X1> ptr =...; weak_ptr <X1> w1 (ptr); ptr.reset (); weak_ptr <Base> w2 (w1);//BANG! Looked implementation std:: weak_ptr in VS2015 - there this moment too is considered.