search for: glvalue

...gt; > <rest of codeis irrelevan> > > First, ptr[i] is an lvalue, of type struct heap *, and ptr[i]-> is an > lvalue of type struct heap (in C++03, this is 5.2.5 paragraph 3, check > footnote 59). > This is where we get the undefined behavior. 3.8/6: "[If you have a glvalue referring to storage but where there is no corresponding object, the] program has undefined behavior if: [...] the glvalue is used to access a non-static data member". There is no object of type 'heap' denoted by *ptr[0] (by 1.8/1, we can only create objects through definitions, new-e...

...undefined behaviors outside of those and the ones caught by {Address,Thread,Memory} Sanitizer. > > I would like to add support for checking the following additional undefined behaviors, which Clang does not currently appear to be able to check for: > > - Using a null pointer or empty glvalue (a dereferenced null pointer) as the object expression in a class member access expression or member function call. > - Using an object of polymorphic class type where either the static and dynamic types are incompatible or the object's lifetime has not started or has ended, in a delete-exp...

...pplicable text from N3376 is: "When a function is called, each parameter shall be initialized with its corresponding argument." [expr.call]/4 the initialization performs lvalue-to-rvalue conversion, which is what ultimately triggers explicit UB: "If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior." [conv.lval]/1 >> That aside, there is no way that 'i' has the same value, since it has no v...

Daniel, Hal, I'm trying to figure out what we would need to do in terms of the current approach, accepting its limitations, to support unions, member arrays, aggregate accesses and type identifiers and what I get looks suspiciously simple. Can you please check it out and let me know if I'm missing something? For unions: TBAA, regardless of a specific approach, cannot guarantee

On 24/11/2012, at 10:21 PM, Nick Lewycky wrote: > > Passing an uninitialized value as a function argument is undefined behaviour on the spot, regardless of what the callee does (even if it never references that argument). Cite reference? No? Then you're guessing ;) > > That aside, there is no way that 'i' has the same value, since it has no value. This is definitely

+aliasing people I *think* this is valid, because the rules have always been described to me in terms of underlying storage type, and not access path. These are all ints, so all loads and stores can alias. On Sat, Aug 9, 2014 at 3:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Tim Northover" <t.p.northover at gmail.com>

...These rules are not based on the name of the type, only the types > contained in the structs. > > TBAA cannot distinguish types solely based on name. > > C++ is similar: > > 3.10.10 > >> If a program attempts to access the stored value of an object through a >> glvalue of other than one of the >> following types the behavior is undefined:54 >> — the dynamic type of the object, >> — a cv-qualified version of the dynamic type of the object, >> — a type similar (as defined in 4.4 ) to the dynamic type of the object, >> — a type that is...

> On Jan 14, 2016, at 4:49 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 14, 2016 at 12:56 PM, John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > C 6.3.2.3p7 (N1548) says: > A pointer to an object type may be converted to a pointer to a > different object type. If the resulting pointer is not