Re: Compiling with Sun's compiler under Solaris fails

[Moritz Borgmann]

> | "mxarray.h", line 75: Warning: Identifier expected instead of "}".
>
> I think there is an extra comma at the end of an enum decl.  I think
> the patch to mxarray.h below should fix this problem.

yep, thanks. Haven't seen that problem any more.

> | "ov-builtin.h", line 85: Warning: Too few arguments in macro
> | DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA2.
>
> Does to ov-builtin.h below avoid this warning?  If not, then maybe
> there is a compiler option that will avoid it.

I still see tons of these :-( Seems to be some silly language 
definition issues in C99 or whatnot.

Find a patch below (stupid workaround). Shouldn't hurt anybody else.

Same principle could be applied to DO_DOUBLE_CONV in 
src/oct-stream.cc, DO_BITSHIFT in src/bitfcns.cc.

> | "../liboctave/Array.h", line 101: Warning (Anachronism): Formal
> | argument cmp of type extern "C" int(*)(const void*,const void*) in
> | call to octave_qsort(void*, unsigned, unsigned, extern "C"
> | int(*)(const void*,const void*)) is being passed int(*)(const
> | void*,const void*).
> | "../liboctave/Array.h", line 490:     Where: While instantiating
> | "Array<double>::ArrayRep::qsort(int(*)(const void*,const void*))".
> | "../liboctave/Array.h", line 490:     Where: Instantiated from
> | non-template code.
>
> I think you'll have to find a compiler option to avoid this warning,
> or suggest a patch.

Sun has some extensive discussion up:

http://docs.sun.com/source/819-3689/Ch3.Std.html#pgfId-18041

I have the feeling that if this problem was to be fixed, it would 
require quite a lot of changes. I see a dozen or so of these 
warnings. But they can be safely ignored at this point.

BTW, as a question of general policy: do you actively strive to 
eliminate warnings, i.e., do you welcome bug reports about warnings? 
I've seldomly seen code so devoid of warnings, that's why I'm asking 
;-)

> Does the patch to graphics.h.in and graphics.cc below fix this
> problem?

Can't tell yet, as I'm seeing another issue in data.cc right now (see 
post to bugs).

> BTW, it is best to report bugs to the address@hidden list.

thanks for the pointer. Have already reported more bugs there. Was 
just not sure in this case if I'd found a bug or if it was just my 
stupidity ;-)

If this thread is getting too technical, please move to bugs or maintainers.

Thanks again!

Moritz

Index: ov-base.h
===================================================================
RCS file: /cvs/octave/src/ov-base.h,v
retrieving revision 1.106
diff -u -u -r1.106 ov-base.h
--- ov-base.h   24 Oct 2007 00:32:44 -0000      1.106
+++ ov-base.h   25 Oct 2007 02:58:38 -0000
@@ -60,8 +60,11 @@

 // T_ID is the type id of struct objects, set by register_type().
 // T_NAME is the type name of struct objects.
+
+#define OV_NOOP
+
 #define DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA \
-  DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA2 ( )
+  DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA2(OV_NOOP)

 #define DECLARE_OV_BASE_TYPEID_FUNCTIONS_AND_DATA \
   DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA2(virtual)