Clang has several kinds of diagnostics, of which the three main kinds are errors, warnings, and notes.
Notes usually accompany certain warnings and errors, such as duplicate definitions:
error: conflicting types for 'square'
static double square(double x) {
^
note: previous declaration is here
static int square(int x);
^
What I want to know is, does Clang have any diagnostics—especially for Objective-C or C, but I'll settle for C++ if I have to—that consist of only a note, with no associated error or warning?
http://clang.llvm.org/docs/InternalsManual.html#the-diagnostic-kinds-td-files says:
These severities are mapped into a smaller set (the Diagnostic::Level
enum, {Ignored, Note, Warning, Error, Fatal}) of output levels by the
diagnostics subsystem based on various configuration options. Clang
internally supports a fully fine grained mapping mechanism that allows
you to map almost any diagnostic to the output level that you want.
The only diagnostics that cannot be mapped are NOTEs, which always
follow the severity of the previously emitted diagnostic and ERRORs,
which can only be mapped to Fatal (it is not possible to turn an error
into a warning, for example).
So unfortunately no; you can't do that without hacking Clang itself. Notes are intended only for linking to other diagnostics. I'd file a bug with the LLVM tracker; this would definitely be useful functionality.
Related
For quite a while I've been using linker sections for registering elements that are used at runtime. I find that it's a simple way to make generic and extensible interface. A particularly useful use-case is something like unit tests or a multitool (e.g. busybox) so one can do something like:
$ ./tool <handler>
Where handler is a simple string that is "looked up" at runtime by walking the linker section. In this way, your parser doesn't have to "know" what commands are supported. It just finds their handlers in the linker section dedicated for them or it doesn't.
With GCC I've been doing something like (you can do this with Clang as well):
#define __tool __attribute__((__section__("tools")))
Then each handler I want to register gets a simple structure (with more or less information as needed)
struct tool {
const char *name;
const char *help;
int (*handler)(int argc, char **argv);
}
Then, for each tool you just do something like (often conveniently wrapped in a macro):
int example_tool0(int argc, char **argv)
{
return -1;
}
static const struct tool example_tool0 = {
.name = "exmaple_tool0",
.help = "usage: ...",
.handler = example_tool0
};
__tool static const struct tool *ptr = &example_tool0;
And used a such:
$ ./tool example_tool0
And because of __tool, each pointer registered in this way is packed into a linker section that can be walked.
Now, on GCC the linker creates two magic variables for each section: __start_SECTION and __stop_SECTION. So, to "walk" all of our registered handlers you just take the size of this section, divide by the size of a pointer, and then strncmp against the name (in this example) in the struct.
All of the above just to say, how can this be done using the OSX/iOS Clang-based toolchain? I would rather not use a custom linker script to achieve this seemingly simple operation.
Is there a way do this on OSX? I have worked around the issue by registering an empty entry at the beginning of the section and at the end. But doing so requires forcing the link order of the object files.
While OSX/iOS uses Clang as their platform compiler, they do not use the LLVM linker. Rather, they implement their own ld64 (which is open source) for whatever reason. So, it may just not be supported. I didn't readily see anything in man ld on OSX, but it's a bit info-dense.
For reference with ELF and GCC
And so this has been answered by others already. I did search, but I must have missed this answer. I've actually looked for an answer to this question many times before but must've never used the right words.
https://stackoverflow.com/a/22366882/2446071
In summary, apparently the linker supports syntax to define these desired symbols yourself:
extern char __start_SECTION __asm("section$start$SEGMENT$SECTION");
extern char __stop_SECTION __asm("section$end$SEGMENT$SECTION");
I use the crash function for testing Crashlytics integrations, but I obviously never want to ship that code in an app.
It's possible to poison identifiers so that any current or future use causes an error:
#pragma GCC poison crash
Is there an equivalent #pragma directive that emits a warning when an identifier is used? I want to be able to build the codebase while retaining a visible indicator that attention is required.
This should work, now that _Pragma is available. Instead of using #pragma GCC poison, you can just #define the identifier crash in a way which will generate a warning using #pragma GCC warning:
#define DO_PRAGMA(x) _Pragma(#x)
#define WARN(x) DO_PRAGMA(GCC warning #x)
#define crash WARN("crash" used) crash
The first two macros just make it less work to escape quotation marks. Note that crash expands to itself (as well as the _Pragma), which works because the C preprocessor doesn't expand a token inside of its own expansion.
If you change warning to error, you'll get an error instead. You could easily arrange to change all of those by using some more macros, or you could just use -Werror
You could use #warning
Usage would be as follows:
#warning This is a custom message
I've been wrestling with an issue in iOS causing improper allocation, getting less memory back from malloc than I should have for a CPP object. I recently discovered it was due to two translation units including the same header, one of which along its include chain had a few occurrences of #pragma pack.
Now, I'm not sure how to properly trace back to whichever file is using it and ensure that it fixes it. I've added a bunch of #pragma pack(show) and have nailed down the offending file from the top (the offending file being the file that causes others files to have the same pack setting of 1). I've opened that file in Xcode and run preprocess on it.
In most cases, it looks like code is setting pack back to default (8 on arm64). Are there any tools that can help verify which is the offender along the chain?
The only tip that I have (a case of a pack 1, which is what the pack was being set to), is a header from the iOS SDK. But even it looks to be ok.
# 54 "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk/usr/include/sys/kauth.h" 2 3 4
#pragma pack(1)
typedef struct {
u_int8_t sid_kind;
u_int8_t sid_authcount;
u_int8_t sid_authority[6];
u_int32_t sid_authorities[16];
} ntsid_t;
#pragma pack()
As I mentioned, when searching through the preprocessed source file, I wasn't able to find any instance of #pragma pack that wasn't undoing its setting shortly after. However, I wasn't aware that there was another way to set packing, via #pragma options align=(packed|reset). It turns out that it wasn't being undone, but I was looking for #pragma pack.
I have to use some private functions, like:
SCDynamicStoreRef
SCDynamicStoreCreate (
CFAllocatorRef allocator,
CFStringRef name,
SCDynamicStoreCallBack callout,
SCDynamicStoreContext *context
) __OSX_AVAILABLE_STARTING(__MAC_10_1,__IPHONE_NA);
By default they are not allowed for iphone, so I've changed declaration of them in my .m file. But now it shows "Availability does not match previous declaration" warning. How to suppress this warning?
With the usual disclaimer that using private APIs might cause your app to be rejected:
You can suppress the warning with
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wavailability"
…
#pragma clang diagnostic pop
It might also cause crashes or other failures if that function is present in the iOS
frameworks, but with different parameters.
In clang, is there a way to enable bounds checking for [] access to std::vectors and other STL containers, preferably when building in debug mode only?
I just spent hours hunting down a subtle bug that turned out to be caused by us accessing past the end of a std::vector. It doesn't need to do anything clever when it detects the error, just trap in the debugger so that I can find out where it happened and fix it in the code.
Is there a way to do this other than "create your own type that inherits from std::vector", which I'd like to avoid?
(I'm using clang version 3.1 if that makes a difference.)
libstdc++ has a mature debug mode using -D_GLIBCXX_DEBUG.
libc++ also has a debug mode using -D_LIBCPP_DEBUG but as we can see this mailing list discussion: Status of the libc++ debug mode it is incomplete:
| My understanding is that this work was never completed and it's
probably broken/incomplete.
That is correct.
It’s on my list of things to fix/implement, but it’s not something that I will get to anytime soon.
It does seem to work for std::vector on 3.4 and up see it live, give the following program:
#include <vector>
#include <iostream>
int main()
{
std::vector<int> v = {0,1,2,3} ;
std::cout << v[-1] << std::endl ;
}
it generates the following error:
vector[] index out of bounds
Aborted
If you're using Linux or OS X you should look into the address sanitizer:
http://clang.llvm.org/docs/AddressSanitizer.html
It introduces a 2x slowdown, but does a bunch of memory checking and may catch your bug.
Another amazing tool that has saved me countless times is valgrind. If you can run with valgrind it will catch a ton of memory bugs and leaks.
#define _GLIBCXX_DEBUG
This enables all kinds of inline checking (see vector and debug/vector)