[
https://issues.apache.org/jira/browse/HADOOP-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027346#comment-14027346
]
Haohui Mai commented on HADOOP-10389:
-------------------------------------
{quote}
Currently, the libraries we depend on are: libuv, for portability primitives,
protobuf-c, for protobuf functionality, expat, for XML parsing, and
liburiparser, for parsing URIs. None of that functionality is provided by the
C++ standard library, so your statement is false.
A lot of this code is not new. For example, we were using tree.h (which
implements splay trees and rb trees), previously in libhdfs. The maintenance
burden was not high. In fact, it was zero, because we never had to fix a bug in
tree.h. So once again, your statement is just false.
bq. htable.c got a review because it is new code. I would hardly call reviewing
new code a "maintenance burden." And anyway, there is a standard C way to use
hash tables... the hcreate_r, hsearch_r, and hdestroy functions. We would like
to use the standard way, but Windows doesn't implement these functions.
{quote}
I fail to understand what point you're try to make. My point is that you can
write much less code in a modern language with better standard libraries, which
makes things much easier to review and maintain. For example, when you're
working on trunk, how many times you have to put up a 200kb patch like this
jira? How many big patches in this feature branch? Please be considerate of the
reviewers of the patch.
{quote}
Firstly, the challenge of maintaining a consistent C++ coding style is very,
very large. ...
For example, exceptions harm performance...
C++ library APIs have binary compatibility issues....
{quote}
Arguably you can implement what you want in C++ and C equally well. Coding
styles and performance can be a problem.
However, before any of them I'm much more concerned about the correctness of
the current code. For example, I'm seeing the code allocates {{hadoop_err}} on
the common paths, and it has to clean it up on all error paths. I'm also seeing
many calls to {{strcpy()}}, as well as calls to {{*printf()}} with non constant
format strings.
My question is that (1) whether the code contains no memory leak, no buffer
overflow, and no format string overflow? (2) whether the code always passes the
function pointer with the correct type? I'm perfectly happy to +1 your patches
as long as you can show your code is indeed free of these common defects.
Given the amount of code in the branch, it might be an issue worth looking at
some point, compared to when a merge vote is called.
> Native RPCv9 client
> -------------------
>
> Key: HADOOP-10389
> URL: https://issues.apache.org/jira/browse/HADOOP-10389
> Project: Hadoop Common
> Issue Type: Sub-task
> Affects Versions: HADOOP-10388
> Reporter: Binglin Chang
> Assignee: Colin Patrick McCabe
> Attachments: HADOOP-10388.001.patch, HADOOP-10389.002.patch,
> HADOOP-10389.004.patch, HADOOP-10389.005.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
