Ce code retourne l'erreur : "Info: You do not return the correct value. — lseek() should at least be called once."

Pourquoi ça renvoie cette erreur puisque le code contient un lseek ?

Hello

I spotted an issue in the week 5 exercise "save struct into file"

to me, when the call to write() fails, the program should close the file, then return -2.

I actually found out that inginious validates a submission which doesn't close the file when an error occurs in write().

here is my submission number : #5c84ee6c6779dd43db062677

Pour la question test, un étudiant propose

#include <stdlib.h>
#include <string.h>
int main(int argc,char *argv[]){
if(!strcmp(argv[2],"-ne")){
return atof(argv[1])==atof(argv[3]);
}
else if(!strcmp(argv[2],"-ge")){
return atof(argv[1])<atof(argv[3]);
}
else if(!strcmp(argv[2],"-gt")){
return atof(argv[1])<=atof(argv[3]);
}
else if(!strcmp(argv[2],"-le")){
return atof(argv[1])>atof(argv[3]);
}
else if(!strcmp(argv[2],"-lt")){
return atof(argv[1])>=atof(argv[3]);
}
else if(!strcmp(argv[2],"-eq")){
return atof(argv[1])!=atof(argv[3]);
}
else{
return 0;
}
}

comment faire en C pour compter efficacement le nombre de sous-fonctions qui sont implémentés et les forcer à utiliser des sous-fonctions ?

Lorsqu'on écrit :

calc: calc.o operations.o
    gcc -o calc calc.o operations.o

les tests passent, lorsqu'on écrit :

calc: calc.o operations.o
    gcc -o calc operations.o calc.o 

ils ne passent pas alors que le binaire est bien là. Je suppose que le binaire peut être différent de celui de référence en fonction des zones mémoires choisies pour les deux codes et que donc le diff entre les deux binaires n'est pas toujours correct.

`int pid = fork(); if(pid==-1){return -1;}
if(pid==0)
{
//if(dup2(fileno(fopen(output_path,"w")),STDOUT_FILENO)==-1) //test1
if(dup2(open(output_path,O_RDWR|O_CREAT|O_TRUNC),STDOUT_FILENO)==-1) //test2
{
return -1;
}
execve(path,argv,NULL);
}
else
{
int exitcode;
int p = waitpid(pid,&exitcode,0);
if(p==-1){return -1;}

if(!WIFEXITED(exitcode)) //pid didn't end correctly
{
    return -1;
}
else
{
    return WEXITSTATUS(exitcode);
}

}`
avec la ligne test1, ca passe, avec test2, l'on obtient le message d'erreur suivant :

Running suite(s): Shell
75%: Checks: 4, Failures: 1, Errors: 0
shell_test.c:85:F:Core:test_redirect:0: Assertion 'fd >= 0' failed
test_redirect s’est terminé après le message suivant : Exécution de "echo 'Hello World' > file_a"

Dans la question https://inginious.info.ucl.ac.be/course/LSINF1252/s5_file_exists
le test est correct même si l'étudiant ne fait pas close lorsque le fichier peut être ouvert. Il me semble important de vérifier qu'ils ferment bien les fichiers qu'ils ont ouverts.

Pas inclus dans Linux, mais voir https://stackoverflow.com/questions/8534274/is-the-strrev-function-not-available-in-linux#8534275

• [S3] Pointer arithmetic : malheureusement, apparemment faire de l'arithmétique sur void* est autorisée dans le setup actuel. Il faudrait réussir à empêcher ça, car les étudiants ne comprennent pas l'intérêt de l'exercice, et arrivent à bricoler une solution très approximative en chipotant avec des void*.

Il y a un problème dans les tests de Filtering Linked List. Si un étudiant fait le code suivant:

return 0;

Ça fait faire une SIGSEV aux tests et donc, ça ne donne aucun feedback à l'étudiant

• Certains étudiants ont passé pas mal de temps à cette séance sur [S2] strlen, strcat et strcasecmp, il est manifestement un peu buggé (le feedback global bug par moments, apparemment quand il y a segfault). Il faudrait peut-être alléger un peu l'énoncé (bcp bloquaient sur le fait que strcasecmp devaient aussi comparer par rapport à l'ordre alphabétique, on pourrait remplacer ça par un simple retour binaire).

Si on se trompe sur le mode du fichier à la création avec open, il retourne que le close n'est pas bon.
Exemple : https://inginious.info.ucl.ac.be/submission/5aa2722baff4147ad20bcff5

Quand un étudiant ne change pas le next du noeud ajouté au début de la liste, les tests font une SIGSEV.
Ex:

struct node *n;
n =(struct node*)malloc(sizeof(struct node));
if(n==NULL) return 1;
(*list).size=(list->size)+1;
(*n).value = value;
(*list).first = n;
return 0;

Pour l'exercice de la S4 ordered linked list il est demandé d'insérer un élément à la bonne position en fonction de l'ordre de la liste. Cependant s'il n'y a qu'un élément présent dans la liste, on ne peut déduire si l'ordre est croissant ou décroissant et donc s'il faut insérer le noeud avant ou après le noeud déjà présent.
Il faudrait peut-être préciser dans les consignes ce qu'il faudrait faire dans ce cas là, ici il me semble qu'il fallait l'insérer avant.

Ce code déclenche une "time limit exceeded" mais il n'y a pas de boucle infinie dans le code de l'étudiant à première vue.

Peut-être que les pointeurs sont faux et que ça déclenche une boucle sur une zone de mémoire bizarre dans le code de test. Si c'est ça, un fix rapide serait de checker si le code de test parcourt plus d'éléments que ceux attendus.

La structure correcte met le pointeur sur l'avant dernier noeud et non le dernier comme annoncé.

Il faudra mettre à jour toute la tâche (énoncé, solution et tests).

Pour réussir tous les tests de reading from the wire [S3] il n'est pas nécessaire d'appeler la fonction mode_read, le buffer mis en argument est déjà rempli avec le bon tableau de char.

Issue très similaire à #19

Ce code, sans aucune boucle, déclenche un "Time Limit Exceeded". La boucle se trouve donc probablement dans le code de test.

Un fix rapide serait de checker si le code de test ne parcourt pas plus d'éléments de la stack que ceux attendus et retourner une erreur si c'est le cas.

Il manque un run pour que la tâche fonctionne.

un code incorrect au niveau de la taille passé comme argument à malloc mais qui passe en vert

for(int i =0; i <10;i++){
size_t *r= (size_t *)malloc((s+1)*sizeof((size_t)s));

if(r!=NULL){
    return(void *)r;      
}
    sleep (5);

}

return NULL;

La tâche ne contenait pas de run, j'en ai ajouté un temporaire.

Pablo, pourrais-tu repasser dessus afin de confirmer que cela correspond à ce que tu avais prévu ?

Ce code passe tous les tests alors qu'il ne devrait pas (accès à un byte au-delà de la zone allouée)

char *ptr=(char )malloc((nmemb)(size));
if (ptr == 0){
return NULL;
}
int i;
for(i=0; i<nmemb; i++){
ptr[i] = 0 ;
}
ptr[nmemb]='\0';
return ptr;

Pour le push, si le deuxième malloc fails, les tests ne vérifient pas que noeud initialisé au préalable est libéré, ce qui peut créer de grosses memory leak.
ex:

if(!head) return 1;
struct node* new = (struct node*) malloc(sizeof(struct node));
if(!new) return 1;
new->name = (char*) malloc(sizeof(strlen(value)+1));
if(!new->name){
    //free(new);
    return 1;
}
strcpy(new->name,value);
new->next = *head;
*head = new;
return 0;

Et ce code passe tous les tests

Advanced queue devrait fournir des informations plus détaillées lorsqu'un test échoue (par ex. si free a été oublié, il faut le remonter via push_info_msg).

Il y a un souci avec cette question.
En effet, sans avoir répondu à toutes les sous questions et en ayant un souci avec ma seule réponse, j'obtiens 100% pour cet exercice.

Coordialement.

Il faudrait rajouter un accès à une archive zip pour qu'ils puissent tester leur Makefile localement, le feedback d'INGInious est binaire pour le moment, ce qui rend leur Makefile indébugable.