Scale for project get_next_line

You should evaluate 1 student in this team

Introduction

Merci de respecter les règles suivantes:

- Restez polis, courtois, respectueux et constructifs pendant le processus
d'évaluation. Le bien-être de la communauté repose là-dessus.

- Identifiez avec la personne évaluée ou le groupe évalué les éventuels
dysfonctionnements de son travail. Prenez le temps d'en discuter et
débattez des problèmes identifiés.

- Vous devez prendre en compte qu'il peut y avoir de légères différences
d'interprétation entre les instructions du projet, son scope et ses
fonctionnalités. Gardez un esprit ouvert et notez de la manière la plus
honnête possible. La pédagogie n'est valide que si la peer-évaluation
est faite sérieusement.

Guidelines

- Ne notez que ce qui est contenu dans le dépôt Git cloné de l'étudiant(e)
ou du groupe.

- Vérifiez que le dépôt Git appartient bien à l'étudiant(e) ou au groupe,
que le projet est bien celui attendu, et que "git clone" est utilisé
dans un dossier vide.

- Vérifiez scrupuleusement qu'aucun alias n'a été utilisé pour vous tromper
et assurez-vous que vous évaluez bien le rendu officiel.

- Afin d'éviter toute surprise, vérifiez avec l'étudiant(e) ou le groupe les
potentiels scripts utilisés pour faciliter l'évaluation (par exemple, des
scripts de tests ou d'automatisation).

- Si vous n'avez pas fait le projet que vous allez évaluer, vous devez lire
le sujet en entier avant de commencer l'évaluation.

- Utilisez les flags disponibles pour signaler un rendu vide, un programme
ne fonctionnant pas, une erreur de Norme, de la triche... Dans ces
situations, l'évaluation est terminée et la note est 0, ou -42 en cas de
triche. Cependant, à l'exception des cas de triche, vous êtes encouragé(e)s
à continuer la discussion sur le travail rendu, même si ce dernier est
incomplet. Ceci afin d'identifier les erreurs à ne pas reproduire dans le
futur.

- Pendant toute la durée de l'évaluation, aucun segfault ou autre arrêt
inattendu, prémature ou incontrôlé ne sera toléré. Auquel cas, la note
finale sera de 0. Utilisez le flag approprié.
Vous ne devriez jamais avoir à éditer un fichier hormis un fichier de
configuration si existant. Dans le cas ou vous souhaitez modifier un fichier,
vous devez expliciter clairement les raisons de l'édition et être en accord
avec l'étudiant(e) évalué(e) avant de faire quoi que ce soit.

- Vous devez aussi vérifier l'absence de fuites mémoire. Toute mémoire
allouée sur le tas doit être libérée proprement avant la fin de l'exécution
du programme.
Vous avez le droit d'utiliser tout outil disponible sur la machine tel que
leaks, valgrind ou e_fence. En cas de fuites mémoire, cochez le flag
approprié.

Attachments

subject.pdf

Partie obligatoire

Norminette

Exécutez la Norminette. En cas d'erreur, l'évaluation s'arrête ici.
Vous pouvez continuer et discuter de l'implémentation du code, mais cela
ne sera pas noté.

Compilation

Il devrait être possible de compiler le projet avec les flags habituels
et le flag -D BUFFER_SIZE. Il doit être possible de compiler ce projet avec et sans
ce dernier en plus des flags : -Wall -Wextra -Werror. S'il y a une erreur,
l'évaluation s'arrête ici. Vous pouvez continuer et discuter de la mise en
œuvre du code, mais la soutenance ne sera pas noté.

Gestion d'erreur

Effectuez au minimum les tests d'erreur suivants afin de vérifier la
gestion d'erreur du programmme.

  • Passez un fd arbitraire a la fonction get_next_line, sur lequel il n'est pas possible de lire (par ex. 42) La fonction doit renvoyer NULL.
  • Vérifiez les retours d'erreur de malloc, read et open. Si la partie "gestion d'erreur" est fausse, merci de ne pas noter la partie suivante, la correction s'arrête ici. Vous pouvez continuer et discuter de l'implémentation du code, mais cela ne sera pas noté.

Tests

En temps qu'évaluateur(ice), vous devez écrire ou apporter un main qui vérifie :

  • La valeur de retour de la fonction get_next_line est NULL en cas d'erreur.
  • Sinon, la fonction renvoie la ligne lue, toujours avec un \n à la fin.

Testez toutes les combinaisons des règles suivantes :

  • Gros BUFFER_SIZE (> 1024)
  • Petit BUFFER_SIZE (< 8, et 1)
  • BUFFER_SIZE de la taille de la ligne à lire

  • 1 de décalage (+/-) entre le BUFFER_SIZE et la ligne

  • Lecture depuis stdin

  • Lecture depuis un fichier

  • (Multiple/Simple) ligne longue (2k+ caractères)

  • (Multiple/Simple) ligne courte (<4 caractères, et 1)

  • (Multiple/Simple) Ligne vide

Ces tests devraient vous permettre de vérifier la validité du projet de
l'étudiant(e). En cas d'erreur, l'évaluation s'arrête ici.

Partie bonus

Les bonus ne seront examinés que si la partie obligatoire est excellente. Cela signifie que la partie obligatoire doit avoir été réalisée du début à la fin, avec une gestion d'erreur parfaite même en cas d'usage inattendu. Si tous les points obligatoires n'ont pas été attribués pendant cette soutenance, aucun point bonus ne sera comptabilisé.

Lecture sur multiples fd

Répétez les tests effectués précédemment mais, cette fois, en lançant
plusieurs instances de get_next_line, chacune utilisant un descripteur
de fichier différent.
Assurez-vous que chaque get_next_line renvoie la bonne ligne.
Ajoutez un descripteur de fichier invalide pour tester la gestion
d'erreurs.

Une seule variable statique

Lisez le code et vérifiez qu'il n'y a bien qu'une seule variable statique.
Attribuez les points bonus si c'est le cas.

Ratings

Don’t forget to check the flag corresponding to the defense