Telegram Group & Telegram Channel
⚙️ Задача для C++ разработчиков: «Непонятная ошибка, которая портит данные»


🎯 Цель: Найти и объяснить причину скрытого неопределённого поведения, которое проявляется не сразу

📍 Ситуация:

Ты разрабатываешь кроссплатформенное приложение на C++17, которое обрабатывает массивы бинарных данных.
На тестах — всё работает. Но у части пользователей (особенно на Linux) возникают:

- Повреждённые файлы после сериализации
- Непредсказуемые вылеты при больших объёмах данных
- Валидация данных случайно "съезжает" (байты путаются)

Вот фрагмент кода:


#include <vector>
#include <cstring>

struct Packet {
uint32_t id;
char data[64];
};

std::vector<uint8_t> serialize(const Packet& p) {
std::vector<uint8_t> buffer(sizeof(Packet));
std::memcpy(buffer.data(), &p, sizeof(Packet));
return buffer;
}


🔍 Визуально всё нормально. В unit-тестах — ок. На CI — ок.
Но на проде данные иногда повреждены, и никто не может воспроизвести баг стабильно.

🧩 Задача:

1. Почему memcpy здесь небезопасен, хотя кажется логичным?
2. Что может отличаться на разных платформах и влиять на поведение?
3. Как бы ты безопасно сериализовал структуру в std::vector<uint8_t>?
4. Как это можно поймать с помощью valgrind / asan / -fsanitize=undefined?
5. Как написать cross-platform-safe сериализацию?

💡 Подсказка:
В C++ `struct Packet` может иметь **padding** и **alignment**, которые отличаются на архитектурах. `memcpy` по `sizeof(Packet)` может захватить лишние или мусорные байты.

🛠 Решение:

1. `struct Packet` не является POD-структурой с гарантированным layout — в ней может быть **неинициализированный padding**, который `memcpy` тоже копирует.

2. Проблема усиливается на системах с разным выравниванием: x86 vs ARM, GCC vs MSVC.

3. Более безопасный способ — сериализовать поля по отдельности:

std::vector<uint8_t> serialize(const Packet& p) {
std::vector<uint8_t> buffer;
buffer.insert(buffer.end(), reinterpret_cast<const uint8_t*>(&
p.id),
reinterpret_cast<const uint8_t*>(&
p.id) + sizeof(p.id));
buffer.insert(buffer.end(),
p.data, p.data + sizeof(p.data));
return buffer;
}



4. Или использовать `std::ostringstream` / `std::span` / `protobuf` / `flatbuffers`.

5. Проверка с `-fsanitize=undefined` даст warning:
```
memcpy: reading padding bytes from stack frame
```

📌 **Вывод:**
В C++ `memcpy` на структуру — это **ловушка**, если ты не контролируешь padding. Никогда не сериализуй структуры напрямую через память, если это не `#pragma pack` и не строго определённый layout.

💬 Это вопрос для собеседования на позицию C++ системного разработчика с уклоном в безопасность и низкоуровневую разработку.

@cpluspluc



tg-me.com/cpluspluc/1101
Create:
Last Update:

⚙️ Задача для C++ разработчиков: «Непонятная ошибка, которая портит данные»


🎯 Цель: Найти и объяснить причину скрытого неопределённого поведения, которое проявляется не сразу

📍 Ситуация:

Ты разрабатываешь кроссплатформенное приложение на C++17, которое обрабатывает массивы бинарных данных.
На тестах — всё работает. Но у части пользователей (особенно на Linux) возникают:

- Повреждённые файлы после сериализации
- Непредсказуемые вылеты при больших объёмах данных
- Валидация данных случайно "съезжает" (байты путаются)

Вот фрагмент кода:


#include <vector>
#include <cstring>

struct Packet {
uint32_t id;
char data[64];
};

std::vector<uint8_t> serialize(const Packet& p) {
std::vector<uint8_t> buffer(sizeof(Packet));
std::memcpy(buffer.data(), &p, sizeof(Packet));
return buffer;
}


🔍 Визуально всё нормально. В unit-тестах — ок. На CI — ок.
Но на проде данные иногда повреждены, и никто не может воспроизвести баг стабильно.

🧩 Задача:

1. Почему memcpy здесь небезопасен, хотя кажется логичным?
2. Что может отличаться на разных платформах и влиять на поведение?
3. Как бы ты безопасно сериализовал структуру в std::vector<uint8_t>?
4. Как это можно поймать с помощью valgrind / asan / -fsanitize=undefined?
5. Как написать cross-platform-safe сериализацию?

💡 Подсказка:
В C++ `struct Packet` может иметь **padding** и **alignment**, которые отличаются на архитектурах. `memcpy` по `sizeof(Packet)` может захватить лишние или мусорные байты.

🛠 Решение:

1. `struct Packet` не является POD-структурой с гарантированным layout — в ней может быть **неинициализированный padding**, который `memcpy` тоже копирует.

2. Проблема усиливается на системах с разным выравниванием: x86 vs ARM, GCC vs MSVC.

3. Более безопасный способ — сериализовать поля по отдельности:

std::vector<uint8_t> serialize(const Packet& p) {
std::vector<uint8_t> buffer;
buffer.insert(buffer.end(), reinterpret_cast<const uint8_t*>(&
p.id),
reinterpret_cast<const uint8_t*>(&
p.id) + sizeof(p.id));
buffer.insert(buffer.end(),
p.data, p.data + sizeof(p.data));
return buffer;
}



4. Или использовать `std::ostringstream` / `std::span` / `protobuf` / `flatbuffers`.

5. Проверка с `-fsanitize=undefined` даст warning:
```
memcpy: reading padding bytes from stack frame
```

📌 **Вывод:**
В C++ `memcpy` на структуру — это **ловушка**, если ты не контролируешь padding. Никогда не сериализуй структуры напрямую через память, если это не `#pragma pack` и не строго определённый layout.

💬 Это вопрос для собеседования на позицию C++ системного разработчика с уклоном в безопасность и низкоуровневую разработку.

@cpluspluc

BY C++ Academy


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/cpluspluc/1101

View MORE
Open in Telegram


telegram Telegram | DID YOU KNOW?

Date: |

How Does Telegram Make Money?

Telegram is a free app and runs on donations. According to a blog on the telegram: We believe in fast and secure messaging that is also 100% free. Pavel Durov, who shares our vision, supplied Telegram with a generous donation, so we have quite enough money for the time being. If Telegram runs out, we will introduce non-essential paid options to support the infrastructure and finance developer salaries. But making profits will never be an end-goal for Telegram.

Pinterest (PINS) Stock Sinks As Market Gains

Pinterest (PINS) closed at $71.75 in the latest trading session, marking a -0.18% move from the prior day. This change lagged the S&P 500's daily gain of 0.1%. Meanwhile, the Dow gained 0.9%, and the Nasdaq, a tech-heavy index, lost 0.59%. Heading into today, shares of the digital pinboard and shopping tool company had lost 17.41% over the past month, lagging the Computer and Technology sector's loss of 5.38% and the S&P 500's gain of 0.71% in that time. Investors will be hoping for strength from PINS as it approaches its next earnings release. The company is expected to report EPS of $0.07, up 170% from the prior-year quarter. Our most recent consensus estimate is calling for quarterly revenue of $467.87 million, up 72.05% from the year-ago period.

telegram from tw


Telegram C++ Academy
FROM USA