Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Привести в порядок возвращаемые из функций значения в C++ #11

Closed
nameofuser1 opened this issue Sep 9, 2020 · 3 comments

Comments

@nameofuser1
Copy link
Contributor

Когда-то вопрос уже поднимался, но благополучно забыли об этом.

  1. Метод serialize в случае успеха возвращает > 0, в случае фейла - 0. В то время, как parse и get message info возвращают -1 для ошибки и 0 для успеха. Сделать бы одинаково.
  2. Вроде как size_t и int не самый хороший способ возвращать значения. Я бы переделал на типы со строгим размером типа uint32_t, int32_t.
@DrTon
Copy link
Member

DrTon commented Sep 9, 2020

Вроде как size_t и int

а почему? вроде size_t как раз и задуман как тип размера массива. A int традиционно используется в POSIX для возврата ошибок, например функции open, ioctl возвращают именно int.

Используя int32_t ты намекаешь на 32битность архитектуры (мол это родной тип), а messgen у нас кроссплатформенный.

@nameofuser1
Copy link
Contributor Author

nameofuser1 commented Nov 24, 2020

Вроде как size_t и int

а почему? вроде size_t как раз и задуман как тип размера массива. A int традиционно используется в POSIX для возврата ошибок, например функции open, ioctl возвращают именно int.

Используя int32_t ты намекаешь на 32битность архитектуры (мол это родной тип), а messgen у нас кроссплатформенный.

А причем тут архитектура? Менее кроссплатформенным он не станет от того, что мы будем int32 возвращать. Просто строгая типизация имеет более предсказуемое поведение.

В свете #15 и https://github.com/microavia/messgen/tree/change-max-message-size-to-uint32, когда мы хотим возвращать отрицательные значения и иметь максимальный размер сообщений uint32, у нас варианты возврата есть только int или int64, тк ssize_t на винде вообще не определен. Почему между int и int64 я выберу int64 - uint32 кастисть к int опасно, тк uint32 может быть равен размеру int, тогда возможно переполнение. Понятно, что сообщения таких размеров маловероятны, но все же ничего не мешает строго описать тип.

Давай придем по этим вопросам к консенсусу и переделаем интерфейсы, тк #15 довольно неприятная штука (

@DrTon
Copy link
Member

DrTon commented Nov 25, 2020

Есть еще три варианта:

  1. int32, тогда максимальный размер сообщения сократится до 2Гб, чтото мне подсказывает, что этого над на ближайшее время хватит
  2. Разделить код возврата (OK/ERROR) и количество обработаных байт (например класть его в аргумент ссылку).
  3. Вообще не возвращать количество обработаных байт, т.к. по факту оно не особо и нужно, есть метод get_size() который мы все равно должны вызвать ПЕРЕД парсингом или сериализацией, чтобы убедится что буфер который мы даем нужного размера.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants