Hey James,
No problem with this, Axel already has a CLA on file.
Cheers,
Gareth
James Berry (JIRA) wrote:
[
http://issues.apache.org/jira/browse/XERCESC-1428?page=comments#action_66685 ]
James Berry commented on XERCESC-1428:
--------------------------------------
Axel,
Thanks!
I checked your code in on branch jberry/3.0-unstable.
As a formality, would you mind answering the following contributer questions:
As the community becomes more and more concerned about the license and
copyright issues related to code contribution, we would be more than happy to
check in the patch submitted once you have kindly completed the followings:
.Who is your employer?
.Did you write the code that you wish to contribute to Apache?
If not, please identify the complete details of the code's source
and of any licenses or restrictions applicable to the code.
.Do you have the right to grant the copyright and patent licenses
for the contribution that are set forth in the ASF v.2.0 license
(http://www.apache.org/licenses/LICENSE-2.0)
.Does your employer have any rights to the code that you have
written, for example, through your contract for employment?
If so, has your employer given you permission to contribute the
code on its behalf or waived its rights in the code?
.Are you aware of any third-party licenses or other restrictions
(such as related patents or trademarks), that could apply to your
contribution? If so, what are they?
If you anticipate you'll be able to continue to contribute regularly, I'd ask
that you also fill out the apache contributer's agreement, here:
http://www.apache.org/licenses/icla.txt, as referenced on this page:
http://www.apache.org/licenses/.
Thanks,
James.
new iconv-transcoder algorithm
------------------------------
Key: XERCESC-1428
URL: http://issues.apache.org/jira/browse/XERCESC-1428
Project: Xerces-C++
Type: Improvement
Components: Utilities
Environment: linux
Reporter: Axel Weiss
Priority: Minor
Attachments: transcoder-179120.diff, transcoder-179120.diff
James Berry wrote:
What if you make this initial buffer a static buffer? And allocate
the exact size needed at the end?
That keeps the memory cost constant, at the expense of a guaranteed
extra string copy.
For cases where you exceed the static buffer size, continue to do
your size-doubling on overflow; for the cases where you exceed the
static buffer size, you'll continue to use excess memory.
I think this tradeoff would be worth it...
Ok, it now starts with a local buffer on the stack and creates a copy with the
exact size needed, if this buffer was not exceeded. Otherwise, an always
doubling buffer enlargement is performed, resulting in returning an excess
buffer for the result.
The patch is against 3.0-unstable-179120.
Axel
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
