Re: eCos uSTL port patch for review

[cetoni GmbH - Uwe Kindler <uwe dot kindler at cetoni dot de>]

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