I am trying to understand the following macro from the following URL:
do { \
word _v(l) = vec_len (V); \
V = _vec_resize ((V), 1, (_v(l) + 1) * sizeof ((V)[0]), (H), (A)); \
(V)[_v(l)] = (E); \
} while (0)
what is the significance of _v(l)? Is it just a variable or something more?
The _v macro is defined in vec.h at line 207:
#define _v(var) _vec_##var
This prepends _vec_ before var. You can observe this by asking your favorite compiler to print the output of the preprocessor stage (-E flag for clang/gcc and /E for msvc).
#define _v(var) _vec_##var
word _v(l) = vec_len (V);
Is expanded into:
word _vec_l = vec_len (V);
It is a variable whose name is generated. The name probably includes the current line number to make it unique. Therefore using this macro twice in a line may or may not work.
To see what the macro expands to, run gcc -E to only preprocess the code but not compile it. Do a bit of research about this -E computer option, it is helpful in many similar cases as well.
Related
Comments are usually converted to a single white-space before the preprocesor is run. However, there is a compelling use case.
#pragma once
#ifdef DOXYGEN
#define DALT(t,f) t
#else
#define DALT(t,f) f
#endif
#define MAP(n,a,d) \
DALT ( COMMENT(| n | a | d |) \
, void* mm_##n = a \
)
/// Memory map table
/// | name | address | description |
/// |------|---------|-------------|
MAP (reg0 , 0 , foo )
MAP (reg1 , 8 , bar )
In this example, when the DOXYGEN flag is set, I want to generate doxygen markup from the macro. When it isn't, I want to generate the variables. In this instance, the desired behaviour is to generate comments in the macros. Any thoughts about how?
I've tried /##/ and another example with more indirection
#define COMMENT SLASH(/)
#define SLASH(s) /##s
neither work.
In doxygen it is possible to run commands on the sources before they are fed into the doxygen kernel. In the Doxyfile there are some FILTER possibilities. In this case: INPUT_FILTER the line should read:
INPUT_FILTER = "sed -e 's%^ *MAP *(\([^,]*\),\([^,]*\),\([^)]*\))%/// | \1 | \2 | \3 |%'"
Furthermore the entire #if construct can disappear and one, probably, just needs:
#define MAP(n,a,d) void* mm_##n = a
The ISO C standard describes the output of the preprocessor as a stream of preprocessing tokens, not text. Comments are not preprocessing tokens; they are stripped from the input before tokenization happens. Therefore, within the standard facilities of the language, it is fundamentally impossible for preprocessing output to contain comments or anything that resembles them.
In particular, consider
#define EMPTY
#define NOT_A_COMMENT_1(text) /EMPTY/EMPTY/ text
#define NOT_A_COMMENT_2(text) / / / text
NOT_A_COMMENT_1(word word word)
NOT_A_COMMENT_2(word word word)
After translation phase 4, both the fourth and fifth lines of the above will both become the six-token sequence
[/][/][/][word][word][word]
where square brackets indicate token boundaries. There isn't any such thing as a // token, and therefore there is nothing you can do to make the preprocessor produce one.
Now, the ISO C standard doesn't specify the behavior of doxygen. However, if doxygen is reusing a preprocessor that came with someone's C compiler, the people who wrote that preprocessor probably thought textual preprocessor output should be, above all, an accurate reflection of the token sequence that the "compiler proper" would receive. That means it will forcibly insert spaces where necessary to make separate tokens remain separate. For instance, with test.c the above example,
$ gcc -E test.c
...
/ / / word word word
/ / / word word word
(I have elided some irrelevant chatter above the output we're interested in.)
If there is a way around this, you are most likely to find it in the doxygen manual. There might, for instance, be configuration options that teach it that certain macros should be understood to define symbols, and what symbols those are, and what documentation they should have.
Hi I have been trying to port LWIP to a new arm device. When compiling the code i get the error message:
"lwip/lwip-1.4.0/src/include/lwip/memp_std.h:35:23: error: expected ')' before numeric constant"
When I go to this file this and below this several similar macros is what I find on that line:
LWIP_MEMPOOL(RAW_PCB, MEMP_NUM_RAW_PCB, sizeof(struct raw_pcb), "RAW_PCB")
If I remove the need for this macro with a define to deactivate the RAW functionality the error moves to the next LWIP_MEMPOL() macro.
The define it seems to want to put a ')' in front of is defined as this:
#define MEMP_NUM_RAW_PCB 1
The RAW_PCB is not defined but is "combined with MEMP_" to create an element in an enum.
I have tried to complie the whole ting with the -E option to get human redable object files and see if i can find any open '(' around the areas where MEMP_RAW_PCB apears and the substitution of MEMP_NUM_RAW_PCB to 1 but I have not found any by manual inspection yet.
Are there any suggestions on what can be going on here or what more I can do or look for to find the cause of the error?
I should maybe add that so far I don't call on any of the LWIP code from main() or any of the functions used in main().
I solved it with:
#ifndef MEMP_STD_H_
#define MEMP_STD_H_
... // memp_std.h codes ...
#endif //#ifndef MEMP_STD_H_
The error suggests you have unbalanced parentheses. The code you have provided thus far does not indicate where this problem is, but since ) is expected, it probably means the error is actually in the lines of code preceding the one you have shown.
Examine the code preceding the line you have shown (perhaps after using gcc -E) to check to see if all the parentheses are balanced.
If you're defining it with the dash-D option, it will generate the 1 by default, e.g.:
gcc -D 'MAX(A,B) ((A) < (B)? (B) : (A))' ...
Generates:
#define MAX(A,B) ((A) < (B)? (B) : (A)) 1
And you get the error: expected ‘)’ before numeric constant message at the line where the substitution occurs because of that trailing 1, e.g.:
int maxval = MAX(i,j);
// generates: int maxval = ((i) < (j)? (j) : (i)) 1;
Conversely, if you use the assignment operator to explicitly define the value, it will generate it the way you expected. E.g.:
int maxval = MAX(i,j);
// generates: int maxval = ((i) < (j)? (j) : (i));
I am working with a primitive C Parser that does not handle the Preprocessor directive.
I can preprocess most of the header with the -E switch without problem.
Lately I found cases when attribute and align are present.
I tried to get rid of them with this tweak:
gcc -D "aligned(ARGS)" \
-D "__align__(ARGS)" \
-D "__attribute__(ARGS)" \
-E /usr/local/include/fancyheader.h
Update:
But without success, example:
struct __attribute__((aligned(16))) long4
{
long int x, y, z, w;
};
The above statements is transformed to, with that "1" pending around
struct 1 long4
{
long int x, y, z, w;
};
Who knowzs the correct way to get rid of the __align__ and __attribute__ extensions ?
What happens when you use -D "aligned(ARGS)=" ?
The preprocessor assigns the value 1 to all macros defined on the command line without specifying a replacement list. For instance, if you compile with -DFOO:
std::cout << FOO << std::endl;
will print 1. If you want to explicitly set the macro replacement list to be empty use -DFOO= (or in your case -D__align__(x)=.
How about un-defining all built-in and pre-defined macros with the -U option, and then creating new definitions with the -D option?
I have code that has a lot of complicated #define error codes that are not easy to decode since they are nested through several levels.
Is there any elegant way I can get a list of #defines with their final numerical values (or whatever else they may be)?
As an example:
<header1.h>
#define CREATE_ERROR_CODE(class, sc, code) ((class << 16) & (sc << 8) & code)
#define EMI_MAX 16
<header2.h>
#define MI_1 EMI_MAX
<header3.h>
#define MODULE_ERROR_CLASS MI_1
#define MODULE_ERROR_SUBCLASS 1
#define ERROR_FOO CREATE_ERROR_CODE(MODULE_ERROR_CLASS, MODULE_ERROR_SUBCLASS, 1)
I would have a large number of similar #defines matching ERROR_[\w_]+ that I'd like to enumerate so that I always have a current list of error codes that the program can output. I need the numerical value because that's all the program will print out (and no, it's not an option to print out a string instead).
Suggestions for gcc or any other compiler would be helpful.
GCC's -dM preprocessor option might get you what you want.
I think the solution is a combo of #nmichaels and #aschepler's answers.
Use gcc's -dM option to get a list of the macros.
Use perl or awk or whatever to create 2 files from this list:
1) Macros.h, containing just the #defines.
2) Codes.c, which contains
#include "Macros.h"
ERROR_FOO = "ERROR_FOO"
ERROR_BAR = "ERROR_BAR"
(i.e: extract each #define ERROR_x into a line with the macro and a string.
now run gcc -E Codes.c. That should create a file with all the macros expanded. The output should look something like
1 = "ERROR_FOO"
2 = "ERROR_BAR"
I don't have gcc handy, so haven't tested this...
The program 'coan' looks like the tool you are after. It has the 'defs' sub-command, which is described as:
defs [OPTION...] [file...] [directory...]
Select #define and #undef directives from the input files in accordance with the options and report them on the standard output in accordance with the options.
See the cited URL for more information about the options. Obtain the code here.
If you have a complete list of the macros you want to see, and all are numeric, you can compile and run a short program just for this purpose:
#include <header3.h>
#include <stdio.h>
#define SHOW(x) printf(#x " = %lld\n", (long long int) x)
int main(void) {
SHOW(ERROR_FOO);
/*...*/
return 0;
}
As #nmichaels mentioned, gcc's -d flags may help get that list of macros to show.
Here's a little creative solution:
Write a program to match all of your identifiers with a regular expression (like \#define :b+(?<NAME>[0-9_A-Za-z]+):b+(?<VALUE>[^(].+)$ in .NET), then have it create another C file with just the names matched:
void main() {
/*my_define_1*/ my_define_1;
/*my_define_2*/ my_define_2;
//...
}
Then pre-process your file using the /C /P option (for VC++), and you should get all of those replaced with the values. Then use another regex to swap things around, and put the comments before the values in #define format -- now you have the list of #define's!
(You can do something similar with GCC.)
Is there any elegant way I can get a list of #defines with their final numerical values
For various levels of elegance, sort of.
#!/bin/bash
file="mount.c";
for macro in $(grep -Po '(?<=#define)\s+(\S+)' "$file"); do
echo -en "$macro: ";
echo -en '#include "'"$file"'"\n'"$macro\n" | \
cpp -E -P -x c ${CPPFLAGS} - | tail -n1;
done;
Not foolproof (#define \ \n macro(x) ... would not be caught - but no style I've seen does that).
I'm stumped. Here is the output of ld.
/usr/lib/libvisual-0.6/actor/actor_avs_superscope.so: undefined reference to `visual_mem_free'
/usr/lib/libvisual-0.6/actor/actor_avs_superscope.so: undefined reference to `visual_mem_malloc0'
Here are the macros:
#define visual_mem_new0(struct_type, n_structs) \
((struct_type *) visual_mem_malloc0 (((visual_size_t) sizeof (struct_type)) * ((visual_size_t) (n_structs))))
#define visual_mem_malloc(size) \
visual_mem_malloc_impl (size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
#define visual_mem_malloc0(size) \
visual_mem_malloc0_impl (size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
#define visual_mem_realloc(ptr, size) \
visual_mem_realloc_impl (ptr, size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
#define visual_mem_free(ptr) \
visual_mem_free_impl (ptr, __FILE__, __LINE__, __PRETTY_FUNCTION__)
Now it doesn't add up. One line's saying that visual_mem_free is missing, which is a macro. The other's saying that visual_mem_malloc0 is missing, but the code's actually calling visual_mem_new0, which suggests it sees visual_mem_new0.
priv = visual_mem_new0 (SuperScopePrivate, 1);
visual_mem_free (priv);
Any clues?
Edit: Bumping.. Maybe some fresh eyes can help?
Edit: By the way, I get no warnings/errors during compiling, nor linking.
Edit: Here's a couple of snippets from the preprocessor's output.
int lv_superscope_cleanup (VisPluginData *plugin)
{
SuperScopePrivate *priv = visual_object_get_private ((((VisObject*) ((plugin)))));
visual_mem_free_impl (priv, "actor_avs_superscope.c", 195, __PRETTY_FUNCTION__);
return 0;
}
And:
priv = ((SuperScopePrivate *) visual_mem_malloc0_impl (((visual_size_t) sizeof (SuperScopePrivate)) * ((visual_size_t) (1)), "actor_avs_superscope.c", 152, __PRETTY_FUNCTION__));
It looks like the macros are being expanded. I'm confused. Is __PRETTY_FUNCTION__ supposed to be expanded?
Interestingly enough, here's the output from strings.
$ strings .libs/actor_avs_superscope.so |grep malloc
visual_mem_malloc0_impl
visual_mem_malloc0
malloc
Chris: I'm just running ld /usr/lib/libvisual-0.6/actor/actor_avs_superscope.so.
And here's the output from nm:
$ nm actor_avs_superscope.o |grep malloc
U visual_mem_malloc0_impl
$ nm actor_avs_superscope.o |grep free
U visual_mem_free_impl
U visual_palette_free_colors
Macros in C code don't result in symbols in compiled executables. Probably what is happening is that some code you are compiling didn't #include these macros, so the compiler inferred that they were functions, and compiled calls to them. You can use -Wall and -Werror to make calls to undefined functions fail to compile.
Macros are handled during the pre-processing phase which comes before linking. So if the link-editor is giving you warnings about macro names then the macros were not expanded.
To see the results of pre-processing, you can use the /E flag. If your macros have been expanded, you would see the line:
visual_mem_free (priv);
changed to something like:
visual_mem_free_impl(priv, "filename.c", 32, "main");
Update
From your nm/strings output, the file actor_avs_superscope.o is not where the problem is. What other object (.o) files and static archives (.a) are used to create actor_avs_superscope.so? You should run nm on all of them in order to find who has the unexpanded macro name in them.
Feels like it's not reading your #defines -- try printing a message inbetween them just to check.
Also check the order of compilation of your files; does the call to visual_mem_new0 come after the #defines?
Your first error is against the installed library, /usr/lib/libvisual-0.6/actor/actor_avs_superscope.so and it looks like you are looking at the local library in your project strings .libs/actor_avs_superscope.so. Try running strings against the one in /usr/lib and you'll probably see the issue.
I'd either Install your updated library version or put it's directory in the LD_LIBRARY_PATH when you run it, something like $ LD_LIBRARY_PATH=./lib ./your_executable.