The Coverity Scan tuning documentation talks about adding function annotations to source files. There are three options listed:
+kill
+alloc
+free
However, from that same page there is a link to an example file that uses as-of-yet unseen flags:
toctou
string_size
What do these flags mean? What other flags are available for function annotation, and where are they documented?
Apparently the content between the brackets should be the Coverity event tag name. The comment should immediately precede the line with the false positive in it, and will cause that defect to be flagged as intentional (as long as it matches the flagged event.)
For example, the toctou event tag name is detailed here.
Source
Related
What has become of the CMake CLEAN_DIRECT_OUTPUT property used in the set_target_properties command? The CMake Properties on Targets page doesn't mention it but it appears in some CMakeLists.txt files I've seen.
Googling for CLEAN_DIRECT_OUTPUT doesn't seem to give much insight into this question. At best, links like linux.die.net document what this property is for:
When a library is built CMake by default generates code to remove any existing library using all possible names. This is needed to support libraries that switch between STATIC and SHARED by a user option. However when using OUTPUT_NAME to build a static and shared library of the same name using different logical target names the two targets will remove each other's files. This can be prevented by setting the CLEAN_DIRECT_OUTPUT property to 1.
And that seems like an important function!
Searching for this property on cmake.org however, shows "no results found".
Fortunately, the cmake source code and its revision history can be found online. Searching the git log history, reveals a commit, dated May 1 2009 by Brad King, that sheds some light into this question.
This commit's log message is as follows:
ENH: Always imply CLEAN_DIRECT_OUTPUT target prop
This property was left from before CMake always linked using full path
library names for targets it builds. In order to safely link with
"-lfoo" we needed to avoid having both shared and static libraries in
the build tree for targets that switch on BUILD_SHARED_LIBS. This meant
cleaning both shared and static names before creating the library, which
led to the creation of CLEAN_DIRECT_OUTPUT to disable the behavior.
Now that we always link with a full path we do not need to clean old
library names left from an alternate setting of BUILD_SHARED_LIBS. This
change removes the CLEAN_DIRECT_OUTPUT property and instead uses its
behavior always. It removes some complexity from cmTarget internally.
Accordingly, the commit's source code changes show that functionality, documentation, and uses of CLEAN_DIRECT_OUTPUT was removed.
Bottom line appears to be: the CLEAN_DIRECT_OUTPUT property has been removed and instead its behavior is always used.
How can you trace function calls, DEFINEs and declarations in a complex project from the listed includes in a given file using gedit?
In other IDEs you usually right-click on a function or variable and it can take you to its original declaration.
Gedit is an extremely light text editor and not an IDE. Therefore to answer you,
It is not possible to do what you are asking in Gedit. It never "reads" your code per se (IDEs/compliers do this) and hence can't locate function definitions etc.
This question already has answers here:
What are the new documentation commands available in Xcode 5? [closed]
(4 answers)
Closed 8 years ago.
This question is for reference purposes.
In the "Fonts & Colors" tab of the Settings window of Xcode, there's a setting for documentation comments (and keywords)? What are they?
Feel free to enhance this answer.
Documentation comments are just (Objective-C) comments marked as documentation. They are treated the same way as normal comments, except that you can set another color and font in Xcode. Some documentation software may even use these comments to create automatically documentation from given header files and other source code.
Documentation comment keywords are keywords that give semantical meaning to text that follows after the keyword in a documentation comment.
You can create inline documentation comments with three slashes (instead of two in normal comments), and block doc. comments with two stars instead of one (instead of one in normal comments). Example:
// Normal inline comment
/// Documentation comment
/* Normal block
comment */
/** Documentation block
comment */
You can create documentation comment keywords by specifying a keyword (one word only) after the "at" symbol. Example:
- (void)sendMessage: (id)sender;
/// #description Sends the receiver.
/// #available Version 1.0 through 2.2
Appledoc is a tool for creating a documentation set from your source code (including documentation comments and method signatures) and getting it to install and reload inside Xcode when needed. It's a command-line program and has instructions for how to incorporate it into your Xcode build process.
Once you have a documentation set you can add it to Xcode via Preferences > Downloads > Documentation.
The special keywords starting with an #-sign is also called HeaderDoc tags. A list of them can be found in the HeaderDoc User Guide. Please note that some of them are Objective-C and some are C++.
For those who did not watch the latest keynote: With Xcode 5 this feature will be built in. It is already available in the current developer preview (called quick help, like announced here).
Xcode 5 now has built-in support for DOxygen style comments. So, you can comment your methods like this:
/*!
* Provides an NSManagedObjectContext singleton appropriate for use on the main
* thread. If the context doesn't already exist it is created and bound to the
* persistent store coordinator for the application, otherwise the existing
* singleton contextis returned.
* \param someParameter You can even add parameters
* \returns The a shared NSManagedObjectContext for the application.
*/
+ (NSManagedObjectContext *)sharedContext;
Inline help will look like this:
Quick help will look like this:
And sidebar help will look like this:
Here's a handy code snippet you can add the your Xcode Code Snippet library to make method documentation simple:
/**
<#description#>
#param <#parameter#>
#returns <#retval#>
#exception <#throws#>
*/
Now, you can just type "doxy" and poof! You have your doxygen template.
There are a number of tools such as Doxygen, Javadoc, and others which recognize "special" comments (known as documentation comments) to automatically generate documentation for the code.
Typically, documentation comments start with a special sequence such as /** (as opposed to just /*) and contain special keywords that often have a special start symbol such as #. There are a lot of similarities between the different comment documentation generators, most of which accept "#param" to document parameters, "#return" to document return values, "#throws" to document exceptions, etc.
In the context of Xcode's syntax highlighting, documentation comments are those with one of these special start sequences that Xcode happens to recognize. It should be noted that there a specific set of such comments that Xcode properly recognizes; for example, the Doxygen tool also allows /*! and //! (with an exclamation) to indicate the start of documentation comments, but Xcode doesn't recognize it.
Im using doxygen outside of its design, but well within its capability. I have a bunch of essentially text files, appended with some doxygen tags. I am successfully generating doxygen output. However, somehow doxygen occasionally discovers what it assumes to be a variable, and proceeds to document it using surrounding text, causing a lot of confusing documentation. I cant see any direct relationship between these anomalies, only that they're reproducing the same output on each run, and what I can see is at least some are next to a ';' or a '='.
I only want doxygen to document what I've manually tagged. I am hoping to remove any occurrence of these anomalies, however I cannot alter existing text. I can only add doxygen tags, or alter the configuration file. Any ideas?
Many thanks.
Because in my particular case, I do not need any automatically generated documentation, only that which I have tagged with doxygen tags, setting
EXCLUDE_SYMBOLS = *
removes any instance of doxygen "finding" and documenting variables. This however may remove any ability to find any class declarations, namespaces or functions, however this is acceptable for me.
I'm producing a hex file to run on an ARM processor which I want to keep below 32K. It's currently a lot larger than that and I wondered if someone might have some advice on what's the best approach to slim it down?
Here's what I've done so far
So I've run 'size' on it to determine how big the hex file is.
Then 'size' again to see how big each of the object files are that link to create the hex files. It seems the majority of the size comes from external libraries.
Then I used 'readelf' to see which functions take up the most memory.
I searched through the code to see if I could eliminate calls to those functions.
Here's where I get stuck, there's some functions which I don't call directly (e.g. _vfprintf) and I can't find what calls it so I can remove the call (as I think I don't need it).
So what are the next steps?
Response to answers:
As I can see there are functions being called which take up a lot of memory. I cannot however find what is calling it.
I want to omit those functions (if possible) but I can't find what's calling them! Could be called from any number of library functions I guess.
The linker is working as desired, I think, it only includes the relevant library files. How do you know if only the relevant functions are being included? Can you set a flag or something for that?
I'm using GCC
General list:
Make sure that you have the compiler and linker debug options disabled
Compile and link with all size options turned on (-Os in gcc)
Run strip on the executable
Generate a map file and check your function sizes. You can either get your linker to generate your map file (-M when using ld), or you can use objdump on the final executable (note that this will only work on an unstripped executable!) This won't actually fix the problem, but it will let you know of the worst offenders.
Use nm to investigate the symbols that are called from each of your object files. This should help in finding who's calling functions that you don't want called.
In the original question was a sub-question about including only relevant functions. gcc will include all functions within every object file that is used. To put that another way, if you have an object file that contains 10 functions, all 10 functions are included in your executable even if one 1 is actually called.
The standard libraries (eg. libc) will split functions into many separate object files, which are then archived. The executable is then linked against the archive.
By splitting into many object files the linker is able to include only the functions that are actually called. (this assumes that you're statically linking)
There is no reason why you can't do the same trick. Of course, you could argue that if the functions aren't called the you can probably remove them yourself.
If you're statically linking against other libraries you can run the tools listed above over them too to make sure that they're following similar rules.
Another optimization that might save you work is -ffunction-sections, -Wl,--gc-sections, assuming you're using GCC. A good toolchain will not need to be told that, though.
Explanation: GNU ld links sections, and GCC emits one section per translation unit unless you tell it otherwise. But in C++, the nodes in the dependecy graph are objects and functions.
On deeply embedded projects I always try to avoid using any standard library functions. Even simple functions like "strtol()" blow up the binary size. If possible just simply avoid those calls.
In most deeply embedded projects you don't need a versatile "printf()" or dynamic memory allocation (many controllers have 32kb or less RAM).
Instead of just using "printf()" I use a very simple custom "printf()", this function can only print numbers in hexadecimal or decimal format not more. Most data structures are preallocated at compile time.
Andrew EdgeCombe has a great list, but if you really want to scrape every last byte, sstrip is a good tool that is missing from the list and and can shave off a few more kB.
For example, when run on strip itself, it can shave off ~2kB.
From an old README (see the comments at the top of this indirect source file):
sstrip is a small utility that removes the contents at the end of an
ELF file that are not part of the program's memory image.
Most ELF executables are built with both a program header table and a
section header table. However, only the former is required in order
for the OS to load, link and execute a program. sstrip attempts to
extract the ELF header, the program header table, and its contents,
leaving everything else in the bit bucket. It can only remove parts of
the file that occur at the end, after the parts to be saved. However,
this almost always includes the section header table, and occasionally
a few random sections that are not used when running a program.
Note that due to some of the information that it removes, a sstrip'd executable is rumoured to have issues with some tools. This is discussed more in the comments of the source.
Also... for an entertaining/crazy read on how to make the smallest possible executable, this article is worth a read.
Just to double-check and document for future reference, but do you use Thumb instructions? They're 16 bit versions of the normal instructions. Sometimes you might need 2 16 bit instructions, so it won't save 50% in code space.
A decent linker should take just the functions needed. However, you might need compiler & linke settings to package functions for individual linking.
Ok so in the end I just reduced the project to it's simplest form, then slowly added files one by one until the function that I wanted to remove appeared in the 'readelf' file. Then when I had the file I commented everything out and slowly add things back in until the function popped up again. So in the end I found out what called it and removed all those calls...Now it works as desired...sweet!
Must be a better way to do it though.
To answer this specific need:
•I want to omit those functions (if possible) but I can't find what's
calling them!! Could be called from any number of library functions I
guess.
If you want to analyze your code base to see who calls what, by whom a given function is being called and things like that, there is a great tool out there called "Understand C" provided by SciTools.
https://scitools.com/
I have used it very often in the past to perform static code analysis. It can really help to determine library dependency tree. It allows to easily browse up and down the calling tree among other things.
They provide a limited time evaluation, then you must purchase a license.
You could look at something like executable compression.