I have a fair bit of code written to compile under various build systems (e.g. CCS, Visual C, Embarcadero CBuilder, Microchip XCn). Since the various compilers differ in how they define things like inline or interrupt routines, I use #if/#elif/#else constructs to satisfy their requirements. The GCC preprocessor documentation even suggests this as a good use for #if etc.
In the case of my microprocessor build tools, the CCS family of compilers, and XC16 (gcc-based) deal with this just fine, but XC8 insists on looking inside a non-active #if blocks and generating warnings.
For example, the code
#ifdef _COMPILER_CCS
#INT_RDA
void RDA_ISR(void)
#elif defined (_COMPILER_MCHIP_XC16)
void __attribute__((__interrupt__(_ISR_SPECIAL_SAVE), __auto_psv__)) _U1RXInterrupt(void)
#elif defined (_COMPILER_MCHIP_XC8)
void vU1RXInterruptHandler(void)
#else
#error Problem with defines
#endif
{
...
}
generates the warning
warning: (107) illegal # directive "INT_RDA"
There are hundreds of these warnings generated, making it hard to see legitimate warnings and/or errors.
Does anyone have suggestions on how to make XC8 shut up about things it's not even supposed to be parsing? I cannot find a flag to turn off this warning.
I use macros with xc8, but use #if
not just #ifdef as it seems to sometimes think undefined 'C'
macros are simply 0. Also I never give a compiler option the value 0.
Bit scary, but I tend to do stuff like:
//#define COMP_OPT 1
//#define COMP_OPT 2
#define COMP_OPT 3
then in the code
#if ( COMP_OPT == 0 )
#error COMP_OPT NOT DEFINED
#endif
#if ( COMP_OPT == 2 )
{
// code for compile option 2
// blah blah
}
#endif
That way I don't unintentionally produce code compiled for the wrong option (or none)
Related
First question here.
I have some troubles with the XCode Build System, specifically with preprocessor definitions.
I'm trying to define a macro for the objective-c runtime to avoid enforcing the dispatch functions to be cast to an appropriate function pointer type. The usual way to go would be to use #define OBJC_OLD_DISPATCH_PROTOTYPES and then include the header on the next line. Once the header gets included, the macro is already defined and the header is configured accordingly.
But that's where it starts to get weird!
The macro is not recognized at all and the header gets included as if the #define statement was not there so it fails to #define OBJC_OLD_DISPATCH_PROTOTYPES and it gets (re?)defined as 0.
main.c
#include <stdio.h>
#define OBJC_OLD_DISPATCH_PROTOTYPES 1
#include <objc/objc-runtime.h>
int main(int argc, const char * argv[]) {
// From there:
// - Build System: OBJC_OLD_DISPATCH_PROTOTYPES is always 0, except if defined in build settings
// - Clang (only): OBJC_OLD_DISPATCH_PROTOTYPES is 1
printf("%d\n", OBJC_OLD_DISPATCH_PROTOTYPES);
}
The build system acts as expected when the preprocessor macro is defined in the project build settings under the "Apple Clang - Preprocessing" section. It defines the global macro using the -D parameter of clang making it available to any files used by the project.
However, source code compiles correctly when I use clang from a terminal using clang main.c.
Could someone tell me what I need to configure for the build system to behave normally?
It gives a warning when building with Xcode IDE:
Ambiguous expansion of macro 'OBJC_OLD_DISPATCH_PROTOTYPES'
and the output is indeed 0 using Xcode directly, but 1 with clang main.c. The difference is that Xcode uses clang with enabled modules by default: You get the same warning on the command line if you enable modules there:
clang -fmodules main.c
Solution
In Xcode, select the target, go to the "Build Settings" tab and in the "Apple Clang - Language - Modules" section, switch the "Enable Modules (C and Objective-C)" entry to 'NO':
Then you get the expected result in both cases, regardless of whether you use Xcode or Clang on the command line.
Explanation:
If you use modules the following happens:
instead of the preprocessor including the text and compiling the result, a binary representation of the module is used
modules are (independently) precompiled, i.e. they use the definitions from the time the module was precompiled
consequently, preprocess definitions from the code before the include/import statement have no effect on the module (nor on other imported modules).
if modules are enabled, not only #imports are affected, but also #includes are translated into module imports under the hood
So you have a contradictory definitions for the OBJC_OLD_DISPATCH_PROTOTYPES.
The precompiled module uses a 0 for OBJC_OLD_DISPATCH_PROTOTYPES and you redefine it as 1.
BTW: if you use
#define OBJC_OLD_DISPATCH_PROTOTYPES 0
then you use the same definition that the precompiled module is using and therefore there is no warning about an ambiguous expansion of the macro even if modules are enabled.
Without enabled modules, the preprocessor includes the text, compiles the result and returns the expected result, i.e. in objc.h the desired typedef are used.
I'm using QtCreator 4.11.2 , installed via MSYS2, with ClangCodeModel enabled.
Here is my program (this is the result of creating a New Non-QT Plain C Application):
#include <stdio.h>
#include <stdbool.h>
_Bool a;
bool b;
int main()
{
printf("Hello World!\n");
return 0;
}
The .pro file is unchanged from the default:
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += \
main.c
The annotation compiler highlights an error saying stdbool.h cannot be found.
But it does not give an error for _Bool a; , so it is clearly running in C99 mode but has some problem with include paths. The "Follow symbol under cursor" option works, opening stdbool.h.
My question is: How do I configure include paths for the annotation compiler or otherwise fix this problem?
I have been unable to figure out how to set options for the annotation compiler or even which compiler binary it is using . Under Tools > Options > C++ > Code Model > Diagnostic Configuration it lets me add -W flags but does not let me add -I flags, a red message pops up saying the option is invalid.
Under Tools > Options > C++ Code Model inspector, there are no diagnostic messages, and the Code Model Inspecting Log shows stdbool.h being correctly found and parsed, as msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/stdbool.h.
If I disable the ClangCodeModel plugin then there are no errors , but I would like to use the clang version if it can be made to work as in general it has good diagnostics.
The result of clang --version in a shell prompt is:
clang version 10.0.0 (https://github.com/msys2/MINGW-packages.git 3f880aaba91a3d9cdfb222dc270274731a2119a9)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: F:\Prog\msys64\mingw64\bin
and if I compile this same source code using clang outside of QtCreator, it compiles and runs correctly with no diagnostics. So the annotation compiler is clearly not the same as the commandline clang?
The Kit I have selected in QtCreator is the autodetected Desktop Qt MinGW-w64 64bit (MSYS2)
The exact same symptoms occur if I make a Plain C++ project and try to include stdbool.h (which is required to exist by the C++ Standard, although deprecated), although interestingly it does accept <cstdbool>.
I have found a workaround of sorts: including in the .pro file the line:
INCLUDEPATH += F:/Prog/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/
causes the annotation compiler to work correctly, however this is undesirable as I'd have to keep changing it whenever I switch Kits because it also passes this to the actual build compiler, not just the annotation compiler.
Create file stdbool.h in C:\msys64\mingw64\x86_64-w64-mingw32\include and copy paste this code:
/* Copyright (C) 1998-2017 Free Software Foundation, Inc.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.
GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<http://www.gnu.org/licenses/>. */
/*
* ISO C Standard: 7.16 Boolean type and values <stdbool.h>
*/
#ifndef _STDBOOL_H
#define _STDBOOL_H
#ifndef __cplusplus
#define bool _Bool
#define true 1
#define false 0
#else /* __cplusplus */
/* Supporting _Bool in C++ is a GCC extension. */
#define _Bool bool
#if __cplusplus < 201103L
/* Defining these macros in C++98 is a GCC extension. */
#define bool bool
#define false false
#define true true
#endif
#endif /* __cplusplus */
/* Signal that all the definitions are present. */
#define __bool_true_false_are_defined 1
#endif /* stdbool.h */
Note
Creating a manual file stdbool.h works for me but its a sketchy and a temporary solution for now. Don't use this if you feel its too sketcy. I would rather use a alternative solution than this hack if it exist. This solution might not be good but it still works for me.
The implementation of function memcmp in glibc uses the macro DBLALIGN(eg, DBLALIG(a3, a0, srcli)) to compare two unsinged int integer. DBLALIGN is delcared as follows. However, the definition of __insn_dword_align is not found in glibc source codes. Where can I find it. Thank you!
#ifdef __tilegx__
#define DBLALIGN __insn_dblalign
#define REVBYTES __insn_revbytes
#else
#define DBLALIGN __insn_dword_align
#define REVBYTES __insn_bytex
#endif
It's a gcc builtin. See e.g. here.
I cannot find the definition
You wouldn't find a definition for any builtin. That's what "builtin" means: the compiler recognizes builtin by name and emits required instructions directly to assembly.
I'm trying to disable automated crash logs reports when one or both of two defines are set: DEBUG for our debug builds and INTERNATIONAL for the international builds. When I try to do that in the #ifndef case, however, I get the warning Extra tokens at end of #ifndef directive and running with DEBUG defined will trigger Crittercism.
#ifndef defined(INTERNATIONAL) || defined(DEBUG)
// WE NEED TO REGISTER WITH THE CRITTERCISM APP ID ON THE CRITTERCISM WEB PORTAL
[Crittercism enableWithAppID:#"hahayoudidntthinkidleavetherealonedidyou"];
#else
DDLogInfo(#"Crash log reporting is unavailable in the international build");
// Since Crittercism is disabled for international builds, go ahead and
// registers our custom exception handler. It's not as good sadly
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
DDLogInfo(#"Registered exception handler");
#endif
This truth table shows what I expect:
INTL defined | DEBUG defined | Crittercism Enabled
F | F | T
F | T | F
T | F | F
T | T | F
This worked before when it was just #ifndef INTERNATIONAL. I've also tried without the defined(blah) and with parentheses around the whole statement (same warning and an error respectively).
How do I get the behavior I want from the compiler?
You want:
#if !defined(INTERNATIONAL) && !defined(DEBUG)
// neither defined - setup Crittercism
#else
// one or both defined
#endif
Or you can do:
#if defined(INTERNATIONAL) || defined(DEBUG)
// one or both defined
#else
// neither defined - setup Crittercism
#endif
I just found one post Conditional Compilation which can be better explained the differences between #if/#elif and #ifdef/#ifndeffrom syntax level:
#if constant-expression newline
#ifdef identifier newline
#ifndef identifier newline
#else newline
#elif constant-expression newline
#endif newline
So here we can see #ifndef must be followed by 'identifier', that was often the macro defined by #define directive, or #rmaddy said 'a single value'.
But if can be followed by 'constant-expression' so that the conditional expression defined(INTERNATIONAL) || defined(DEBUG) or !defined(INTERNATIONAL) && !defined(DEBUG) can be used.
Could you tell me please how can I do the following:
#if __unix__
#define path_sep='/'
#elif __windows__
#define path_sep='\'
#else
#error "path_sep not defined."
#endif
using gfortran compiler.
This can be done in combination with conditional compilation and using the "D" option on the command line. Here is some example code:
program test_Dopt
character (len=1) :: pathsep
pathsep = "?"
#ifdef WOS
pathsep = "\"
#endif
#ifdef UOS
pathsep = "/"
#endif
write (*, '( "pathsep is >", A1, "<")' ) pathsep
end program test_Dopt
Name the program with filetype F90 to cause gfortran to run the preprocessor or use -cpp on the compile line. Then pass options to the prepreprocessor by including them after D on the compile line, e.g., gfortran -DWOS. (This is more general then gfortran -- most Fortran compilers will process C-style pre-processor directives.) Then you can identify the OS outside of Fortran and pass the information to the Fortran program.
You can compile your code via using the filetype F90 or -cpp.