¿por qué clang ++ se comporta de manera diferente a clang ya que el primero es un enlace simbólico de este último?

Question

Tengo un programa C que intenta modificar un literal de cadena const. Como ahora aprendí que esto no está permitido.

Cuando compilo el código con clang test.c el compilador no da ninguna advertencia. Pero cuando compilo con clang++ test.c da una advertencia:

test.c: 6: 15: advertencia: la conversión de cadena literal a 'char *' está obsoleto [-Wdeprecated-grabables-strings] Char * s = "hola mundo"; ^

El problema es que resulta que clang++ es sólo un enlace símbolo de clang:

ll `which clang++` 
lrwxr-xr-x 1 root admin 5 Jan 1 12:34 /usr/bin/clang++@ -> clang 

Así que mi pregunta es ¿cómo podría clang++ se comporta de forma diferente a partir clang dado que es un enlace símbolo de clang ?

Answer 1

Clang está mirando su argv[0] y alterando su comportamiento dependiendo de lo que ve. Este es un truco poco común y desalentador, pero no raro, que se remonta como mínimo a 4.2BSD ex y vi, que eran el mismo ejecutable, y probablemente más.

En este caso, clang está compilando su archivo .c como C, y clang++ lo está compilando como C++. Esta es una verruga histórica en la que no debes confiar; utilice el comando de compilación apropiado y asegúrese de que su extensión de archivo refleje el contenido verdadero del archivo.

Answer 2

Por convención, el nombre por el que se invoca un comando se pasa como argv[0]; no es especialmente inusual que los programas cambien su comportamiento de acuerdo con esto. (Históricamente, ln, cp, y mv eran enlaces duros al mismo ejecutable para la Investigación Unix y utilizan argv[0] para decidir qué acción hay que hacer. Además, la mayoría de las conchas buscan un líder - en argv[0] para decidir si debe ser un shell de entrada.) A menudo también hay otra forma de obtener el mismo efecto (opciones, variables de entorno, etc.); deberías, en general, usar esto en lugar de jugar juegos argv[0].

Existen razones para hacerlo, pero en la mayoría de los casos no es una buena idea confiar en él o diseñar programas a su alrededor.