"James Kuyper Jr." wrote:
>
> Mike Ball wrote:
> >
> > Andrei Iltchenko wrote:
> > > Can you please point out an implementation where offsetof is not broken in
> > > that respect?
> >
> > Certainly.  All versions of the Sun compiler since 1994.
>
> Could you provide the code used to define offsetof() on that compiler,
> and explain any implementation-specific features it relies on?

Yes, but I was wrong, as you point out.  I miscopied the example when
I transferred it from my pc, where I was reading it, to the Sun workstation.

I apologize for the error.

-Mike Ball-

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Fergus Henderson <fjh@cs.mu.OZ.AU> wrote in message
news:985jmi$a21$1@mulga.cs.mu.OZ.AU...
> Ron Natalie <ron@spamcop.net> writes:
>
> >Andrei Iltchenko wrote:
> >>
> >> I think that the definition of a POD class in the current version of
the
> >> Standard is overly permissive in that it allows for POD classes for
which a
> >> user-defined operator function 'operator&' may be defined.
> ...
> >> 1. Complementing the definition of a POD-struct and a POD-union with
the
> >> following words:
> >> A POD-struct/POD-union is an aggregate class/union that has no
user-defined
> >> member function operator&.
> >
> >I'm not sure what problem it is that you are trying to solve.  Why do
> >you need this change of definition of POD?
>
> The problem that Andrei Iltchenko was trying to solve was illustrated by
his
> example using offsetof().
That's exactly what I was trying to point out.

> Clearly the standard implementation of offsetof()
> will not work for members whose type is one for which 'operator&' is
defined.
>
> However, rather than changing the definition of POD, it might be
> simpler to just add another restriction to the use of offsetof().
>
> Here's what it currently says:
>
>  | 18.1 - Types [lib.support.types]
>  ...
>  |    -5- The macro offsetof accepts a restricted set of type arguments in
>  |    this International Standard. type shall be a POD structure or a POD
>  |    union (clause class). The result of applying the offsetof macro to a
>  |    field that is a static data member or a function member is
undefined.
>
> It would be easy enough to add something appropriate here.
That might be a solution with the least impact on the existing code base. I
was just thinking that forbidding user-defined 'operator&' for POD types,
while being quite drastic, would be a most natural solution.

Thanks a lot Fergus.

Sincerely,
Andrei Iltchenko.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie <ron@spamcop.net> wrote in message
news:3AA6C051.EE77D7AB@spamcop.net...
>
>
> Fergus Henderson wrote:
> >
> >
> > However, rather than changing the definition of POD, it might be
> > simpler to just add another restriction to the use of offsetof().
> >
> > Here's what it currently says:
> >
> >  | 18.1 - Types [lib.support.types]
> >  ...
> >  |    -5- The macro offsetof accepts a restricted set of type arguments
in
> >  |    this International Standard. type shall be a POD structure or a
POD
> >  |    union (clause class). The result of applying the offsetof macro to
a
> >  |    field that is a static data member or a function member is
undefined.
> >
> > It would be easy enough to add something appropriate here.
> >
> That would be better.  POD is used for too many other things.  The problem
> is that every implementation of offsetof that he tried is broken not that
> POD is misdefined.  Whether it's easier to mandate a fix to offsetof or
restrict
> what it can be passed (without redefining POD itself) I leave up to those
> who wish to argue about those things.  But lets leave POD alone!
Can you please point out an implementation where offsetof is not broken in
that respect?

Andrei.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Iltchenko wrote:
>
> > who wish to argue about those things.  But lets leave POD alone!
> Can you please point out an implementation where offsetof is not broken in
> that respect?
>
Probably they all are.  Frankly, if I were writing the compiler, I would have
the macro use a builtin function rather than the &0->member kludge.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Iltchenko wrote:
> Can you please point out an implementation where offsetof is not broken in
> that respect?

Certainly.  All versions of the Sun compiler since 1994.

Michael S. Ball
Sun Microsystems Laboratories

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Mike Ball wrote:
>
> Andrei Iltchenko wrote:
> > Can you please point out an implementation where offsetof is not broken in
> > that respect?
>
> Certainly.  All versions of the Sun compiler since 1994.

Could you provide the code used to define offsetof() on that compiler,
and explain any implementation-specific features it relies on?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Mike Ball <mike@ballfam.net> wrote in message
news:3AA7BF86.82D4A849@ballfam.net...
>
>
> Andrei Iltchenko wrote:
> > Can you please point out an implementation where offsetof is not broken
in
> > that respect?
>
> Certainly.  All versions of the Sun compiler since 1994.
>
> Michael S. Ball
> Sun Microsystems Laboratories

Sounds a bit overoptimistic, for the program didn't even compile with Sun
Workshop C++ compiler 5.0, see below:


nestorix:akirsano !124> CC -V test.cpp
CC: WorkShop Compilers 5.0 98/12/15 C++ 5.0
ccfe: WorkShop Compilers 5.0 99/12/09 C++ 5.0 Patch 107311-09
"test.cpp", line 31: Error: Cannot cast from int to POD_bomb&.
"test.cpp", line 31: Error: Cannot cast from int to POD_bomb&.
"test.cpp", line 31: Error: Cannot cast from int to POD_bomb&.
3 Error(s) detected.


line 31:   << offsetof(POD_struct, m_nonstatic_bomb2)



nestorix:akirsano !126> version
Machine hardware:   sun4u
OS version:         5.7
Processor type:     sparc
Hardware:           SUNW,UltraSPARC-IIi-Engine

The following components are installed on your system:


Sun Visual WorkShop C++ 5.0
        Sun WorkShop Compiler C 5.0
        Sun WorkShop Compiler C++ 5.0
        Sun WorkShop Tools.h++ 7.0
        Sun WorkShop Standard 64-bit Class Library 2.0 for C++
        Sun WorkShop Garbage Collector Libraries 1.0 for C++
        Sun WorkShop Visual 3.0
        Sun WorkShop IPE 5.0
        Sun WorkShop TeamWare 2.1
        Sun WorkShop FileMerge 3.1
        Sun WorkShop Dbx 5.0
        Sun WorkShop Performance Analyzer 5.0
        Sun WorkShop LoopTool 2.2
        Sun WorkShop LockLint 2.2
        XEmacs 20.4 Source Distribution


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Mike Ball wrote:
>
> Andrei Iltchenko wrote:
> > Can you please point out an implementation where offsetof is not broken in
> > that respect?
>
> Certainly.  All versions of the Sun compiler since 1994.
>
> Michael S. Ball
> Sun Microsystems Laboratories

I beg to differ.  It's still broken.  At least on the Spar Compiler
5.0.  Andrei's program yields:

x.cc:  line 30:  Error:  Cannot cast from int to POD_bomb&.

The expression it chokes on is:
( size_t ) ( & ( ( ( POD_struct * ) 0 ) -> m_nonstatic_bomb2 ) )



4.2 won't even compile it because it doesn't attempt to implement the
std includes, but if you substitute the "stddef.h" and "iostream.h" and
nuke the std:: references, it produces a non-functioning executable.

My 4.2 disk says copyright 1996, thats after 1994.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie <ron@spamcop.net> wrote in message
news:3AA6C051.EE77D7AB@spamcop.net...
>
>
> Fergus Henderson wrote:
> >
> >
> > However, rather than changing the definition of POD, it might be
> > simpler to just add another restriction to the use of offsetof().
> >
> > Here's what it currently says:
> >
> >  | 18.1 - Types [lib.support.types]
> >  ...
> >  |    -5- The macro offsetof accepts a restricted set of type arguments
in
> >  |    this International Standard. type shall be a POD structure or a
POD
> >  |    union (clause class). The result of applying the offsetof macro to
a
> >  |    field that is a static data member or a function member is
undefined.
> >
> > It would be easy enough to add something appropriate here.
> >
> That would be better.  POD is used for too many other things.  The problem
> is that every implementation of offsetof that he tried is broken not that
> POD is misdefined.  Whether it's easier to mandate a fix to offsetof or
restrict
> what it can be passed (without redefining POD itself) I leave up to those
> who wish to argue about those things.  But lets leave POD alone!
>

Ron, there's more to it than that. The definition of a POD class really has
to be changed to account for the user-defined 'operator&'. For another
example, 3.9 paragraph 2 states:

"For any complete POD object type T, whether or not the object holds a valid
value of type T, the underlying bytes (1.7) making up the object can be
copied into an array of char or unsigned char [footnote: By using, for
example, the library functions (17.4.1.2) memcpy or memmove]. If the content
of the array of char or unsigned char is copied back into the object, the
object shall subsequently hold its original value. [Example:

#define N sizeof(T)
char buf[N];
T obj;   // obj initialized to its original value
memcpy(buf, &obj, N);
            // between these two calls to memcpy,
            // obj might be modified
memcpy(&obj, buf, N);
            // at this point, each subobject of obj of scalar type
            // holds its original value

--end example]

Now, supposing that the POD type T in the example above is POD_bomb

// POD_bomb is a POD-struct. It has no non-static non-public data members,
// no virtual functions, no base classes, no constructors, no user-defined
// destuctor, no user-defined copy assignment operator, no non-static data
// members of type pointer to member, reference, non-POD-struct, or
// non-POD-union.
struct  POD_bomb  {
   int   m_value1;
   int   m_value2;
   int  operator&()
   {   return  m_value1++;   }
   int  operator&() const
   {   return  m_value1 + m_value2;   }
};

I don't think that you can any more count on the assertions made in the
comments to the example. Given a standard conforming implementation, the
code will not even compile. And I see no legal way of copying the contents
of an object of type POD_bomb into an array of char or unsigned char with
memcpy or memmove without making use of the & operator.

Sincerely,
Andrei Iltchenko.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I think that the definition of a POD class in the current version of the
Standard is overly permissive in that it allows for POD classes for which a
user-defined operator function 'operator&' may be defined. Given that the
idea behind POD classes was to achieve compatibility with C structs and
unions, this makes 'Plain old' structs and unions behave not quite as one
would expect them to.

In the C language, if x and y are variables of struct or union type S that
has a member m, the following expression are allowed: '&x', 'x.m', 'x = y'.
While the C++ standard guarantees that if x and y are objects of a POD class
type S, the expressions 'x.m', 'x = y' will have the same effect as they
would in C, it is still possible for the expression '&x' to be interpreted
differently, subject to the programmer supplying an appropriate version of a
user-defined operator function 'operator&' either as a member function or as
a non-member function.

This may result in surprising effects. Consider:

#include <cstddef>
#include <iostream>

// POD_bomb is a POD-struct. It has no non-static non-public data members,
// no virtual functions, no base classes, no constructors, no user-defined
// destuctor, no user-defined copy assignment operator, no non-static data
// members of type pointer to member, reference, non-POD-struct, or
// non-POD-union.
struct  POD_bomb  {
   int   m_value1;
   int   m_value2;
   int  operator&()
   {   return  m_value1++;   }
   int  operator&() const
   {   return  m_value1 + m_value2;   }
};


// POD_struct is a yet another example of a POD-struct.
struct  POD_struct  {
   POD_bomb   m_nonstatic_bomb1;
   POD_bomb   m_nonstatic_bomb2;
};


int  main()
{

   std::cout << "offset of m_nonstatic_bomb2: " << offsetof(POD_struct,
m_nonstatic_bomb2) << '\n';
   return  0;

}

The program above is a well-formed C++ program, and it compiles on every C++
compiler I have access to. The problem is, however, that any attempt to
execute the compiled program results in an immediate crash on every platform
where I tried it. And it's not difficult to figure out what the reason for
the crash is, given the most common way of implementing offsetof.

My proposed resolution to the problem might be:
1. Complementing the definition of a POD-struct and a POD-union with the
following words:
A POD-struct/POD-union is an aggregate class/union that has no user-defined
member function operator&.
2. Specifying that operator& shall be a non-static member function.
I realize that the second change can be somewhat hard on the existing C++
code base, and I can think of other ways of correcting the situation.

I am about to submit a Defect Report on the above issue unless somebody
proves my assertions wrong.


Sincerely,
Andrei Iltchenko.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Iltchenko wrote:
>
> I think that the definition of a POD class in the current version of the
> Standard is overly permissive in that it allows for POD classes for which a
> user-defined operator function 'operator&' may be defined. Given that the
> idea behind POD classes was to achieve compatibility with C structs and
> unions, this makes 'Plain old' structs and unions behave not quite as one
> would expect them to.

POD applies only to data.  The point of the POD distinction is that it
has
all the C behavior for initialization (i.e. none), copying, and aliasing
to
chars.   All the POD constraints are specifically there to make it so
that
a few key operations that are not otherwise well defined on objects can
be
allowed to work the way they did in C (mostly treating data as
aggregations
of char's and static initialization).

> 1. Complementing the definition of a POD-struct and a POD-union with the
> following words:
> A POD-struct/POD-union is an aggregate class/union that has no user-defined
> member function operator&.

I'm not sure what problem it is that you are trying to solve.  Why do
you need
this change of definition of POD?  It's not like you can declare
something POD
like you declare it "const".    If you could, you could say: don't do
anything
that would make this confusing with the C behavior.  But POD doesn't
mean that, and you
can't make such a declaration.   POD says, if the requirements of POD
are met,
then a few more guarantees can be made on the nature of the data in the
object.

How does adding artificial constraints to POD get you anything.
Suddenly my
POD-class becomes non-POD, and a bunch of things go from defined to
undefined
behavior, but there's no compiler error or such that warns you of this.\

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie <ron@spamcop.net> writes:

>Andrei Iltchenko wrote:
>>
>> I think that the definition of a POD class in the current version of the
>> Standard is overly permissive in that it allows for POD classes for which a
>> user-defined operator function 'operator&' may be defined.
...
>> 1. Complementing the definition of a POD-struct and a POD-union with the
>> following words:
>> A POD-struct/POD-union is an aggregate class/union that has no user-defined
>> member function operator&.
>
>I'm not sure what problem it is that you are trying to solve.  Why do
>you need this change of definition of POD?

The problem that Andrei Iltchenko was trying to solve was illustrated by his
example using offsetof().  Clearly the standard implementation of offsetof()
will not work for members whose type is one for which 'operator&' is defined.

However, rather than changing the definition of POD, it might be
simpler to just add another restriction to the use of offsetof().

Here's what it currently says:

 | 18.1 - Types [lib.support.types]
 ...
 |    -5- The macro offsetof accepts a restricted set of type arguments in
 |    this International Standard. type shall be a POD structure or a POD
 |    union (clause class). The result of applying the offsetof macro to a
 |    field that is a static data member or a function member is undefined.

It would be easy enough to add something appropriate here.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Fergus Henderson wrote:
>
>
> However, rather than changing the definition of POD, it might be
> simpler to just add another restriction to the use of offsetof().
>
> Here's what it currently says:
>
>  | 18.1 - Types [lib.support.types]
>  ...
>  |    -5- The macro offsetof accepts a restricted set of type arguments in
>  |    this International Standard. type shall be a POD structure or a POD
>  |    union (clause class). The result of applying the offsetof macro to a
>  |    field that is a static data member or a function member is undefined.
>
> It would be easy enough to add something appropriate here.
>
That would be better.  POD is used for too many other things.  The problem
is that every implementation of offsetof that he tried is broken not that
POD is misdefined.  Whether it's easier to mandate a fix to offsetof or restrict
what it can be passed (without redefining POD itself) I leave up to those
who wish to argue about those things.  But lets leave POD alone!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Iltchenko wrote:
...
> // POD_bomb is a POD-struct. It has no non-static non-public data members,
> // no virtual functions, no base classes, no constructors, no user-defined
> // destuctor, no user-defined copy assignment operator, no non-static data
> // members of type pointer to member, reference, non-POD-struct, or
> // non-POD-union.
> struct  POD_bomb  {
>    int   m_value1;
>    int   m_value2;
>    int  operator&()
>    {   return  m_value1++;   }
>    int  operator&() const
>    {   return  m_value1 + m_value2;   }
> };
...
> code will not even compile. And I see no legal way of copying the contents
> of an object of type POD_bomb into an array of char or unsigned char with
> memcpy or memmove without making use of the & operator.

You must use the & operator, but you don't have to use the overloaded
version:

#define N sizeof(POD_bomb)
char buf[N];
POD_bomb obj={1,2};

// See section 9.2p17
memcpy(buf, reinterpret_cast<POD_bomb*>(&obj.m_value1), N);

I agree, that's clumsy, but it is possible. However, because it's so
clumsy, you may have a point.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

James Kuyper Jr. <kuyper@wizard.net> wrote in message
news:3AAA2DD2.B2536CF3@wizard.net...
> Andrei Iltchenko wrote:
> ...
> > // POD_bomb is a POD-struct. It has no non-static non-public data
members,
> > // no virtual functions, no base classes, no constructors, no
user-defined
> > // destuctor, no user-defined copy assignment operator, no non-static
data
> > // members of type pointer to member, reference, non-POD-struct, or
> > // non-POD-union.
> > struct  POD_bomb  {
> >    int   m_value1;
> >    int   m_value2;
> >    int  operator&()
> >    {   return  m_value1++;   }
> >    int  operator&() const
> >    {   return  m_value1 + m_value2;   }
> > };
> ...
> > code will not even compile. And I see no legal way of copying the
contents
> > of an object of type POD_bomb into an array of char or unsigned char
with
> > memcpy or memmove without making use of the & operator.
>
> You must use the & operator, but you don't have to use the overloaded
> version:
>
> #define N sizeof(POD_bomb)
> char buf[N];
> POD_bomb obj={1,2};
>
> // See section 9.2p17
> memcpy(buf, reinterpret_cast<POD_bomb*>(&obj.m_value1), N);
>
> I agree, that's clumsy, but it is possible. However, because it's so
> clumsy, you may have a point.
>

Exactly, the only well-formed way to take the address of an object of such a
type is to make use of the guarantees that are given in 9.2/17. I tried to
accentuate that in the Defect Report that I subsequently submitted. The
thing is that you cannot always count on the member subobject types not
overloading the unary '&' operator too.

Regards,

Andrei Iltchenko.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]