In article fsf@vx.cit.alcatel.fr, James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
>dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
>
>|>  #include <malloc>
>|>  #include <new>
>|>  #include <iostream>
>|>
>|>  void *  operator new(size_t bytesReq) {
>|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
>|>   return malloc(bytesReq);
>|>  }
>
>Generally speaking, I suspect that the above function will result in an
>infinite recursion in most implementations, and I believe that it should
>be illegal.  (No point in making things overly difficult for the
>implementor without reason.)
>
>Still, I'm curious to know what passage in the current draft makes it
>illegal.  I'm not aware of one.

I wonder if you have reversed a requirement that is in the draft.

It says in 18.4.1 "Storage allocation and deallocation" that it is
unspecified whether any of the forms of operator new call malloc, but
20.4.6 "C Library" says "The functions calloc(), malloc(), and realloc()
do not attempt to allocate storage by calling ::operator new() (18.4)."

That means it must be safe to implement an operator new in terms of malloc.
Some such requirement is necessary to allow portable allocation functions
to be written, and this is the obvious requirement to make.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage <Stephen.Clamage@Eng.Sun.COM> wrote:
: James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
: >dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
: >
: >|>  #include <malloc>
: >|>  #include <new>
: >|>  #include <iostream>
: >|>
: >|>  void *  operator new(size_t bytesReq) {
: >|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
: >|>   return malloc(bytesReq);
: >|>  }
: >
: >Generally speaking, I suspect that the above function will result in an
: >infinite recursion in most implementations, ....

: I wonder if you have reversed a requirement that is in the draft.

: It says in 18.4.1 "Storage allocation and deallocation" that it is
: unspecified whether any of the forms of operator new call malloc, but
: 20.4.6 "C Library" says "The functions calloc(), malloc(), and realloc()
: do not attempt to allocate storage by calling ::operator new() (18.4)."

: That means it must be safe to implement an operator new in terms of malloc.
: Some such requirement is necessary to allow portable allocation functions
: to be written, and this is the obvious requirement to make.

I think James implied that operator << and endl() is allowed (and likely) to
call ::operator new(), therefore introducing an infinite recursion.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Stephen.Clamage@Eng.Sun.COM (Steve Clamage) writes:

|>  In article fsf@vx.cit.alcatel.fr, James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>  >dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
|>  >
|>  >|>  #include <malloc>
|>  >|>  #include <new>
|>  >|>  #include <iostream>
|>  >|>
|>  >|>  void *  operator new(size_t bytesReq) {
|>  >|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
|>  >|>   return malloc(bytesReq);
|>  >|>  }
|>  >
|>  >Generally speaking, I suspect that the above function will result in an
|>  >infinite recursion in most implementations, and I believe that it should
|>  >be illegal.  (No point in making things overly difficult for the
|>  >implementor without reason.)
|>  >
|>  >Still, I'm curious to know what passage in the current draft makes it
|>  >illegal.  I'm not aware of one.
|>
|>  I wonder if you have reversed a requirement that is in the draft.
|>
|>  It says in 18.4.1 "Storage allocation and deallocation" that it is
|>  unspecified whether any of the forms of operator new call malloc, but
|>  20.4.6 "C Library" says "The functions calloc(), malloc(), and realloc()
|>  do not attempt to allocate storage by calling ::operator new() (18.4)."
|>
|>  That means it must be safe to implement an operator new in terms of malloc.
|>  Some such requirement is necessary to allow portable allocation functions
|>  to be written, and this is the obvious requirement to make.

I know that it is legal to call malloc and free in operator new.  My
question is: where in the draft does it say that I cannot call other
library functions (like ostream::operator<<), or if it is implicit (the
draft doesn't say I can), does this also mean that calling e.g.:
"memset" is illegal, or at least, not guaranteed?  For that matter, what
is the "official" status of the above example: undefined behavior?

(FWIW: even if the draft says that anything but malloc, calloc and
realloc are illegal, I can live with it.  I use memcpy and memset in my
debugging operator new; if the draft declares this "undefined behavior",
my programs will still be "practically" portable, even if not formally
so, since there is no reasonable way an implementation is going to use
operator new in those functions.  And implementations which do
unreasonable things just to cause the user problems don't last long on
the market.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>|>  >dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
>|>  >
>|>  >|>  #include <malloc>
>|>  >|>  #include <new>
>|>  >|>  #include <iostream>
>|>  >|>
>|>  >|>  void *  operator new(size_t bytesReq) {
>|>  >|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
>|>  >|>   return malloc(bytesReq);
>|>  >|>  }
...
>what is the "official" status of the above example: undefined behavior?

Well, assuming that you substitue `#include <cstdlib>' for
`#include <malloc>', and assuming that you add `using std;',
and assuming that you handle zero-sized allocations...

As I interpret the draft, the status is that the program
is well-formed, with unspecified behaviour.  The unspecified
behaviour might lead to further undefined behaviour (accessing `cerr'
before it has been constructed), or to behaviour that exceeds the
resource limits of the implementation (infinite recursion).  Thus the
draft imposes no requirements on implementations with regard to the
behaviour of this program.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]