🚀 go-pugleaf

I would like to ask for comments on three easy questions illustrated 
by the following piece of code:
 
template <class I, class T>
void mVect<I,T>::resize(I new_size) {
   T *old = v;
   v = new T[new_size];    // T *v is a private member of mVect  
   int size_of_elem = sizeof(T);    // <--- question 3 
   // 
   // do something 
   // 
   delete[] old;     // <--- questions 1 & 2 
} 
 
I have the following questions:
1. Is it absolutely robust and portable to delete[] old, even
   if a previous call was for new_size == 0 (or if v was allocated
   by the ctor for the size == 0) ?
	In other words: is it guaranteed that:
   (v = new T[0]) == 0;
2. Is it correct to assume that no destructor is called by this statement
	if old was set as: old = new T[0]  ??
3. Is there any risk involved in using sizeof(T) in this statement ?
 
I used to be sure that the answers are:
1. Yes
2. Yes
3. No
 
However, I have recently started to port an application developed
with SunPro (previously ported to Borland and checked with the
Bounds-Checker32).
The Watcom code blows-up on the delete[] statement (if a previous
call was for new_size == 0) and gives a warning whenever it sees the 
sizeof(T).

If the answer for quaestions 1 and 2 is negative then I would like to
know the reason why the standard does not require new to return 0
for zero_size array of objects.
This would work nicely with the delete guaranteed to be safe for
the 0 argument.
If there is a good reason for allowing new to return "anything" in such
situations then one should add to every ctor setting a ptr to 0
(which indeed made the Watcom version of my application running).
 
Thanks in advance for your time.
 
Marek
-- 
                  Marek Makowski  | Email: marek@iiasa.ac.at
         International Institute  | Phone: (+43-2236) 807.561
    for Applied Systems Analysis  | Fax:   (+43-2236) 71.313
       A-2361 Laxenburg, Austria  | Web: http://www.iiasa.ac.at
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]