Car si j'avais des fichiers qui changeaient de type
Non, jamais. Un fichier peut changer de contenu, être tronqué, étendu, mais il ne change JAMAIS de type :
- un fichier régulier reste un fichier régulier
- un répertoire reste un répertoire
- une FIFO nommée reste une FIFO nommée
- une socket UNIX reste une socket UNIX (bon ce type-là, on peut pas le
open de toute façon)
- un périphérique reste un périphérique (du même type, de mêmes numéros)
Par contre,
un chemin (un nom) peut désigner une chose puis une autre.
En Unix tradi, tu as bien un moyen simple pour ouvrir un fichier uniquement si c'est un répertoire (l'option
O_DIRECTORY) mais pas uniquement si c'est un fichier normal!!!
Et toi, tu trouves ça acceptable, parce que tu n'y comprends rien.
en l'espace de quelques microsecondes
Comment peux-tu garantir qu'il ne s'écoule pas plus longtemps?Tu ne peux pas. La plupart du temps, il ne s'écoulera qu'un temps trivial. Parfois, le thread unique du processus sera suspendu, et il s'écoulera beaucoup plus de temps.
je ne me dirais pas que l'appel open() est mal fichu, mais m'interrogerais plutôt sur la raison de ces changements, et sur l'opportunité de lancer des traitements sur des données aussi instables.
Oui, parce que
tu ne sais pas programmer.
Tu es parfaitement incompétent. Ce n'est pas une attaque, c'est un constat.
L'espace des noms de fichier est partagé, comme une variable globale. Les autres processus peuvent modifier les noms de fichiers à tout moment.
Tu peux croiser les doigts, mais tu n'as pas de garantie. Donc
tu ne peux pas assurer la sécurité.Mais tu ne comprends RIEN à la sécurité informatique, donc peu importe!
On se fout pas mal de la qualité de mon code C
Non.
Ton code est incorrect et
tu ne connais pas Unix, sinon tu saurais que tout processus a une valeur de retour. C'est un des premiers trucs qu'on apprend!
D'ailleurs make lui-même utilise cette valeur de retour : si elle est non nulle, il s'arrête parce que ça indique une erreur. Si tu ignores cela,
c'est que tu ne connais pas le fonctionnement de make.
ou des options de compilation,
Tu méconnais l'importance des options parce que
tu ne sais pas programmer.
Les bonnes options t'informent de ce genre d'erreur.
car elles n'étaient pas l'objet de ton "défi" :Le Makefile que j'ai pondu en deux minutes répond très exactement à ce cahier des charges.
Non. Déjà tu répliques dans un fichier externe les dépendances qui sont déjà indiquées dans le code source. Si tu trouve ça bien, tu ne comprends vraiment rien à la programmation et à l'informatique.
Si tu supprimes le #include dans le .c et le fichier .h, make va refuser de compiler ton programme.
Cela n'arrive pas dans un vrai environnement de programmation qui n'est pas cautionné par les gens ... comme toi.