[Monotone-devel] Re: recent sunpro changes

[Patrick Mauritz]

On Fri, 2005-08-12 at 12:21, Nathaniel Smith wrote:
> Some questions about the recent changes to support SunPro:
>   - why remove lots of files from m4/?
because "autoreconf -i" installed other versions of them. imho either
the repo should contain all (incl. configure and Makefile.in) or no
generated/copied files. (personal preference for the latter)
I'm not sure if I got all of them (I'm quite sure I didn't), and I'll
look at this again after I know which way to go.

>   - is -Wall disabled by default, now?  If so, please re-enable it?
I'll make a test and re-add it. do you want -Wshadow, too? (not enabled
by -Wall, I think)

>   - MM(): __func__ is the ISO standard equivalent to
>     __PRETTY_FUNCTION__ (but worse, so we should prefer
>     __PRETTY_FUNCTION__ when available).  I don't know if there's any
>     way to make it work without typeof(), though?
there are some hacks to make a typeof() with msvc, maybe there are some
for sunpro, too.. for the time being, maybe just printing __func__ is
the way to go?
I hesitated to do this by default because the semantics of MM() confused
me, it's a very complex piece of magic

>   - All the explicit new[]/delete[]'s do not make me smile :-(.
me neither.

>     Even if auto_ptr doesn't work, surely we can do better with some
>     sort of smart pointer.
a possible solution might be to special case those functions for
lengths, as usually a 20/40byte string is passed.. maybe templates?
but that was too complex for me to do, esp. without prior discussion -
the current code is an easy (but ugly) solution that "works".

>   (And I'm still not really convinced that
>     you can't say "void foo(int x) { int arr[x]; ...}" in standard
>     C++, but I guess there isn't much to do about that...?)
--- testcase ---
int foo(int x) {
  char bar[x];
}
----------------
divert% g++ -pedantic -c test.cc
test.cc: In function `int foo(int)':
test.cc:2: error: ISO C++ forbids variable-size array `bar'

>   - Botan changes (headers): please send upstream?  they look a little
>     dubious, though; does
>        #include <cstring>
>       +#include <string.h>
>     really make sense?
I'll retest that.


thanks,
patrick mauritz