Thread: Strange macro, valid?

Originally Posted by Exit

Your implication was that a space had been omitted - that is not the case.

It is the case. A space SHOULD have been there for clarity. It's not. Thus, everybody wonders what this "weird new syntax is."

Consider, also, the actual requirement, which I have detailed.

The requirement doesn't change the fact that there is NO SUCH MACRO SYNTAX as A(x)B(y). Running the macro through the preprocessor proves it definitively.

The programmer was simply trying to be one of the "Three C's": Cute, Clever, or Confusing.

The only use of this type of macro

Code:

#define MMM_X(x)_Z(z)	(0x0C + (((x)-1)*3 + ((z)-1))*4)

Which i can see is that; you call this macro with two name such as MMM_X and Z. What do you all tthink. Is there any other use of using that?

ssharish2005

There are no other macros defined in the header. All the other defines are either constant base addresses, register offsets or bit masks.

Originally Posted by Exit

There are no other macros defined in the header. All the other defines are either constant base addresses, register offsets or bit masks.

I really don't get what your question is anymore. You asked if the macro is valid. You also say it compiles. This pretty much proves the macro is "valid" in that sense. But this doesn't mean there is some kind of macro syntax A(x)B(y) which takes two arguments x and y. It would be written AB(x, y) instead. The preprocessor proves THIS.

So what we have here is some bizarre code with unclear motivations. In other words, bad code.

Originally Posted by Exit

In a header I was looking at, I saw this...

Code:

#define MMM_X(x)_Z(z)	(0x0C + (((x)-1)*3 + ((z)-1))*4)

... is that valid? I don't recall seeing a macro like that before.

Subject to a few conditions, this is valid. Although it would be more clearly expressed with an additional space before the _Z, that space is not mandatory.

As to what it does: that depends on what _Z actually is. In practice, it is probably another macro and z is probably a variable that is accessible at the point where the macro MMM_X is used (eg a global).

I really don't get what your question is anymore.

That wasn't an additional question, simply a statement of fact.

As to what it does: that depends on what _Z actually is. In practice, it is probably another macro and z is probably a variable that is accessible at the point where the macro MMM_X is used (eg a global).

That line is the only line in the header which contains macro definition, all other lines are constant addresses, register offsets or bitmasks. There are no global variables.

Okay, I am in the office now and have had the chance to play with it a little.

Code:

#include <stdio.h>
#define MMM_P(x)_C(z) (0x0C + (((x)-1)*3 + ((z)-1))*4)
#define OFFSET (0xF0000 + 0xe800)

int main()
{
	int i;
	int j;
	unsigned int x;

	for (i=1; i<6; i++)
	{
		for (j=1; j<4; j++)
		{
			x = OFFSET + MMM_P(i)_C(j);
			printf("Port %i Register %i addr : %08X\n", i,j,x);
		}
		printf("\n");
	}
	
	return 0;
}

This program, with the odd looking macro construction does not compile. I get the following errors from gcc...

Code:

junk2.c: In function ‘main’:
junk2.c:15: error: ‘z’ undeclared (first use in this function)
junk2.c:15: error: (Each undeclared identifier is reported only once
junk2.c:15: error: for each function it appears in.)
junk2.c:15: error: called object ‘_C(<erroneous-expression>)’ is not a function
junk2.c:15: error: expected ‘;’ before ‘_C’

This program, with a more traditional looking macro definition does compile...

Code:

#include <stdio.h>
#define MMM_P_C(x,z) (0x0C + (((x)-1)*3 + ((z)-1))*4)
#define OFFSET (0xF0000 + 0xe800)

int main()
{
	int i;
	int j;
	unsigned int x;

	for (i=1; i<6; i++)
	{
		for (j=1; j<4; j++)
		{
			x = OFFSET + MMM_P_C(i,j);
			printf("Port %i Register %i addr : %08X\n", i,j,x);
		}
		printf("\n");
	}
	
	return 0;
}

... and gives the expected output.

Code:

Port 1 Register 1 addr : 000FE80C
Port 1 Register 2 addr : 000FE810
Port 1 Register 3 addr : 000FE814

Port 2 Register 1 addr : 000FE818
Port 2 Register 2 addr : 000FE81C
Port 2 Register 3 addr : 000FE820

Port 3 Register 1 addr : 000FE824
Port 3 Register 2 addr : 000FE828
Port 3 Register 3 addr : 000FE82C

Port 4 Register 1 addr : 000FE830
Port 4 Register 2 addr : 000FE834
Port 4 Register 3 addr : 000FE838

Port 5 Register 1 addr : 000FE83C
Port 5 Register 2 addr : 000FE840
Port 5 Register 3 addr : 000FE844

The strange macro construct does not prevent the program compiling if it is not used.

Well, there you go.

That is exactly what I'd expect from the two code-snippets you show - that is, that one of them contains an invalid macro. I suspect also that you will find a macro

Code:

#define _Z(z) int z = something;

someplace in your code - this may NOT be in the same header-file that you have the MMM macro tho' (e.g. it may be in the file that USES the latter macro, and it may even differ from one function to another!

[Obviously, the code-snippet I've shown here is absolutely a guess, and it may well be quite different in all sorts of ways - but I'm 100% sure that such a macro definition exists, and that it most likely declares a local variable!]

--
Mats

So, could you tell us which driver this belongs to, as you've already explained that it's the Linux kernel that it belongs to?

--
Mats

Originally Posted by Exit

I get these errors from a kernel build when I try to use the "strange" macro construction in a device driver. If there is another macro/function it is sufficiently well hidden that a regular OS make can't find it.

Code:

drivers/dxl/cardid.c: In function `cardid_ioctl':
drivers/dxl/cardid.c:173: warning: implicit declaration of function `_C'
drivers/dxl/cardid.c:173: error: `z' undeclared (first use in this function)
drivers/dxl/cardid.c:173: error: (Each undeclared identifier is reported only once
drivers/dxl/cardid.c:173: error: for each function it appears in.)
drivers/dxl/cardid.c:173: error: called object is not a function
drivers/dxl/cardid.c:173: error: syntax error before "_C"

I thought you said that it compiles and builds correctly - am I the one that is confused or are you?

Thanks for the details of what component it is that are causing a problem.

--
Mats

LOL. Yes, it compiles and builds fine until I try and use it, at that point, it gives the errors I posted. Sorry, should have been clearer. I am using other values from the same header without issue, only when I try to obtain the offset to a port control register using the macro does it fail.

Ehm, yes, and there's something broken somewhere, either the macro itself is broken, or there's a missing _C macro somewhere (perhaps there used to be one somewhere else and it got lost at some point). I'd contact the producer of that driver, as it appears that the source isn't on the web - if I google for dxl/cardid.c, it comes up with very little useful stuff.

--
Mats

I'd be suprised if it came up with anything at all, cardid.c is one of my drivers and I only wrote it last week! The header comes with the developers kit for the KS8695PX chip.

I will write a patch for the header and submit it to the maintainer of that particular branch of the kernel.