Some issues / problems

[Markus Schaber]

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.

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;


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 (...) {}



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


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.


There are still some few warnings I'll investigate and bring up in a
later email.


Thanks for your patience and your great work,
Markus

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.

[Rudolf Schreiner]

Post by Markus Schaber
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.

Just for your info: MICO is indeed actively worked on. We are currently
involved in some ports of large scale, mission critical systems to
MICO. As part of one of these projects, we will soon release a new
MICO version.
The silence on this list does not mean that nothing is happening. Just
what's happening is too "sensitive" for a public list...

Cheers,
Rudi
------------------------------------------------------------------------
Rudolf Schreiner, CTO, ObjectSecurity Ltd.
St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS
Tel. [phone], Fax. [phone]
USA: Tel.[phone], Fax [phone]
***@objectsecurity.com, www.objectsecurity.com
------------------------------------------------------------------------

[Karel Gardas]

Hi,

Post by Markus Schaber
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...)

Post by Markus Schaber
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!

Post by Markus Schaber
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!

Post by Markus Schaber
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)’
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.

Post by Markus Schaber
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).

Post by Markus Schaber
There are still some few warnings I'll investigate and bring up in a
later email.

That would be great!

Post by Markus Schaber
[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]

Hi Marcus,

I'm cc-ing mico-devel, since this might be of interest to others as well.

Hi, Karel,

Post by Karel Gardas

Post by Markus Schaber
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...)

OK, then I'll have a look into this issue. However, I'll be on vacation
the next week, so don't hold your breath.

That's perfectly OK. I think this might be a little bit destabilizing
change and so this will not go into 2.3.13 anyway. FYI: 2.3.13 should be
out sometime in next 2 weeks or so.

Post by Karel Gardas
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.

I suspected something like this.

Post by Karel Gardas
Hmm, are you sure 2.3.12 release is not affected.

Actually, not 100%, I'll recheck. It might be that I accidentally used
a internally patched version.

Post by Karel Gardas
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).

Yes, it seems that they preprocess a file that contains "#include
<math.h>", and grep for the word "finite". Somehow this does not work.
I currently have autoconf-2.61 installed, I hope that this is not
breaking anything.
The weird thing is that the check for the finite function itself works
fine (minus a warning).
configure:15167: checking for finite
configure:15223: gcc -o conftest -O2 -Wall conftest.c -lreadline -lncurses -lssl -lcrypto -ldl -lm >&5
conftest.c:81: warning: conflicting types for built-in function 'finite'
configure:15229: $? = 0
configure:15247: result: yes
I'll see what I can do, but I don't have much ideas ATM.

Two notes:

1) autoconf-2.13 is required

2) for configure.in -> configure generation you cannot use just
`autoconf', but use bootstrap.sh script which takes care of it. It also
does its best to find appropriate autoconf version for you.

Thanks!
Karel

[Markus Schaber]

Hi, Karel,

Post by Karel Gardas
I'm cc-ing mico-devel, since this might be of interest to others as well.

Ah, good, I intended to send my mail to mico-devel, it seems that I got
the headers wrong, sorry.

Post by Karel Gardas

OK, then I'll have a look into this issue. However, I'll be on vacation
the next week, so don't hold your breath.

That's perfectly OK. I think this might be a little bit destabilizing
change and so this will not go into 2.3.13 anyway. FYI: 2.3.13 should be
out sometime in next 2 weeks or so.

Ah, good news. Let's hope that 2.3.14 will be a little quicker.

Post by Karel Gardas

[finite() autoconf issues]

1) autoconf-2.13 is required

Ok, so I'll have to install that version. It seems that debian carries
a "autoconf2.13" package.

Maybe it does make sense to update mico to a newer autoconf after the
release.

Post by Karel Gardas
2) for configure.in -> configure generation you cannot use just
`autoconf', but use bootstrap.sh script which takes care of it. It also
does its best to find appropriate autoconf version for you.

Good hint, thanks.


Regards,
Markus