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: |

The STAR Market, as is implied by the name, is heavily geared toward smaller innovative tech companies, in particular those engaged in strategically important fields, such as biopharmaceuticals, 5G technology, semiconductors, and new energy. The STAR Market currently has 340 listed securities. The STAR Market is seen as important for China’s high-tech and emerging industries, providing a space for smaller companies to raise capital in China. This is especially significant for technology companies that may be viewed with suspicion on overseas stock exchanges.

Should I buy bitcoin?

“To the extent it is used I fear it’s often for illicit finance. It’s an extremely inefficient way of conducting transactions, and the amount of energy that’s consumed in processing those transactions is staggering,” the former Fed chairwoman said. Yellen’s comments have been cited as a reason for bitcoin’s recent losses. However, Yellen’s assessment of bitcoin as a inefficient medium of exchange is an important point and one that has already been raised in the past by bitcoin bulls. Using a volatile asset in exchange for goods and services makes little sense if the asset can tumble 10% in a day, or surge 80% over the course of a two months as bitcoin has done in 2021, critics argue. To put a finer point on it, over the past 12 months bitcoin has registered 8 corrections, defined as a decline from a recent peak of at least 10% but not more than 20%, and two bear markets, which are defined as falls of 20% or more, according to Dow Jones Market Data.

telegram from id


Telegram C++ Academy
FROM USA