Question

I am auditing C code that has been generated from Pro*C ages ago, and I have found this:

static const struct sqlcxp sqlfpn =
{
    33,
    "d:¥¥VS¥¥Projects¥¥SOMEDIR¥¥somefile.pc"
};

Absolute paths in code are forbidden by our quality rules.
Is Oracle’s Pro*C→C converter really doing such a bad thing, or did I miss something?

Answer 1

This is used by the undocumented sqlctx() function, and I don’t think you can stop Pro*C generating this structure. I’m not sure it’s intrinsically a bad thing, it’s just something that appears in the generated code and is used internally by Oracle.

You’ll also see the full path of the original .pc file in #line directives, if you have the LINES precompiler option turned on. (This allows the C compiler to report errors against the line number in the original source file, which is much handier than trying to figure it out from the line in the generated source).

I suspect, but I’m not entirely sure, that it’s included in sqlctx() so the value can be used for internal errors too, and possibly for debugging.

From a coding standards perspective, having full paths in your source is probably considered a bad thing because you’d have to touch the code if the paths changed; but that seems rather moot in generated code as the new path will be picked up automatically on next build. However, if there are other reasons – a blanket security requirement to reveal minimal build information maybe – then you should be aware that the full path will also appear in the final binary. (In Linux, strings shows the full path; no idea about a Windows equivalent but I’d imagine it’s there somewhere). If you’re auditing generated code then it sounds like a security rather than practical thing.

You can avoid the full path, if it really matters, by moving into the source directory and just giving the file name with no path in the iname, i.e.

cd d:\VS\Projects\SOMEDIR
proc iname=somefile.pc ...

instead of

proc iname=d:\VS\Projects\SOMEDIR\somefile.pc