les meilleures choses ont un début ...

This commit is contained in:
Denis Monnerat 2024-09-03 11:18:13 +02:00
parent a36b11c986
commit 88f2be455e
2 changed files with 162 additions and 1 deletions

View File

@ -1,2 +1,24 @@
# BUT2FI_2024_R3.05
# BUT2FI-R3.05
Ce dépôt rassemble les ressources (cours, td, tp, projets, contrôles) de la ressource
R3.05 (Programmation système).
> Il s'agit de vous donner un aperçu des concepts système sur la gestion de la mémoire, des fichiers et des processus
> du système linux. Même s'il est impossible en 8 semaines d'appréhender tous les détails, vous ne devez pas vous borner à
> être de simples utilisateurs des api systèmes. Le but est de comprendre les concepts et leurs mises en oeuvre.
**Vous placerez tous les programmes écrits en tp dans un dépôt r305_dm, dont je serai collaborateur.**
* Ce dépôt sera structuré de manière hiérarchique : tp1, tp2, tp3, etc.
* A chaque exercice correspond un dossier avec vos reponses : ex1, ex2, etc.
À la fin de chaque séance, je dois avoir accès à **tout** ce que vous avez fait durant le tp.
Merci de lire les [quelques recommandations](./misc/CODE.md) sur les bonnes pratiques d'écriture de code.
#### Semaine 1 (04/09 - 08/09)
Rappels sur la gestion de la [mémoire](cours/memoire.pdf), [td1](td/td1/td1.pdf), [tp1](tp/tp1/).

139
misc/CODE.md Normal file
View File

@ -0,0 +1,139 @@
## Coding Style
Le code ne doit pas seulement être "correct" et "performant". Il doit être aussi
lisible et compréhensible par un autre être humain.
La meilleure façon d'écrire du code lisible est de choisir un style cohérent, et de
s'y tenir.
La suite est un ensemble de conseils. Vous pouvez suivre le ["K&R style"](http://www.cas.mcmaster.ca/~carette/SE3M04/2004/slides/CCodingStyle.html)
(de Brian Kernighan et Dennis Ritchie) qui ont créé le langage C, ou le style [GNU](https://www.gnu.org/prep/standards/standards.html#Writing-C).
### Un exemple
```c
/** @brief Reverse the characters of src into dst.
* @param src the input string to reverse
* @param dst the reversed string
* @return the length of src
*/
size_t strreverse(char* dst, const char* src) {
assert(dst && src); // neither parameter should be NULL
assert(dst != src); // we cant reverse a string into itself
size_t len = strlen(src);
for (size_t pos = 0; pos != len; ++pos) {
dst[pos] = src[len - pos - 1];
}
dst[len] = 0;
return len;
}
```
- noms de variables courts et parlants,
- utilisation des types du C pour fournir des informations
sur les arguments `const char *`,
- utlisation des types utilisés par les librairies
standards (`strlen` renvoie un `size_t`),
- utilisation des fonctions standards,
- conforme aux conventions des librairies standards (nom de fonction, ordre des arguments),
- une description brève de la fonction,
- utilisation d'`assert` pour tester des pre-conditions.
La règle d'or est d'être cohérent !
#### Formatage
- choisir une indentation et s'y tenir. 4 espaces est un standard,
- passer à la ligne pour séparer les sections logiques de votre programme,
- éviter les longues lignes. 80 caractères est une limite commune,
- soyez consistant avec les accolades et les blocs,
- soyez consistant avec les espaces entre opérateurs,
- les noms de fonctions doivent être clairs et concis. Le nom doit être suffisant pour
comprendre le rôle d'une variable/fonction/strucutre.
#### Commentaires
Commenter son code est une bonne idée. Mais trop de commentaires en est une mauvaise.
- le code doit être lisible,
- commenter ce qui n'est pas triviale,
- commenter chaque fonction sur ce qu'elle fait, ses paramètres, et ce qu'elle
retourne. On peut utiliser le standard de Doxygen.
- s'il y a plusieurs fichiers sources, écrire un commentaire au début du fichier
pour expliquer son rôle.
#### Divers
- vérifier les retours d'erreurs,
- éviter les variables globales, à moins que ce ne soit indispensable,
- utiliser systématiquement un fichier d'entête avec les signatures de
vos fonctions,
- utiliser `errno.h` (appels systèmes, fonctions standards).
exemple avec l'appel système `write` :
```
ERRORS
These functions shall fail if:
EAGAIN The file is neither a pipe, nor a FIFO, nor a socket, the O_NONBLOCK flag is set for the file descrip
tor, and the thread would be delayed in the read operation.
EBADF The fildes argument is not a valid file descriptor open for reading.
EBADMSG
The file is a STREAM file that is set to control-normal mode and the message waiting to be read in
cludes a control part.
EINTR The read operation was terminated due to the receipt of a signal, and no data was transferred.
EINVAL The STREAM or multiplexer referenced by fildes is linked (directly or indirectly) downstream from a
multiplexer.
EIO The process is a member of a background process group attempting to read from its controlling termi
nal, and either the calling thread is blocking SIGTTIN or the process is ignoring SIGTTIN or the
process group of the process is orphaned. This error may also be generated for implementation-defined
reasons.
EISDIR The fildes argument refers to a directory and the implementation does not allow the directory to be
read using read() or pread(). The readdir() function should be used instead.
EOVERFLOW
The file is a regular file, nbyte is greater than 0, the starting position is before the end-of-file,
and the starting position is greater than or equal to the offset maximum established in the open file
description associated with fildes.
The pread() function shall fail if:
EINVAL The file is a regular file or block special file, and the offset argument is negative. The file offset
shall remain unchanged.
ESPIPE The file is incapable of seeking.
The read() function shall fail if:
EAGAIN The file is a pipe or FIFO, the O_NONBLOCK flag is set for the file descriptor, and the thread would
be delayed in the read operation.
EAGAIN or EWOULDBLOCK
The file is a socket, the O_NONBLOCK flag is set for the file descriptor, and the thread would be de
layed in the read operation.
ECONNRESET
A read was attempted on a socket and the connection was forcibly closed by its peer.
ENOTCONN
A read was attempted on a socket that is not connected.
ETIMEDOUT
A read was attempted on a socket and a transmission timeout occurred.
These functions may fail if:
EIO A physical I/O error has occurred.
ENOBUFS
Insufficient resources were available in the system to perform the operation.
ENOMEM Insufficient memory was available to fulfill the request.
ENXIO A request was made of a nonexistent device, or the request was outside the capabilities of the device.
```