C - double underscore inside #define macro
I've done some searches and consulted with a friend of mine, but also want the StackExchange communities to come in. For the foreword, I'm basically an HW person who has been hacked to the ground with low firmware, so forgive me for all this seems common knowledge. I've programmed C in the past, but it's been a while.
For a custom ASIC, I am isolated in that we have many control / status registers that we will access via software / firmware (I will most likely just call it SW from now on). For our verilog / SV / UVM testbeds, we have a script that builds the verilog `define header file. In this case, we have the following structure:
`define REG_NAME <addr of register>
`define REG_NAME__BITFIELD1 <bit vector i.e. 1:0>
`deinfe REG_NAME__BITFIELD2 <bit vector i.e. 4:2>
We use double underscores to visually distinguish between the register name and the bitfield. We then use this to do operations like read-modify-write, bit masking, etc. For SW, I wrote a script to print the .h file in C format. I wanted to keep similar formatting:
#define REG_NAME <addr of register>
#define REG_NAME__BITFIELD1___MASK 0x00000003
#define REG_NAME__BITFIELD1___SHIFT 0
#deinfe REG_NAME__BITFIELD2___MASK 0x0000001c
#deinfe REG_NAME__BITFIELD2___SHIFT 2
In this case, I want to keep the double underscore to distinguish between REG and BIT_FIELD and a triplet to distinguish MASK / SHIFT / whatever I add.
I know from the following SE questions: Using double underscore in C How is __mro__ different from other double underscore names?
The underscore prefix is not good coding practice. Is it generally a bad coding technique to have double / triple underscores INSIDE a definition of this type? I know I can control the definition of the macro to never start or end with double / triple underscores. It's honestly what helps me quite a bit. I find it difficult to distinguish between words when all single underscores are used. And with over 60k register based #defines, I would like to have a cleaner way to look at it. However, if this is something that most SW engineers will close, I would change it as soon as possible (hopefully) that someone who is a real SW engineer will handle most of this (not that I don't want to do SW , it's fun).
If this has been discussed, feel free to forward the stream. I searched for about 30-45 minutes, but couldn't find anything that seemed to discuss this topic.
Thank!
source to share
In C and C ++, you (the application programmer) should avoid beginning identifiers with even a single underscore — all such identifiers are "implementation reserved" in at least some contexts; instead of remembering the exact rules which are easiest to use to start all your ids with a letter.
In C ++, only identifiers containing two consecutive underscores (like yours REG_NAME__BITFIELD1___MASK
) are also reserved for implementation.
So, as far as the standard is concerned, you can do what you want in C, but not C ++.
However, I personally believe that your rationale for wanting to use two underscores in a row (many similar identifiers with structure in their names, make the structure more obvious) is legitimate, and I disagree with the people in the related question who say that it's too hard to tell the difference between one and two underscores when you read. I don't understand why you want to highlight three underlines in a row, and I think it's too difficult to tell the difference between two and three underscores in a row.
(Note: One of the old questions you linked to is about Python, which is a completely unrelated language, it cannot be used to inference about C or C ++.)
(You can use identifiers specific implementations that begin with an underscore, if they are documented, for example, __STDC__
, _Bool
, _IOLBF
- just do not define them yourself, unless documentation (for example _POSIX_C_SOURCE
) in complex programs, the line between "program" and "implementation." may blur, so don't worry if you see a program that defines identifiers that start with an underscore, there's a good chance the authors know exactly what they're doing.)
source to share