Comments (5)
Currently the Eclipse OMR project uses <> for system include files and "" for our project header files. I believe we are not violating any spec with this usage pattern but if there is a best practice we could be following that is something we would consider. Do you have any more details?
from omr.
I suggest to reconsider the consequences of the following wording from the section "16.2 Source file inclusion" in the standard specification for the programming language "C++".
…
The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
…
- How do you think about to avoid "a duplicated file search" here?
- Would you like to restrict the searched directories for header files of your software?
from omr.
Boiling that down: the point would be to avoid searching the "current directory" for our headers by using angle brackets rather than the quoted form? Given the fuzziness of the notion of the "current" directory when compiling, I can sort of see the argument. But I also think most people would find the change odd.
Anyone feel strongly we should go down this path? Otherwise I vote we keep it as is at least for now; we've managed to go 20+ years without running into problems with the current directory on the search path...
from omr.
Given the fuzziness of the notion of the "current" directory when compiling, I can sort of see the argument.
I would generally prefer to exclude the potential for the inclusion of header files from unexpected directories. Can such a security detail become a bit more important occasionally?
from omr.
Angela pointed out that the same standard specification for C++ programming you pulled text from also contains the following recommendation (point 7 on page 403):
[ Note: Although an implementation may provide a mechanism for making arbitrary source files available to the < > search, in general programmers should use the < > form for headers provided with the implementa- tion, and the " " form for sources outside the control of the implementation. For instance:
#include <stdio.h> #include <unistd.h> #include "usefullib.h" #include "myprog.h"
— end note ]
OMR makefiles assume they're being run in the current directory and would break for a number of reasons if they weren't being run there.
The security argument feels pretty weak to me: any security risk would come from someone with access to the platform to rebuild OMR / language runtime and they could just as easily modify the makefile to include whatever directory they want on the include path. Security details are definitely important, but I don't see this recommendation providing any real security improvement.
In summary, using angle brackets on OMR header includes would seem to serve no purpose other than to specifically go against the general recommendation Angela pointed out above, which virtually every C/C++ programmer is used to.
I think we should keep things as they are.
from omr.
Related Issues (20)
- Update bit manipulator functions to use built-ins when supported
- Add BenefitInliner source files to the UMA builds
- Add omrtime API for process time HOT 3
- tril tests are not able to detect the right CPU level on Z
- Reuse OMRPORT_TIME_DELTA_IN_NANOSECONDS in omrtime.c HOT 1
- x86: make improvements to port library for cpu identification
- Implement omrsysinfo_get_process_start_time for z/TPF HOT 4
- Agenda for June 20, 2024 OMR Architecture Meeting
- TRIL tests on z/OS generates non-standard NaN formatting HOT 3
- Linux RISCV64 PR Builds Failing: Missing libfakeroot_1.31-1.2 HOT 3
- Allow '[' and ']' to be used for specifying options in subset
- Hang in SanityTest
- Define fmax/fmin/dmax/dmin opcode specifications HOT 2
- Use 32-bit XORRegReg to zero registers on x64
- Consolidate ValuePropogation paths for with and without off-heap
- Upgrade Python on CI nodes to at least version 3.2
- Revisit optimizations in IntegerMultiplyDecomposer.cpp
- Supported C++ features document is out of date HOT 10
- Revisit coding standards HOT 1
- SEGFULT in portLibrary.str_printf() calls HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omr.