How to force Visual Studio preprocessor case sensitivity with #includes? - c++

If you have a header file named ThisIsAHeaderFile.h, the following will still locate the file in Visual Studio:
#include <ThisIsAheaderFile.h>
Is there a way to enforce case sensitivity so that the #include will result in an error?

You can't, because the Windows file system is itself case-insensitive.
If you could get into a situation where you had both RICHIE.h and richie.h, it might make sense to control case sensitivity, but you can't.

I would like to point out that this is not an unsolvable problem as many tries to point out to the OP. The case insensitivity is beside the point. The point is as Lorenz03Tx explains in a comment, even though the file system is case insentitive the case is retained, so it can be controlled.
Such a counter measures is really great to have when doing cross platform development, and prevents much after work when the code is compiled for the other platform. Not to forget that making the build process more picky you would induce better habits for the developers, as they gradually will be more consistent how they include and name files.
TL;DR
One solution is to use a script that simply scans the source files for include statements and tries to match them along the include paths. Such a script could be added to visual studio post-build events, and thus run at every build, or (inspired by krlmlr) use the preprocessor of a compiler that enforce case sensitivity.

It is (used to be?) possible to create files with the same name but case differences on NTFS. Maybe someone with cygwin can verify this.
MSDN
Even then, however, it's impossible to access more than one of these at a time from a normal Windows application.

While it might not be possible to enforce this from within Visual Studio, one could implement a quick check by running only the preprocessor on the C/C++ source. This will run quickly enough to be practicable even as post-commit hook in a version control system, and err if the case in file names has been mismatched. So:
Configure your build system in Linux to support preprocessor-only runs (-E with gcc/g++)
Implement a preprocessor-only run as post-commit hook, triggering an early notification to the responsible person and/or to someone willing to routinely fix these errors
Of course, this assumes a VCS as central storage for the code.

Both FAT and NTFS are case insensitive file systems. Foo and fOO are the same file as far as they are concerned. Although the Windows OS will preserve the case you use for a file. If you name a file ThisIsAheaderFile.h it will show up that way in the file system. Although all system function calls to open that file can use any casing they want.

Also having similar problem when trying to build under linux; not full solution...
If you Find in Files #include by VS and copy result to textarea, you will get sorted CSV with include file name, original path and list of files in 3rd column (columns are tab delimited)
Easy to check solution/wide and in case there are not much case problems it should be easy to replace them?
function readIncludes(t)
{
var s = t.value.split('\n');
var res = {};
for(var r in s)
{
if (r == 0) continue;
var dq = s[r].indexOf('(');
var p = s[r].substr(0, dq);
var p2 = s[r].indexOf(':', dq);
p2 = s[r].substring(0, p2);
dq = s[r].indexOf('#', dq);
var i = s[r].substr(dq);
var ip = i.replace(/#include\s+/, "");
if (!ip) continue; // *#includes.*
var st = '<>""';
if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
st = st[st.indexOf(ip[0]) + 1];
ip = ip.substr(1, ip.indexOf(st, 2) - 1);
if (!ip || ip[0] == '/') debugger
if (!res[ip]) res[ip] = [];
res[ip].push(p2);
}
var resSorted = [];
for(var r in res)
{
var shortR = r.replace(/.+[\\/]/, ""); // include file
resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
}
t.value = resSorted.sort().join('\n'); // sort again long lines of results
}
html,body,textarea {
width: 100%;
height: 100%;
white-space: nowrap;
}
<textarea onchange="readIncludes(this)">
</textarea>

Related

recursive_directory_iterator's skip_permission_denied option appears to be ignored on macOS?

Using C++20 and std::filesystem::recursive_directory_iterator on macOS, this code:
for (auto& f : recursive_directory_iterator(getenv("HOME"), directory_options::skip_permission_denied)) {
// dummy
}
Which should, according to my understanding of the documentation, skip directories which it does not have permission to recurse into, encounters an error upon trying to recurse into ~/Library/Application Support/MobileSync/.
However:
in recursive_directory_iterator::operator++(): attempting recursion into "/Users/t/Library/Application Support/MobileSync": Operation not permitted
I assume this means that there is some permission / security feature in place that the iterator will not skip over even if skip_permission_denied is present - what might this be, and how would I cleanly make the iterator skip over directories that cause it to break regardless of permissions?
I could manually disable_recursion_pending() when encountering known directories like MobileSync or .Trash that cause this problem, but that would be a messy solution compared to being able to detect in advance when a directory will cause this issue.
I'm afraid there is no easy way around it, as the iterator is "closed" on error so a post-error disable_recursion_pending will not help. I opened an issue for libcxx (https://github.com/llvm/llvm-project/issues/48870) and libstdc++ (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533) that got worked on, but the libcxx one was not fixed yet, and even then it would have to make it into macOS as on macOS the standard library is part of the system.
One admittedly ugly but possible non-hardcoded workaround would be to blacklist dynamically and retry e.g. somewhere along the lines of:
// ugly workaround to iterate the home dir on macOS with std::filesystem:
std::set<fs::path> blacklist;
while(true) {
fs::path lastPath;
try {
for(auto rdi = fs::recursive_directory_iterator(getenv("HOME"), fs::directory_options::skip_permission_denied);
rdi != fs::recursive_directory_iterator();
++rdi) {
auto& de = *rdi;
lastPath = de.path();
if(blacklist.count(de.path())) {
rdi.disable_recursion_pending();
}
else {
// collect info you need here
// ...
}
++rdi;
}
}
catch (fs::filesystem_error& fe) {
if(!blacklist.insert(lastPath).second) {
// exception on same path, double error, something went really wrong
break;
}
else {
// we blacklisted a new entry, reset your collected info here,
// we need to restart
// ...
continue;
}
}
// we are through and managed to get all info
// ...
break;
}
Of course this is a lot of code working around something that should be a single line and only needed on macOS, so if one uses this at all, it should be wrapped away.
One subtle thing to be aware of is that a range-based-for uses the fs::begin(fs::recursive_directory_iterator) function that creates an "invisible" copy, and makes it impossible to call disable_recursion_pending() on the correct instance. This is the reason why a regular for-loop is used.
Another ugly part of that workaround is that besides the standards suggestions neither path1() nor path2() of the exception deliver the offending path and as parsing the exception text is a bad idea, the paths are remembered in the otherwise useless lastPath variable.
All in all it works, but this is nothing I would actually use, as the tree needs to be scanned multiple times (on my notebooks "Application Support" it takes six rescans until it gets through and four times the runtime of an implementation that works without this hack), so I would see this more as an experiment if it is possible to generically iterate the home on macOS with std::filesystem.
So, sadly, until those issues are fixed, std::filesystem::recursive_directory_iterator is not that great on macOS, and I continue to use my drop-in filesystem replacement on that platform, that honors skip_permission_denied for EPERM and EACCES (but is utf-8 only).

Opening code written in emacs on Xcode appears badly indented

This is my first post on stack overflow, so please forgive me for any mistakes.
I learned c++ with Xcode and recently started working with a group that uses Emacs. This group has a huge code in c++ and so I did a CMake interface to generate a project in Xcode. What happened is that the code appears badly indented in Xcode. For instance, these lines in emacs:
if ( argc > 4 ) {
std::string argument( argv[arg_index++] );
// NOTE: file_name should NOT be "aboveCrack" or "belowCrack"
if ( argument == "aboveCrack" ) {
surf_to_draw = CrackMn3DGraphDX2::EAboveSurface;
}
else if ( argument == "belowCrack" ) {
surf_to_draw = CrackMn3DGraphDX2::EBelowSurface;
}
else {
// argument 4 is comp. crack surface output name
got_file_name = true;
postCompSurface_file_name = argument;
}
}
if ( !got_file_name && argc > 5 ) {
got_file_name = true;
postCompSurface_file_name = argv[arg_index++];
if ( argc > 6 ) {
// get comp. crack surface output style
postCompSurface_style = argv[arg_index++];
}
}
Look like this in Xcode:
if ( argc > 4 ) {
std::string argument( argv[arg_index++] );
// NOTE: file_name should NOT be "aboveCrack" or "belowCrack"
if ( argument == "aboveCrack" ) {
surf_to_draw = CrackMn3DGraphDX2::EAboveSurface;
}
else if ( argument == "belowCrack" ) {
surf_to_draw = CrackMn3DGraphDX2::EBelowSurface;
}
else {
// argument 4 is comp. crack surface output name
got_file_name = true;
postCompSurface_file_name = argument;
}
}
if ( !got_file_name && argc > 5 ) {
got_file_name = true;
postCompSurface_file_name = argv[arg_index++];
if ( argc > 6 ) {
// get comp. crack surface output style
postCompSurface_style = argv[arg_index++];
}
}
Which is impossible to program with.
I searched and apparently it has something to do with the tabs in Emacs. Based on this, one fix I could find was to open each file in Emacs and do C-x h (mark all) followed by M-x untabify. This transforms the tabs in spaces and everything looks good in Xcode.
The problems with this idea are that it requires to change the files one by one and it won't stop this from happening again in the future.
Therefore, my question is: is there a way to open the Emacs indented files in Xcode preserving the indentation?
Many thanks!
Nathan Shauer
The first setting that you need to put in your .emacs is: (setq-default indent-tabs-mode nil). This will make sure emacs uses spaces instead of tabs for indentation.
Also, I created a tiny function:
(defun rag/untabify-buffer ()
;; get rid of all the tabs in a buffer
(interactive)
(untabify (point-min) (point-max))
nil)
Add this to before-save-hook and this will make sure all the files will be untabified when you make a change and save a file. Once you've untabified all files, you can remove the hook
No. While it is possible to use emacs to make these changes or even a number of other tools which can automate such changes, it won't really fix your problem as you will likely have to do it every time you check out the code from version control. Depending on the version control system used, it is also possible that doing such formatting changes will result in the code appearing to be modified, which will result in larger checkins and make other useful tools less useful because more will appear to have been changed than was actually changed. This will likely frustrate other project members.
There are two basic approaches, but one depends on the version control solution being used by the project. The first solution is to get the project to agree on a coding standard which specifies either that normal spaces must be used for indentation or that tabs are to be used. The problems you are seeing are primarily due to a mix. Emacs is able to handle this sort of mixed formatting quite well, but other editors, like Xcode are not so smart.
The other approach, which can work quite well because it doesn't rely on everyone following the standard is to configure the version control system to translate tabs as part of the checkin process into spaces. How this is done depends on the version control system being used.
Essentially, this is a problem which needs to be addressed at the project or version control level. Anything you do will only need to be repeated every time you do a fresh pull from version control for any files which have been modified. Fix it at the repository level and the issue will go away.

Identifying a Programming Language

So I have a software program that for reasons that are beyond this post, I will not include but to put it simply, I'd like to "MOD" the original software. The program is launched from a Windows Application named ViaNet.exe with accompanying DLL files such as ViaNetDll.dll. The Application is given an argument such as ./Statup.cat. There is also a WatchDog process that uses the argument ./App.cat instead of the former.
I was able to locate a log file buried in my Windows/Temp folder for the ViaNet.exe Application. Looking at the log it identifies files such as:
./Utility/base32.atc:_Encode32 line 67
./Utilities.atc:MemFun_:Invoke line 347
./Utilities.atc:_ForEachProperty line 380
./Cluster/ClusterManager.atc:ClusterManager:GetClusterUpdates line 1286
./Cluster/ClusterManager.atc:ClusterManager:StopSync line 505
./Cluster/ClusterManager.atc:ConfigSynchronizer:Update line 1824
Going to those file locations reveal files by those names, but not ending with .atc but instead .cat. The log also indicates some sort of Class, Method and Line # but .cat files are in binary form.
Searching the program folder for any files with the extension .atc reveals three -- What I can assume are uncompiled .cat files -- files. Low and behold, once opened it's obviously some sort of source code -- with copyright headers, lol.
global ConfigFolder, WriteConfigFile, App, ReadConfigFile, CreateAssocArray;
local mgrs = null;
local email = CreateAssocArray( null);
local publicConfig = ReadConfigFile( App.configPath + "\\publicConfig.dat" );
if ( publicConfig != null )
{
mgrs = publicConfig.cluster.shared.clusterGroup[1].managers[1];
local emailInfo = publicConfig.cluster.shared.emailServer;
if (emailInfo != null)
{
if (emailInfo.serverName != "")
{
email.serverName = emailInfo.serverName;
}
if (emailInfo.serverEmailAddress != "")
{
email.serverEmailAddress = emailInfo.serverEmailAddress;
}
if (emailInfo.adminEmailAddress != null)
{
email.adminEmailAddress = emailInfo.adminEmailAddress;
}
}
}
if (mgrs != null)
{
WriteConfigFile( ConfigFolder + "ZoneInfo.dat", mgrs);
}
WriteConfigFile( ConfigFolder + "EmailInfo.dat", email);
So to end this as simply as possible, I'm trying to find out two things. #1 What Programming Language is this? and #2 Can the .cat be decompiled back to .atc. files? -- and vice versa. Looking at the log it would appear that the Application is decoding/decompiling the .cat files already to interpret them verses running them as bytecode/natively. Searching for .atc on Google results in AutoCAD. But looking at the results, shows it to be some sort of palette files, nothing source code related.
It would seem to me that if I can program in this unknown language, let alone, decompile the existing stuff, I might get lucky with modding the software. Thanks in advance for any help and I really really hope someone has an answer for me.
EDIT
So huge news people, I've made quite an interesting discovery. I downloaded a patch from the vendor, it contained a batch file that was executing ViaNet.exe Execute [Patch Script].atc. I quickly discovered that you can use Execute to run both .atc and .cat files equally, same as with no argument. Once knowing this I assumed that there must be various arguments you can try, well after a random stroke of luck, there is one. That being Compile [Script].atc. This argument will compile also any .atc file to .cat. I've compiled the above script for comparison: http://pastebin.com/rg2YM8Q9
So I guess the goal now is to determine if it's possible to decompile said script. So I took a step further and was successful at obtaining C++ pseudo code from the ViaNet.exe and ViaNetDll.dll binaries, this has shed tons of understanding on the proprietary language and it's API they use. From what I can tell each execution is decompiled first then ran thru the interpreter. They also have nicknamed their language ATCL, still no idea what it stands for. While searching the API, I found several debug methods with names like ExecuteFile, ExecuteString, CompileFile, CompileString, InspectFunction and finally DumpObjCode. With the DumpObjCode method I'm able to perform some sort of dump of script files. Dump file for above script: http://pastebin.com/PuCCVMPf
I hope someone can help me find a pattern with the progress I made. I'm trying my best to go over the pseudo code but I don't know C++, so I'm having a really hard time understanding the code. I've tried to seperate what I can identify as being the compile script subroutines but I'm not certain: http://pastebin.com/pwfFCDQa
If someone can give me an idea of what this code snippet is doing and if it looks like I'm on the right path, I'd appreciate it. Thank you in advanced.

Force visual studio to error on include with incorrect capatilization [duplicate]

If you have a header file named ThisIsAHeaderFile.h, the following will still locate the file in Visual Studio:
#include <ThisIsAheaderFile.h>
Is there a way to enforce case sensitivity so that the #include will result in an error?
You can't, because the Windows file system is itself case-insensitive.
If you could get into a situation where you had both RICHIE.h and richie.h, it might make sense to control case sensitivity, but you can't.
I would like to point out that this is not an unsolvable problem as many tries to point out to the OP. The case insensitivity is beside the point. The point is as Lorenz03Tx explains in a comment, even though the file system is case insentitive the case is retained, so it can be controlled.
Such a counter measures is really great to have when doing cross platform development, and prevents much after work when the code is compiled for the other platform. Not to forget that making the build process more picky you would induce better habits for the developers, as they gradually will be more consistent how they include and name files.
TL;DR
One solution is to use a script that simply scans the source files for include statements and tries to match them along the include paths. Such a script could be added to visual studio post-build events, and thus run at every build, or (inspired by krlmlr) use the preprocessor of a compiler that enforce case sensitivity.
It is (used to be?) possible to create files with the same name but case differences on NTFS. Maybe someone with cygwin can verify this.
MSDN
Even then, however, it's impossible to access more than one of these at a time from a normal Windows application.
While it might not be possible to enforce this from within Visual Studio, one could implement a quick check by running only the preprocessor on the C/C++ source. This will run quickly enough to be practicable even as post-commit hook in a version control system, and err if the case in file names has been mismatched. So:
Configure your build system in Linux to support preprocessor-only runs (-E with gcc/g++)
Implement a preprocessor-only run as post-commit hook, triggering an early notification to the responsible person and/or to someone willing to routinely fix these errors
Of course, this assumes a VCS as central storage for the code.
Both FAT and NTFS are case insensitive file systems. Foo and fOO are the same file as far as they are concerned. Although the Windows OS will preserve the case you use for a file. If you name a file ThisIsAheaderFile.h it will show up that way in the file system. Although all system function calls to open that file can use any casing they want.
Also having similar problem when trying to build under linux; not full solution...
If you Find in Files #include by VS and copy result to textarea, you will get sorted CSV with include file name, original path and list of files in 3rd column (columns are tab delimited)
Easy to check solution/wide and in case there are not much case problems it should be easy to replace them?
function readIncludes(t)
{
var s = t.value.split('\n');
var res = {};
for(var r in s)
{
if (r == 0) continue;
var dq = s[r].indexOf('(');
var p = s[r].substr(0, dq);
var p2 = s[r].indexOf(':', dq);
p2 = s[r].substring(0, p2);
dq = s[r].indexOf('#', dq);
var i = s[r].substr(dq);
var ip = i.replace(/#include\s+/, "");
if (!ip) continue; // *#includes.*
var st = '<>""';
if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
st = st[st.indexOf(ip[0]) + 1];
ip = ip.substr(1, ip.indexOf(st, 2) - 1);
if (!ip || ip[0] == '/') debugger
if (!res[ip]) res[ip] = [];
res[ip].push(p2);
}
var resSorted = [];
for(var r in res)
{
var shortR = r.replace(/.+[\\/]/, ""); // include file
resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
}
t.value = resSorted.sort().join('\n'); // sort again long lines of results
}
html,body,textarea {
width: 100%;
height: 100%;
white-space: nowrap;
}
<textarea onchange="readIncludes(this)">
</textarea>

Eclipse CDT Debugger Issue, v. .metadata does not exist

I am attempting to use the gdb/mi debugger in the Eclipse CDT version 6.02. While I am debugging I can step through the program with ease up until I reach the following snippet of a block of code.
ENUM_START_TYPE My_Class::some_function( const char * c, const char * e)
{
ENUM_START_TYPE result = GENERIC_ENUM_VALUE;
if ( c[0] == '<' )
{
result = do_something()
}
...
MORE CODE
...
return result;
}
When the debugger reaches this line.
if ( c[0] == '<' )
It starts exploring sections of code that it can not find until it opens a tab containing the /projectname/.metadata and simply declares:
"Resource '/project_name/.metadata' does not exist.
At which point the debugger terminates the program with no reason as to why.
All I wish to do is step over this line of code because it really is as trivial as comparing characters.
My question is: Why is this happening? Is it something to do with the debugger, or does it have something to do with my code, or what. Additionally, what is the .metadata and why can't the file be located and opened when it clearly exists (I can locate and open the .metafile without a problem).
Other info that may be pertinent: The files are located on a clearcase snapshot view, but are not checked into source control. I don't think that would cause an error like this, but clear case has caused so many random errors for me that I thought it would be worth mentioning.
Thanks in advance
As I am not aware of any side-effect a snapshot view might have in the process.
A dynamic view could consider part of the directories as "non-selected" (and then non-readable).
You have also the issue of symlink to dynamic view set on drive.
But a snapshot view is nothing more than a working tree on the hard drive.
To rule out any "ClearCase interference", you could try and debug your project entirely copied outside of any view of any sort (based on the content of your current snapshot view), and see if the problem persists.