La testul test_ferror_read_large, testul se plânge că ar fi trebuit să returnez
0 dar eu returnez 8192.
Dar dacă citesc 8192 (2 apeluri read() au succes) octeți și după am eroare, nu
ar trebui să returnez câți am citit cu succes și abia citirile următoare să
eșueze direct?
Am o versiune veche
Pe testarea locală, dar și pe VMchecker, anumite teste eșuează dar nu afișează
nicio eroare. Spre exemplu, testul 10 (test_fputc_large_file). Local când rulez
manual executabilul văd că returnează 0 drept $?. Există mai multe teste cu
această situație.
Sent from Mail for Windows 10
___
de Operare
Subject: Re: [so] [SO][Tema2][Multi] Probleme test_ferror_read_large
On Sat, 16 Mar 2019 at 13:10, Paul-Stelian Olaru via so
wrote:
>
> La testul test_ferror_read_large, testul se plânge că ar fi trebuit să
> returnez 0 dar eu returnez 8192.
>
>
>
> Dar dacă c
Sat, 16 Mar 2019 at 13:10, Paul-Stelian Olaru via so
wrote:
>
> La testul test_ferror_read_large, testul se plânge că ar fi trebuit să
> returnez 0 dar eu returnez 8192.
>
>
>
> Dar dacă citesc 8192 (2 apeluri read() au succes) octeți și după am eroare,
> nu ar trebui să r
Tu rulezi make din Powershell. Evident nu va găsi comenzile oferite de Cygwin.
Checkerul se rulează în Cygwin.
[P.S: Atașamentele se poate să nu ajungă în arhiva mailing list-ului. Folosește
și tu imgur sau ceva similar!]
Sent from Mail for Windows 10
From: Tuculina Gabriel
Sent: Saturday, Mar
tests with no error output
On Sat, 16 Mar 2019 at 13:36, Paul-Stelian Olaru via so
wrote:
>
> Pe testarea locală, dar și pe VMchecker, anumite teste eșuează dar nu
> afișează nicio eroare. Spre exemplu, testul 10 (test_fputc_large_file). Local
> când rulez manual executabilul văd că
În cerință nu este foarte clar când ar trebui so_fclose(stream) să returneze 0
și când SO_EOF.
În teste, văd că după o eroare la fgetc/fread ar trebui să returneze 0 și după
o eroare la fputc/fwrite ar trebui SO_EOF. Deci codul de retur bănuiesc că nu
depinde de so_feof(stream).
Când mă folose
, 2019 1:52 PM
To: Paul-Stelian Olaru; Sisteme de Operare
Subject: Re: [so] [SO][Tema2][Multi] Probleme test_ferror_read_large
On Sat, 16 Mar 2019 at 13:10, Paul-Stelian Olaru via so
wrote:
>
> La testul test_ferror_read_large, testul se plânge că ar fi trebuit să
> returnez 0 dar eu retu
Sent: Saturday, March 16, 2019 6:06 PM
To: Paul-Stelian Olaru; Sisteme de Operare
Subject: Re: [so] [SO][Tema 2][Linux]Inconsistență la codul de retur so_fclose()
On Sat, 16 Mar 2019 at 17:38, Paul-Stelian Olaru via so
wrote:
>
> În cerință nu este foarte clar când ar trebui so_fclose(stre
Subject: Re: [so] [SO][Tema 2][Linux]Inconsistență la codul de retur so_fclose()
On Sat, 16 Mar 2019 at 17:38, Paul-Stelian Olaru via so
wrote:
>
> În cerință nu este foarte clar când ar trebui so_fclose(stream) să returneze
> 0 și când SO_EOF.
>
>
>
> În teste, văd că d
Pe testul 0 am eroarea asta:
so_stdio.c:13: ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
Linia corespunzătoare (vizibilă și pe repo) arată cam așa:
static int so_prepare_read(SO_FILE *stream); // 13
static int so_prepare_write(SO_FILE *stream); // 14
static int so_readahead(SO_FILE
Got 0 expected 0 este neașteptat.
Pentru a putea număra corect nr de syscall-uri trebuie să le faci prin
funcțiile ReadFile, WriteFile, CreateFile, CloseHandle etc. Și trebuie ca
so_fileno să returneze HANDLE-ul.
Sent from Mail for Windows 10
From: Ionuț Mihalache via so
Sent: Saturday, March
Fseek ar trebui să facă fflush, apoi lseek/SetFilePosition pentru simplitate.
Ai făcut chestia asta? După un apel fseek sau fflush bufferul va fi gol, și din
nou programul trebuie să se comporte la fel (mai puțin performanța) ca situația
fără buffer. Ai verificat asta?
From: Cristin Sirbu via s
Vezi că tu faci Valgrind pe Bash, nu pe programul de teste!
https://imgur.com/a/4vTPtgI
Vezi în exemplul meu cum se poate rula corect Valgrind pe testul în sine.
Sent from Mail for Windows 10
From: Șendre Mihai-Alin via so
Sent: Sunday, March 31, 2019 11:42 PM
To: Adrian Șendroiu
Cc: Sisteme de
Eu nu îți pot vedea codul, dar dacă buffer este alocat dinamic vezi să nu fi
mutat pointerul! Într-o alocare statică, buffer + 4095 va funcționa pentru
accese de dimensiune 1 octet. Eu am avut erori pentru că nu dădeam parametru
corect lui read() (uitam să scad nr de octeți deja citiți, o idee o
Deci ideea e să rămână un capăt de scriere deschis (chit că în procesul copil
în cazul modului „r” | I hate auto-quoting in my mail client). EOF va fi
raportat la capătul de citire doar când acel capăt a fost închis și bufferele
interne ale sistemului de operare au fost epuizate. Procesul părint
Vezi că taburile au 8 spații, nu 4! Ai ținut cont de asta?
Sent from Mail for Windows 10
From: Alexandru Fazakas via so
Sent: Tuesday, April 2, 2019 7:29 PM
To: Sisteme de Operare
Subject: [so] [Team2][Linux][Coding style] False positive checkpatch.pl
Salut,
Cred ca checker-ul de coding style i
That looks like an off-by-one error to me. În so_fread, apelezi memmove și nu
ai grijă când muți spre dreapta [nu îmi dau seama de ce ai face asta dar mă
rog], dar depășești bufferul.
(0 bytes after a block of __ allocated).
Memoria e alocată în main. Adică tu scrii mai multe date decât îți spu
2. Suspectez că în fseek/fflush nu golești bufferul (funcțiile ăstea spun că
următoarea operație din buffer poate să fie alta decât ultima). Trebuie să faci
și ceva bounds checking lol.
Resetează și tu toți indicii pe care îi ai (după un write, fseek ar fi bine să
genereze automat fflush).
Sent
Colega mea mi-a spus că au dispărut dintr-odată toate temele și a trebuit să
facă reupload. Momentan primesc și eu BS-ul cu timeout 1ms.
Sent from Mail for Windows 10
From: Lepadatu Tiberiu Andrei via so
Sent: Wednesday, April 3, 2019 11:24 PM
To: so@cursuri.cs.pub.ro
Subject: [so] [Vmchecke
În Windows, BOOL nu e chiar un boolean. În Windows FALSE este 0, TRUE este 1 și
BOOL este de fapt int și poate avea valori diferite (dar orice valoare nenulă
trebuie tratată ca true). Yeah, IKR, not exactly intuitive. Winapi is weird.
Sent from Mail for Windows 10
From: Lepadatu Tiberiu Andrei
Pentru handlerul default pe Windows trebuie să returnezi ceva cu
CONTINUE_SEARCHING din handlerul apelat de sistem. Honestly chestia asta e mai
ușoară pe Windows decât pe Linux.
Sent from Mail for Windows 10
From: Ionuț Mihalache via so
Sent: Tuesday, April 16, 2019 12:01 AM
To: Sisteme de Oper
Nu văd unde specifică în acea pagină de manual că dimensiunea poate fi mai mică
decât o pagină. Ba chiar, este imposibil ca mmap (sau echivalentul de pe orice
sistem de operare cu memorie virtuală) să mapeze jumătăți de pagină – nu există
suport hardware pentru așa ceva. mmap va mapa întotdeauna
Pentru a rezolva faulturi verific dacă a fost deja mapată pagina de memorie.
Dacă nu, o mapez. Dacă da, consider eșec la mapare și declanșez handlerul
salvat la so_init_loader. Perfect, asta îmi dă aproape toate testele chiar, dar
pe testul 7 (inputs/inv_perm) mi se spune că am 2 faulturi în loc
_perm?
On Tue, 16 Apr 2019 at 17:07, Paul-Stelian Olaru via so
wrote:
>
> Pentru a rezolva faulturi verific dacă a fost deja mapată pagina de memorie.
> Dacă nu, o mapez. Dacă da, consider eșec la mapare și declanșez handlerul
> salvat la so_init_loader. Perfect, asta îmi dă aproape
M
To: Paul-Stelian Olaru; Sisteme de Operare
Subject: Re: [so] Incorrect number of faults (test 7, inputs/inv_perm)
Ce zice strace ./_test/run_test ./_test/inputs/inv_perm?
On Tue, 16 Apr 2019 at 17:07, Paul-Stelian Olaru via so
wrote:
>
> Pentru a rezolva faulturi verific dacă a fost deja
Acesta este al 3-lea mail pe care l-am primit. Am primit 2 confirmări că deja
ți s-a dat revert.
Sent from Mail for Windows 10
From: Popa Bogdan via so
Sent: Saturday, April 20, 2019 12:08 PM
To: so@cursuri.cs.pub.ro
Subject: [so] [Tema3] Submisie Tema 3 peste Tema 2 Linux
Salut. Am încărcat as
27 matches
Mail list logo
