Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#241 closed ожидается проверка (задача сдана)

WW #3

Reported by: potryasaeva.anna Owned by: Артур Гулецкий (huletski)
Component: WW_intrusive_list Version: 2.0
Keywords: Cc:

Description


Change History (4)

comment:1 Changed 5 years ago by Артур Гулецкий (huletski)

Type: ожидается проверкаожидаются исправления

В решении присутствуют артефакты сбoрки (lab_03 и obj), их необходимо удалить:

{lab_03}[2120]$ pwd && svn up && svn status
/home/hfx/dvl/cpp19/potryasaeva.anna/lab_03
Updating '.':
At revision 926.
{lab_03}[2121]$ ls
include  lab_03  Makefile  obj  src

Кроме того, решение падает на последовательности команд, приведенной в качестве примера в задании:

{lab_03}[2128]$ cat ../../../private-labs/lab_03/check/tests/00-smoke.input 
add 1 2
add 3 6
add 4 6
len
add 1 2
print
sort
rm 1 2
print
rma
print
len
add 2 -4
print
exit
{lab_03}[2129]$ ./lab_03 < ../../../private-labs/lab_03/check/tests/00-smoke.input 
3
(1 2) (4 6) (3 6) (1 2) 
Unknown command
(4 6) (3 6) 

0
(2 -4) 

=================================================================
==17309==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7ff97e778ff8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10bff8)
    #1 0x4010e4 in add_point src/main.c:13
    #2 0x4015da in main src/main.c:64
    #3 0x7ff97e2c382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).

comment:2 Changed 5 years ago by potryasaeva.anna

Type: ожидаются исправленияожидается проверка
Version: 1.02.0

comment:3 Changed 5 years ago by Артур Гулецкий (huletski)

Resolution: задача сдана
Status: assignedclosed

Все работает, +12.

В целом хорошо, замечания следующие:

  • разный стиль отступов в main.c и в clist.c;
  • при чтении строки в буфер, используя scanf, нужно ограничивать максимальное число считываемых символов размерами буфера (заменив %s на %9s (размер буфера - 1) в первом аргументе), чтобы избежать переполнения буфера при некорректном вводе и, как следствие, UB;
  • предполагалось, что размер списка будет вычисляться каждый раз при вызове get_length, а не храниться в поле size;
  • l->size++; выглядит более "естрественно", чем ++l->size;, компилятор скорее всего сгенерирует одинаковый код для обоих statement'ов.

comment:4 Changed 5 years ago by Артур Гулецкий (huletski)

UPD: замечание по "архитектуре"

main.c:51, l->size = 0;. Лучше так не делать, так как поле size является (по смыслу) скорее "внутренним" полем списка -> инварианты, связанные с ним (e.g. l->size == 0 <-> l->head == NULL), поддерживаются функциями, реализующими базовую работу со структурой данных (в clist.c). Пользователь структуры данных (код main.c), модифицируя внутреннее состояние извне, в общем случае может нарушать поддерживающиеся инварианты.

Note: See TracTickets for help on using tickets.