Это используется недокументированной функцией sqlctx(), и я не думаю, что вы можете остановить Pro * C, генерирующий эту структуру.Я не уверен, что это по сути плохо, это просто то, что появляется в сгенерированном коде и используется внутри Oracle.
Вы также увидите полный путь к исходному файлу .pc в *Директивы 1005 *, если у вас включена опция прекомпилятора LINES .(Это позволяет компилятору C сообщать об ошибках по номеру строки в исходном исходном файле, что гораздо удобнее, чем пытаться вычислить его по строке в сгенерированном источнике).
Я подозреваю, но я 'Я не совсем уверен, что он включен в sqlctx(), поэтому это значение можно использовать и для внутренних ошибок, и, возможно, для отладки.
С точки зрения стандартов кодирования, наличие полных путей в вашем источнике, вероятно, считаетсяплохо, потому что вы должны были бы прикоснуться к коду, если пути изменились;но это кажется довольно спорным в сгенерированном коде, поскольку новый путь будет выбран автоматически при следующей сборке.Однако, если есть другие причины - может быть, требуется общее требование безопасности для раскрытия минимальной информации о сборке - тогда вы должны знать, что полный путь также появится в окончательном двоичном файле.(В Linux strings показывает полный путь; понятия о Windows-эквиваленте нет, но я думаю, что он где-то там).Если вы проверяете сгенерированный код, то это звучит скорее как безопасность, а не как практическая вещь.
Вы можете избежать полного пути, если он действительно имеет значение, перейдя в исходный каталог и просто указав имя файла безпуть в iname, то есть
cd d:\VS\Projects\SOMEDIR
proc iname=somefile.pc ...
вместо
proc iname=d:\VS\Projects\SOMEDIR\somefile.pc