CODEWITHSUNDEEP
c
UptownMaker
UptownMaker

Reputation: 79

What's with the '@' symbols in this C code?

I'm digging around the guts of NumPy, trying to figure out why it's not building for me (64-bit Cygwin and Windows 8.1), I've come to this file.

When compilation hits the rad2deg() function (pasted below), I get a segmentation fault. Looking at the file, there are a ton of '@' symbols sprinkled throughout the code. It looks like some kind of wildcard token, or a preprocessor token, but I can't find any information on it anywhere.

#define LOGE2    NPY_LOGE2@c@
#define LOG2E    NPY_LOG2E@c@
#define RAD2DEG  (180.0@c@/NPY_PI@c@)
#define DEG2RAD  (NPY_PI@c@/180.0@c@)

@type@ npy_rad2deg@c@(@type@ x) {
    return x*RAD2DEG;
}`

There are other places in the code where compiler doesn't choke with the '@' characters.

Is there a search term that might explain this?

Upvotes: 2

Views: 124

Answers (1)

UptownMaker
UptownMaker

Reputation: 79

Okay, I've figured it out.

This is some non-standard pre-pre-processor trick, probably implemented in the Python code which builds the C code for NumPy.

/**begin repeat
 * #type = npy_float, npy_double, npy_longdouble#
 * #c = f, ,l#
 * #C = F, ,L#
 */

#define LOGE2    NPY_LOGE2@c@
#define LOG2E    NPY_LOG2E@c@
#define RAD2DEG  (180.0@c@/NPY_PI@c@)
#define DEG2RAD  (NPY_PI@c@/180.0@c@)

@type@ npy_rad2deg@c@(@type@ x)
{
    return x*RAD2DEG;
}

/**end repeat**/

It iterates across the code, replacing the @-surrounded tokens in the code with the tokens in the comment block, generating three nearly identical code blocks operating on different data types.

I suspect the segfault may be coming from improper data types; we'll see.

Upvotes: 3

Related Questions