stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: Problem with num_put on zOS
Date Wed, 01 Mar 2006 18:40:04 GMT
Nicole Willson wrote:
> As far as I know the library was configured for zOS using sp6 code and that
> was simply adapted to sp7.  I guess I don't know what you mean by
> configuring the library.  I thought that was what I was doing by changing
> the rwc_std_11d.h file.

You can hardly expect to do it right just by tweaking the macros.
There are dozens of them and many are #defined in response to very
subtle conditions. In addition, there are many new tests in the
latest version of the library that didn't exist back then. You need
to compile, link and run the configuration tests to make sure the
set is complete and their results make sense and are optimal.

The library can adapt to a lot of bugs and limitations but the
workarounds it uses aren't always as robust or as efficient as
if the bugs didn't exist to begin with.

For instance, the library might be able to adapt to the function
wcslen() not being defined in the C library by defining its own
simple loop. The C library version is almost always going to more
efficient (typically written in assembly). An earlier version of
an OS may not provide wcslen() but a newer might. Using a config
header obtained on the older OS with the new one will work (if
this were the only difference) but will cause the library to use
the inefficient workaround when the more efficient libc function
could be used instead.

Anyway, this is just one of dozens of examples, and a pretty harmless
one. I could easily come up with much more sinister cases. Suffice it
to say that it's inappropriate and wrong (not to mention incredibly
tedious) to try to port the library (any of our libraries, in fact,
but stdcxx is likely to have the most serious problems) to a new
compiler or OS by manually tweaking the autoconfiguration macros.


View raw message