This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: eCos uSTL port patch for review
- From: cetoni GmbH - Uwe Kindler <uwe dot kindler at cetoni dot de>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: ecos-patches at sourceware dot org
- Date: Tue, 04 Aug 2009 07:56:56 +0200
- Subject: Re: eCos uSTL port patch for review
- References: <17177634.682341249033390443.JavaMail.servlet@kundenserver> <4A72C639.8000001@dallaway.org.uk> <4A773539.4050408@dallaway.org.uk>
Hi John,
thanks for reviewing the uSTL port.
a) I would prefer this package to be located under language/cxx/ustl/ to
avoid confusion with the GNU C pre-processor. An easy change.
no problem - done
b) Most of the diff between this package and the master uSTL sources
concerns potentially undefined pre-processor macros. Clearly it's
preferable to modify the original sources as little as possible.
Defining certain macros to "0" in config.h brings its own dangers. Are
the changes you have made to the pre-processor configuration tests
acceptable upstream by the uSTL maintainer(s)?
Could you please explain what do you mean by "dangers". Do you mean
undefining pre-processor macros (like #undef HAVE_INT64_T) could cause
trouble to other eCos packages or to eCos build process? Normally the
config.h file is generated automatically by the bsconf tool but I
provide an manually edited config.h file that is optimized for eCos
support like it is done by penrillian for S60
(http://www.penrillian.com/content/view/82/73/). Normally it should not
be necessary to undefine a macro because if it exists, then we would
like to use it and if it does not exist, then it is already undefined.
So do you mean I should remove all #undefs?
Do you mean you would like to see the #ifdef __GXX_RTTI and #ifdef
__EXCEPTIONS stuff in the uSTL mainline? I will ask the maintainer if
these changes are acceptable. Would this be a showstopper for import
into eCos CVS if these changes are rejected?
c) CYGPKG_USTL_TESTS should list the executable names (eg "tests/bvt00")
rather than the source file names for compatibility with the eCos
Configuration Tool.
no problem - done
d) Are you (or anyone else) aware of any compatibility issues arising
from the switch to C99 vsnprintf() behaviour?
O.k., I understand that this change may be critical for existing eCos
applications and needs intensive testing. To keep the risk to a minimum
I have the following tree proosals:
1)
Make the C99 vfnprintf() behaviour an option. Disable this option by
default. This would ensure that the existing and well tested behaviour
would be used. If the uSTL package is pulled in, then this package would
require the C99 implementation to get activated.
2)
Provide an additional C99 compliant vsnprintf() implementation in the
uSTL package (i.e. from http://www.jhweiss.de/software/snprintf.html)
that will be used by uSTL format functions. This would increase code
size for final ecos application.
3)
Mix 1) and 2) - that means, by default and without uSTL the default
vfnprinf() behaviour is active. If uSTL becomes active, then the new C99
compliant vfnprintf() behviour becomes active. If the user prefers the
default vfnprintf() behaviour if uSTL package is active, then the
additional C99 compliant vsnprintf() implementation will be compiled
into the eCos library.
What do you think about these proposals? I would like to go with 1. It
would ensures the default behaviour for all existing eCos applications
and for future applications that do not use uSTL and it would provide a
C99 compliant implementation for uSTL support and would not increase
code size of the final eCos image.
e) Does everything behave correctly when built with "-fexceptions -frtti" ?
I will test this now and then tell you.
Regards, Uwe
Uwe Kindler
Software Engineering
cetoni GmbH
Automatisierung und Mikrosysteme
Am Wiesenring 6
D-07554 Korbussen
Phone: +49 (0) 36602 338 28
Fax: +49 (0) 36602 338 11
Email: uwe.kindler@cetoni.de
Web: http://www.cetoni.de
Handelsregister Jena HRB 202566
Ust.-Ident-Nr. DE 1505 26212
GeschÃftsfÃhrer:
Tilo Kunze