Но это значит, что программа ожидает поэлементного добавления элементов массива в стек, что-то вроде

Не совсем. В строках

const size_t size = 5;
const int data_in[size] = {1};
stack_push(stack, &data_in, sizeof(data_in));

В стеке в итоге оказывается не 5 элементов {1, 0, 0, 0, 0}, а один элемент размера 5 * sizeof(int). Требований работы с массивами в ТЗ нет, потому что библиотека не знает ничего о принимаемыз данных. Для нее данные -- это просто указатель на участок и его размер. Там может быть один int, структура, неинициализированный участок или массив.

И еще уточню на всякий случай: рассматриваемый нами тест написан для проверки ситуации, в которой пользователь передал неверные аргументы в функцию stack_pop. В данном случае, он положил в стек элемент размером 5* sizeof(int), а затем просит вытащить его и положить в буфер недостаточного размера 5* sizeof(int).

Поэтому в этой строке

EXPECT_EQ(stack_pop(stack, data_out, sizeof(data_out)), 0u);

ожидается, что stack_pop вернет 0 (как бы говоря, я положила 0 байт в твой буфер, так как места в нем недостаточно); а в строке

EXPECT_THAT(data_out, ::testing::Each(0));

мы просто проверяем, что библиотека нас не обманула, и действительно ничего не записала в data_out. Там до этого были нули, они там и остались.

Ваш запрос обратил мое внимание на другую проблему в тестах. Я на самом деле хотел, чтобы весь массив data_in был инициализирован -1, а по невнимательности написал по аналогии с = {0};. Это поправлю сейчас.

Спасибо!
Забыл, что в случае такого объявления массива

const int data_in[size] = {1};
stack_push(stack, &data_in, sizeof(data_in));

в нем будет лежать не [1,0,0,0,0], а в [1,1,1,1,1], потому не совсем корректно понял сам тест.

Спасибо! Забыл, что в случае такого объявления массива

const int data_in[size] = {1};
stack_push(stack, &data_in, sizeof(data_in));

в нем будет лежать не [1,0,0,0,0], а в [1,1,1,1,1], потому не совсем корректно понял сам тест.

Тут вы как раз полностью правы были)

Я вам инвайт коллаборатора направил, если хотите добавлю в ревьюверы пулл-реквеста с исправлением теста

В данном случае, он положил в стек элемент размером 5* sizeof(int), а затем просит вытащить его и положить в буфер недостаточного размера 5* sizeof(int).

Ответственность за корректность "вытаскивания" элементов из стека лежит не на пользователе?

Я вам инвайт коллаборатора направил, если хотите добавлю в ревьюверы пулл-реквеста с исправлением теста

Да, буду за

В данном случае, он положил в стек элемент размером 5* sizeof(int), а затем просит вытащить его и положить в буфер недостаточного размера 5* sizeof(int).

Ответственность за корректность "вытаскивания" элементов из стека лежит не на пользователе?

На пользователе. Он должен представить буфер, с размером не меньшим, чем размер верхнего элемента в стеке. Это следствие того, что данные в буфере не типизированы.

Разве это тогда не проблема пользователя, что он предоставил размер массива меньший (из 4 * size(int)), чем размер элемента стека (5 * size(int))?

Разве это тогда не проблема пользователя, что он предоставил размер массива меньший (из 4 * size(int)), чем размер элемента стека (5 * size(int))?

Ну да, это его проблема) Но это не значит, что надо намеренно выходить за границы массива или нарушать гранулярность данных , обрезав их до нужного размера. Библиотека спокойно сообщает о том, что пользователь передал указатель на участок памяти недостаточного размера. Это стандартная практика в С.

С другой стороны, если пользователь создал буфер размера 4 байта, а сам передал в stack_pop аргумент size == 8, то от такой ситуации никак не спасешься. Библиотека не гарантирует, что программа продолжить работать корректно после такого вызова.

Может есть смысл в ТЗ отдельно добавить требование проверки совпадения размеров полей, которые подает пользователь с размером элемента в стеке? Что-то вроде "стек должен обеспечивать корректный вывод данных" или "библиотека должна гарантировать соответствие размера выводимых из стека данных и поля пользователя". То, что данные не типизированные ещё не означает, что библиотека должна заботиться о пользователе, ограничивая пользователя, если он хочет вытащить данные в поле некорректного размера.

Может есть смысл в ТЗ отдельно добавить требование проверки совпадения размеров полей, которые подает пользователь с размером элемента в стеке? Что-то вроде "стек должен обеспечивать корректный вывод данных" или "библиотека должна гарантировать соответствие размера выводимых из стека данных и поля пользователя".

Требования совпадения размеров буферов нет, есть требование достаточности размера буфера, предоставляемого пользователем. Если пользователь захочет, может предоставить буфер большего размера, чем размер данных в верхушке стека.

Перечитал ТЗ, возможно этот момент и стоит отдельно обозначить. Что то вроде

• unsigned int stack_pop(const hstack_t stack, void* data_out, const unsigned int size)
  Brief: Извлечь элемент из стека и записать данные этого элемента в буфер, если соответствующий хэндлеру стек существует и пользователь предоставил буфер достаточного размера.
  Parameters: stack - хэндлер стека; data_out - указатель на буфер для записи данных; size - размер буфера.
  Returns: размер записанных данных в байтах, если соответствующий хэндлеру стек существует и пользователь предоставил буфер достаточного размера, или 0 в противном случае.

То, что данные не типизированные ещё не означает, что библиотека должна заботиться о пользователе, ограничивая пользователя, если он хочет вытащить данные в поле некорректного размера.

Считаю сохранение целостности данных в стеке приоритетным по отношению к возможному странному желанию пользователя получить первые несколько байт данных с утерей остальных. Что делать, если пользователь просто ошибся или не знал заранее, какой размер данных на вершине стека? К тому моменту, как он поймет ошибку, данные будут уже утеряны.

Сравните два варианта:

// push some text
const char* message = "This is important text, do not lose it!";
hstack_t handler = stack_new();
if (handler != -1) {
    stack_push(handler, message, strlen(message));
}

// 1. stack_pop pops data to buffer of insufficient size and silently erases data
char buffer[20] = {0};
unsigned int out = stack_pop(handler, buffer, sizeof(buffer));
// out = 20, *buffer = "This is important te", "xt, do not lose it!" is lost forever

// or...

// 2. stack_pop refuses to pop data to buffer of insufficient size
char* buffer = (char*)calloc(20, 1);
unsigned int out = stack_pop(handler, buffer, 20);
if (out == 0u) {
    buffer = (char*)realloc(buffer, 40);
    out = stack_pop(handler, buffer, 40);
    // out = 39, buffer = "This is important text, do not lose it!"
}

Требования совпадения размеров буферов нет, есть требование достаточности размера буфера, предоставляемого пользователем.

Благодарю за уточнение. Подправлю этот момент в своём домашнем.

Перечитал ТЗ, возможно этот момент и стоит отдельно обозначить.

Выглядит здорово!

Что делать, если пользователь просто ошибся или не знал заранее, какой размер данных на вершине стека? К тому моменту, как он поймет ошибку, данные будут уже утеряны.

Согласен, но изначально по ТЗ не совсем понятно, должна ли библиотека отслеживать такое странное желание пользователя. Поскольку это требует отдельной проверки, а ТЗ не предъявляло такого требования, то могла случиться "оптимизация на проверку": зачем проверять то, что не требуют проверять. Приведенное уточнение ТЗ должно сделать картину яснее