Pergunta

Estou auditando o código C que foi gerado a partir de Pró*C anos atrás, e eu encontrei isso:

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

Caminhos absolutos no código são proibidos pelas nossas regras de qualidade.
O conversor Pro*C→C da Oracle está realmente fazendo uma coisa tão ruim ou eu perdi alguma coisa?

Foi útil?

Solução

Isto é usado pelos indocumentados sqlctx() função, e não acho que você possa impedir o Pro*C de gerar essa estrutura.Não tenho certeza se isso é intrinsecamente ruim, é apenas algo que aparece no código gerado e é usado internamente pela Oracle.

Você também verá o caminho completo do original .pc arquivo em #line directivas, se você tiver a LINES opção de pré-compilador ligadas.(Isso permite que o compilador C relate erros no número da linha no arquivo de origem original, o que é muito mais prático do que tentar descobrir isso a partir da linha na fonte gerada).

Suspeito, mas não tenho certeza, que esteja incluído no sqlctx() portanto, o valor também pode ser usado para erros internos e possivelmente para depuração.

Do ponto de vista dos padrões de codificação, ter caminhos completos em sua fonte provavelmente é considerado uma coisa ruim porque você teria que mexer no código se os caminhos mudassem;mas isso parece bastante discutível no código gerado, pois o novo caminho será escolhido automaticamente na próxima compilação.No entanto, se houver outros motivos - talvez um requisito geral de segurança para revelar informações mínimas de compilação - então você deve estar ciente de que o caminho completo também aparecerá no binário final.(No Linux, strings mostra o caminho completo;não faço ideia sobre um equivalente do Windows, mas imagino que esteja em algum lugar).Se você estiver auditando o código gerado, isso parece mais uma questão de segurança do que prática.

Você pode evitar o caminho completo, se for realmente importante, indo para o diretório de origem e apenas fornecendo o nome do arquivo sem caminho no iname, ou seja

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

em vez de

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

Outras dicas

Na verdade, há um motivo:e10825 p313:

Observação:O valor do hash sqlctx é gerado com base no parâmetro iname passado para o comando pro*c/c ++.Isso pode causar problemas nos aplicativos em que os arquivos com o mesmo nome são armazenados em diferentes diretórios que contêm funções diferentes e os scripts de construção são enviados ao diretório físico para pré -compilar o programa.Como resultado, não há necessidade de colocar os modos em um nível mais alto e arquivos pré -compilados usando seus nomes de caminho.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top