Hi,
Markus Schaber wrote:
> Hi,
>
> We are using mico for one of our projects inhouse, and we falsely got
> the impression that mico was not maintained any more (no releases,
> debian packages vanishing, and no time to really investigate the
> issues.). Yesterday, I had some time to look at the mico website, and
> found out that mico still is actively worked on, and I think that we
> may have something to contribute.
>
> Building mico (latest release) and our software with GCC 4.3.1, we
> stumbled over some bugs and warnings. We fixed them inhouse by patching
> the mico source, being unaware that some of them were already fixed in
> darcs HEAD.
>
> The first issue were lots of warnings about deprecated casts of string
> literals to char*, all of those seem fixed in mico head.
>
> Some other issue are the strict alias warnings, which are worked-around
> with -fno-strict-aliasing both inhouse and in darcs HEAD. As this is
> only a workaround which also disables some optimizations, we intend to
> "really" fix those issues, but I can't give any promise or timeline.
> Also, I don't know whether someone else is working on this issue.
as far as I know nobody is working on strict aliasing issue yet. I've
investigated this just shortly few years ago and was satisfied with the
-fno-strict-aliasing workaround although as you mentioned this is not
optimal solution. If you do have idea how to fix it, I'm happy to
discuss it with you here. (I don't remember exactly, but IIRC it was
something to do with marshaling/un-marshaling using unions...)
> The next one was the issue in idl/codegen-midl.cc where insert_guid()
> was writing into a string constant. The fix you provided in HEAD seems
> to look like a memory leak to me, as the string should be freed with
> CORBA::string_free() at the end.
>
> We had a different fix for that, which also has the advantage that it
> does allocate the buffer on the stack which is cheaper on most
> platforms. (Patch against HEAD)
>
>
> diff -rN -u old-head/idl/codegen-midl.cc new-head/idl/codegen-midl.cc
> --- old-head/idl/codegen-midl.cc 2008-07-08 11:08:16.179497000 +0200
> +++ new-head/idl/codegen-midl.cc 2008-07-08 11:08:18.419637000 +0200
> @@ -1604,7 +1604,7 @@
>
> void CodeGenMIDL::insert_guid()
> {
> - char* szGUID = CORBA::string_dup("(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)");
> + char szGUID[39] = "(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)";
>
> #if defined(_WIN32) && !defined(__MINGW32__)
> GUID g;
>
Applied!
>
> Another issue was a missing include[1]. "throw.h" uses strcmp() without
> including <string.h>.
>
>
> diff -rN -u old-head/include/mico/throw.h new-head/include/mico/throw.h
> --- old-head/include/mico/throw.h 2008-07-08 11:08:16.443513500 +0200
> +++ new-head/include/mico/throw.h 2008-07-08 11:08:19.207686250 +0200
> @@ -25,7 +25,7 @@
> #define __mico_throw_h__
>
> #include <stdarg.h>
> -
> +#include <string.h>
>
> #ifdef HAVE_EXCEPTIONS
> #define MICO_CATCHANY(x) try { x; } catch (...) {}
>
Applied!
>
>
> The last one for now is an exception declaration problem. Unless I
> messed up something here, it seems that only HEAD is affected, and not
> the stable release. I had a quick fix to make it compile, but I think
> that the real problem is a misdetection of HAVE_FINITE_PROTO.
>
> /usr/include/bits/mathcalls.h:205: error: declaration of ‘int finite(double)
> throw ()’ throws different exceptions
> ../include/mico/util.h:222: error: from previous declaration ‘int
> finite(double)’
>
> The ugly, broken quick fix is:
>
> diff -rN -u old-head/include/mico/util.h new-head/include/mico/util.h
> --- old-head/include/mico/util.h 2008-07-08 11:08:16.447513750 +0200
> +++ new-head/include/mico/util.h 2008-07-08 11:08:19.211686500 +0200
> @@ -219,7 +219,7 @@
> #endif
>
> #ifndef HAVE_FINITE_PROTO
> -extern "C" int finite (double);
> +extern "C" int finite (double) throw();
> #endif
>
> #ifndef HAVE_FTIME_PROTO
>
Not applied as this breaks build on any platform without finite with
throw (verified on SunOS 5.11 + GNU C++ 3.4.3). I think this issue needs
proper patch in MICO's configure machinery.
>
> As I have no clue of that autoconf stuff, I'm not sure yet whether the
> problem is on my side in my environments here.
>
Hmm, are you sure 2.3.12 release is not affected. That's strange, since
there is no change on this front since it IIRC. Anyway, to start with
autoconf machinery you will need to install autoconf-2.13 and then study
configure.in and aclocal.m4. The former file uses some macros defined in
the later file. I think in the worst case you will need to write your
own M4 macro detecting finite prototype properly. Currently it seems to
be done by grepping math.h header file (in configure.in).
> There are still some few warnings I'll investigate and bring up in a
> later email.
That would be great!
> Footnotes:
> [1] One of the changes of either newer GCC/listdc++ or newer glibc
> against older versions seems that they removed some implicit includes.
> In earlier versions of the standard library, some headers
> "accidentally" included other headers, so code that missed some
> #include-directives actually compiled. Also, incidentally including the
> missing header directly (or indirectly) in your own code before the
> broken header "hides" the missing include, so such bugs can linger in
> the code for decades before being noticed.
I don't have any problem with such changes as they usually push
developers to cleanup the source code. :-)
Thanks for your patches!
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
_______________________________________________
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
