[
https://issues.apache.org/jira/browse/YARN-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562708#comment-15562708
]
Allen Wittenauer commented on YARN-5704:
----------------------------------------
bq. though VS is the only C compiler I know of that (until recently?) doesn't
support most of C99
It's a bit more complex than that. Let's dig into the details.
GNU, as usual, does whatever the hell GNU wants. Unless one tells it
otherwise, gcc's supported features changes pretty much every release and tends
to be wildly unpredictable. This can result in some interesting side effects
for advanced programmers. e.g., tricks to build custom memory allocators were
recently 'optimized' away.
Most non-GNU-based compilers that I've worked with default (usually) to C89
with extensions (e.g., C++ style comments). This is primarily due to C99 being
incompatible with previous C standards. (new keywords, int declarations, ...)
In order to tell the compiler that no, really, we want to use C99 and not to
barf on the incompatbilities, then (minimally) a flag has to get passed or
(maximally) a different compiler executable (hi DPW) needs to get used. If we
want to declare this code base as being C99 then we need to tell cmake to make
sure we're using a C99 compiler. Until we do that, this code is defaulting to
non-C99.
In addition, we would also need to audit the code to make sure that we really
are writing C99. That shouldn't be too difficult, but it is something that
needs to happen. Minimally, compiling with something that isn't gcc in C99
mode would likely highlight the problem areas since gcc tends to be...
forgiving.... without --pedantic.
Bonus: telling cmake that we're doing C99 is sort of a mine field, depending
upon which version of cmake is in use.
bq. If there are restrictions on the subset of C this should use, the compiler
needs to enforce them.
Totally agree. But the end result is we can't just declare we're writing C99
and then expect the compiler to magically know that.
Anyway...
As I said above, my #1 issue with this patch is the lack of a unit test. If
someone wrote a method that determined if experimental/insecure features were
enabled in the heart of the Java authentication code based upon a site.xml
setting, I'm fairly confident that the contributor would be adding and anyone
reviewing would flag the need for even a basic unit test, if not true, false, &
broken input tests. In one sense, I understand why the community at large
treats the non-Java code as coming from a lower caste, but c-e is one of the
most important parts of the source base. It really does require extra scrutiny
and the lack of even a basic unit test when it's clearly possible should be a
huge red flag.
> Provide config knobs to control enabling/disabling new/work in progress
> features in container-executor
> ------------------------------------------------------------------------------------------------------
>
> Key: YARN-5704
> URL: https://issues.apache.org/jira/browse/YARN-5704
> Project: Hadoop YARN
> Issue Type: Task
> Components: yarn
> Affects Versions: 2.8.0, 3.0.0-alpha1, 3.0.0-alpha2
> Reporter: Sidharta Seethana
> Assignee: Sidharta Seethana
> Attachments: YARN-5704-branch-2.8.001.patch, YARN-5704.001.patch
>
>
> Provide a mechanism to enable/disable Docker and TC (Traffic Control)
> functionality at the container-executor level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
