Es una mala práctica de utilizar la función () cuando las funciones de biblioteca podrían utilizarse en lugar del sistema? ¿Por qué?

Question

Digamos que hay alguna funcionalidad necesaria para una aplicación en desarrollo que podría lograrse haciendo una llamada al sistema, ya sea a un programa de línea de comandos o la utilización de una biblioteca. Suponiendo que la eficiencia no es un problema, es una mala práctica simplemente hacer una llamada al sistema a un programa en lugar de utilizar una biblioteca? ¿Cuáles son las desventajas de hacer esto?

Para hacer las cosas más concreta, un ejemplo de este escenario sería una aplicación que necesita para descargar un archivo desde un servidor web, ya sea el programa o la biblioteca cURL libcurl podría ser utilizado para esto.

Answer 1

A menos que usted está escribiendo código para un solo sistema operativo, no hay manera de saber si su llamada al sistema va a trabajar incluso. ¿Qué pasa cuando hay una actualización de sistema o una actualización del sistema operativo?
No utilizar una llamada al sistema si hay una biblioteca para hacer la misma función.

Answer 2

Yo prefiero bibliotecas debido a la cuestión de la dependencia, a saber, el ejecutable no podría estar allí cuando usted lo llama, pero la biblioteca será (suponiendo que las referencias de biblioteca externos quedan atendidos cuando el proceso se inicia en su plataforma). En otras palabras, el uso de las bibliotecas parecería garantizar un resultado más estable y predecible en los entornos más de llamadas al sistema haría.

Answer 3

Hay varios factores a tener en cuenta. Uno una de las claves es la fiabilidad de si el programa externo estará presente en todos los sistemas donde está instalado el software. Si existe la posibilidad de que se encuentra, entonces tal vez es mejor hacerlo dentro de su programa.

Con un peso en contra de eso, usted podría considerar la posibilidad de que el código adicional cargado en su programa es prohibitivo - que no es necesario el exceso de código para una parte tan raramente utilizada de su aplicación

.

La función del sistema () es conveniente, pero peligroso, no menos porque invoca una concha, por lo general. Usted puede ser mejor de llamar el programa más directamente - en Unix, a través del tenedor () y las llamadas al sistema exec (). [Tenga en cuenta que una llamada al sistema es muy diferente de llamar a la función system(), por cierto!] Otoh, es posible que tenga que preocuparse de asegurar que todos los descriptores de archivos abiertos en su programa están cerrados - especialmente si su programa es una especie de demonio que se ejecuta en nombre de otros usuarios; esto es un problema menor si no están utilizando privilegios especiales, pero sigue siendo una buena idea de no dar acceso al programa invocado a cualquier cosa que no tenía la intención. Puede que tenga que mirar a la llamada fcntl() sistema y el FD_CLOEXEC bandera.

En general, es más fácil mantener el control de las cosas si se construye la funcionalidad en su programa, pero no es una decisión trivial.

Answer 4

La seguridad es una preocupación. Un rizo malicioso podría causar estragos en su programa. Depende de si se trata de un programa personal, donde la velocidad de codificación es su principal objetivo, o una aplicación comercial donde las cosas como la seguridad juegan un factor.

Answer 5

Las llamadas al sistema son mucho más difíciles de realizar con seguridad.

Todo tipo de personajes divertidos necesitan ser codificados correctamente para pasar argumentos a, y los tipos de codificación pueden variar según la plataforma o incluso la versión del comando. Así que hacer una llamada al sistema que contiene los datos del usuario en absoluto requiere una gran cantidad de cordura comprobación y es fácil cometer un error.

Answer 6

Si, como se mencionó anteriormente, tener en cuenta la diferencia entre las llamadas al sistema (como fcntl () y abierta ()) y el sistema () llama. :)

En las primeras etapas de la creación de prototipos de un programa en C, que a menudo hacen llamadas externas a programas como grep y SED para la manipulación de archivos a través de popen (). No es seguro, no es seguro, y ciertamente no es portátil. Pero puede permitirle a ponerse en marcha rápidamente. Eso es valioso para mí. Me permite centrarse en el núcleo muy importante del programa, por lo general la razón por la que solía c en el primer lugar.

En lenguajes de alto nivel, más vale que tengas una buena razón. :)

Answer 7

En lugar de hacer bien, me Unix y construir un marco alrededor de la escritura de su aplicación, utilizando los argumentos de línea de comandos y la entrada estándar.

Answer 8

han mencionado otros de buenos puntos (fiabilidad, seguridad, seguridad, portabilidad, etc.) - pero voy a echar a otro. Actuación. En general, es muchas veces más rápido que llamar a una función de biblioteca o incluso generar un nuevo subproceso entonces es comenzar todo un proceso nuevo (y todavía tiene que comprobar correctamente / verificar que es la ejecución y analizar su salida!)