Ну что-то похожее)

Ну что-то похожее)

Скорее всего вам это не нужно (если вы не пишете код для АЭС)

ну можешь попробовать погонять статическим анализом. оно кое-как попытается проанализировать все пути выполнения.

Так, что подразумевает стат анализ в этом случае?

Так, что подразумевает стат анализ в этом случае?

запуск статического анализатора на твоей функции resize

Проверка кода на типичные ошибки миллионом и еще одной эвристикой

Например на вызов p = realloc(p, ...)

и вера в то, что он проанализирует все возможные пути выполнения функции и посмотрит, течёт ли память по какому-нибудь пути

вообще за статическими гарантиями обычно идут в отличные от С++ языки

вообще за статическими гарантиями обычно идут в отличные от С++ языки

надеюсь когда-нибудь увидим новое небо)

вообще за статическими гарантиями обычно идут в отличные от С++ языки

ну что ж делать, если нам хочется в С++ это видеть

страдать, как обычно

Внезапно нагуглил http://telegrammy.net/group/ProCxx/page1.htm

Ребят, привет!

Нужна помощь. Читаю файл кусками с помощью ifstream в unsigned char[64]

затем кодирую с помощью rsa и декодирую

и пишу в другой файл с помощью ofstream. В итоге валидными на выходе получаются только текстовые файлы

Перед записью в файл проверяю строки c strcmp, они равны, но если после записи открыть оба файла и сравить они получаются разные

*открыть как hex

а ты ofstream в бинарном режиме создаешь?

std::ofstream ofs ("test.txt", std::ofstream::out | std::ofstream::binary);

да

https://pastebin.com/mZaTyeTi

Перед записью в файл проверка: if (strcmp(buffer, encrypted)), которая никогда не выполняется. т.е. строки всегда равны!

а как ты определяешь валидность?

Просто открытием. Текстовые файлы открывает, картинки и архивы -нет

может дело в том что ты добиваешь файлы нулями до кратности 64 байтам?

или скорее даже не нулями, а мусором

Я хз, на выходе то одинакового размера они получаются.

а, не

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

а в хекс-редакторе как разница выглядит?

сек

https://pp.userapi.com/c844417/v844417438/119fc1/Hx2Dkt0Lnwo.jpg

Вот. Ну там с ходу даже видно разницу. При том у текстового файла нет отличий, даже в hex-редакторе

А почему проверка strcmp, а не memcmp?

https://pp.userapi.com/c844417/v844417438/119fc1/Hx2Dkt0Lnwo.jpg

ага, вроде понятно в чем дело

попробовал memcmp, результат тот же

rsa->encrypt(buffer, len) кодирует либо до len либо до нуля

раскодирует тоже, соответственно, а дальше в encrypted будет лежать мусор

а strcmp тоже сравнивает до первого нуля, поэтому сравнение отрабатывает нормально

сейчас посмотрю

len передается по ссылке и возвращает всегда 256, а у rsa->decrypt(...) len возвращает кол-во раскодированных байт. Печатаю в консоль каждый прочитанный блок и они равны

https://pp.userapi.com/c844417/v844417438/119ffa/7CMGfBXSNA8.jpg

Так, а если подойти с другой стороны? Я читаю файл кусками, потому что при ключе rsa размером 2048 максимальный размер кодируемой памяти - 256 байт

мб я ошибаюсь и в openssl есть методы кодирующие и декодирующие большие участки целиком?

len передается по ссылке и возвращает всегда 256, а у rsa->decrypt(...) len возвращает кол-во раскодированных байт. Печатаю в консоль каждый прочитанный блок и они равны

Len перед вызовом encrypt присвоить нужно

Не нулю

Или посмотреть другие методы rsa

Иначе как функция encrypt узнает, сколько байт из буфера нужно закодировать?

http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=RSA_public_encrypt

RSA_public_encrypt() returns the size of the encrypted data (i.e., RSA_size(rsa)). RSA_private_decrypt() returns the size of the recovered plaintext. On error, -1 is returned; the error codes can be obtained by ERR_get_error(3).

В моём случае rsa->encrypt(...) - это обертка над сишным апи

Вот если интересно код encrypt https://pastebin.com/e9hGjU92

RSA_size(rsa)) - при ключе в 2048 всегда возвращает 256

message - это ведь не строка, а массив байт?

да, верно

Почему strlen(message) ?

а как?

Действительно, может тут я поспешил. Но как иначе измерить?

Действительно, может тут я поспешил. Но как иначе измерить?

ЧТо надо измерить? Я сходу не вижу выше...

Кода читаешь из файла ты же получаешь сколько ты байт прочитал — вот это значение и передавай

я понял. Как раз это писал)

Сейчас попробую

И в функции нет free для cencrypt.

Не помогло.

Добавил ещё одну проверку - на размер буффера и закодированого и раскодированного текста из буфера. размер буффера и раскодированного текста всегда совпадают

https://pp.userapi.com/c845217/v845217221/116e78/C7dap_D9NUQ.jpg

если bufferSize = 1, то всё норм кодируется и декодируется. Но считывать и писать в файл по байту мне кажется не очень мысль. Да и долго очень.

И в функции нет free для cencrypt.

Немного невнимательно исправил что ты сказал. Спасибо, ошибка там и была.

А кто-нибудь разбирался с "Core Coroutines" http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1063r1.pdf ?

Шалом, коллеги. Вопросы про windows api принимаются?

Шалом, коллеги. Вопросы про windows api принимаются?

Да

Супер. Как проще всего синхронно отправить сообщение другому процессу (WM_COPYDATA) и дождаться от него ответа (тоже WM_COPYDATA) ? нужно сделать что-то типа WaitForWMCopyData

Супер. Как проще всего синхронно отправить сообщение другому процессу (WM_COPYDATA) и дождаться от него ответа (тоже WM_COPYDATA) ? нужно сделать что-то типа WaitForWMCopyData

Это невозможно

Супер. Как проще всего синхронно отправить сообщение другому процессу (WM_COPYDATA) и дождаться от него ответа (тоже WM_COPYDATA) ? нужно сделать что-то типа WaitForWMCopyData

А дожидаться WinAPI будет, если ты 0) будешь использовать SendMessageXXXX, а не PostMessage 1) Не задаш таймаут

Супер. Как проще всего синхронно отправить сообщение другому процессу (WM_COPYDATA) и дождаться от него ответа (тоже WM_COPYDATA) ? нужно сделать что-то типа WaitForWMCopyData

Назад данные можно и через именованый пайп принять. А в первом сообщении отправить его имя.

Что-то другому процессу в любом случае придется передать. Например, хендл окна, куда отправлять ответное сообщение.

А дожидаться WinAPI будет, если ты 0) будешь использовать SendMessageXXXX, а не PostMessage 1) Не задаш таймаут

эт понятно, я именно SendMessage использую. Попробую ещё раз более внятно расказать что хочу. Окно A (сервер) получает WM_COPYDATA от окна Б (от клиента), отправленный с помощью SendMessage(WM_COPYDATA... , хэндлит запрос и отправляет ответ окну Б в виде SendMessage(WM_COPYDATA... Я пока что пытаюсь понять вот что. Окно Б от момента отправки сообщения до момента его обработки в в окне А будет заблокировано и не будет принимать сообщения, или всё таки нет

эт понятно, я именно SendMessage использую. Попробую ещё раз более внятно расказать что хочу. Окно A (сервер) получает WM_COPYDATA от окна Б (от клиента), отправленный с помощью SendMessage(WM_COPYDATA... , хэндлит запрос и отправляет ответ окну Б в виде SendMessage(WM_COPYDATA... Я пока что пытаюсь понять вот что. Окно Б от момента отправки сообщения до момента его обработки в в окне А будет заблокировано и не будет принимать сообщения, или всё таки нет

Ну, это плохо. Бдут дэдлоки...

эт понятно, я именно SendMessage использую. Попробую ещё раз более внятно расказать что хочу. Окно A (сервер) получает WM_COPYDATA от окна Б (от клиента), отправленный с помощью SendMessage(WM_COPYDATA... , хэндлит запрос и отправляет ответ окну Б в виде SendMessage(WM_COPYDATA... Я пока что пытаюсь понять вот что. Окно Б от момента отправки сообщения до момента его обработки в в окне А будет заблокировано и не будет принимать сообщения, или всё таки нет

Смотря откуда звать SendMessage. Если из основного потока окна, что вероятно, то да, будет заблокировано.

Назад данные можно и через именованый пайп принять. А в первом сообщении отправить его имя.

на мой взгляд проще тогда уже чисто на пайпах делать, без WM_COPYDATA

PostMessage не блокирует отправляющий поток, но не гарантирует доставку

эт понятно, я именно SendMessage использую. Попробую ещё раз более внятно расказать что хочу. Окно A (сервер) получает WM_COPYDATA от окна Б (от клиента), отправленный с помощью SendMessage(WM_COPYDATA... , хэндлит запрос и отправляет ответ окну Б в виде SendMessage(WM_COPYDATA... Я пока что пытаюсь понять вот что. Окно Б от момента отправки сообщения до момента его обработки в в окне А будет заблокировано и не будет принимать сообщения, или всё таки нет

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

эт понятно, я именно SendMessage использую. Попробую ещё раз более внятно расказать что хочу. Окно A (сервер) получает WM_COPYDATA от окна Б (от клиента), отправленный с помощью SendMessage(WM_COPYDATA... , хэндлит запрос и отправляет ответ окну Б в виде SendMessage(WM_COPYDATA... Я пока что пытаюсь понять вот что. Окно Б от момента отправки сообщения до момента его обработки в в окне А будет заблокировано и не будет принимать сообщения, или всё таки нет

Окно Б от момента отправки сообщения до момента его обработки в в окне А будет заблокировано и не будет принимать сообщения, или всё таки нет Да, будет заблокировано.

на мой взгляд проще тогда уже чисто на пайпах делать, без WM_COPYDATA

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

на мой взгляд проще тогда уже чисто на пайпах делать, без WM_COPYDATA

Это твоё дело...

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

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

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

Не сказал бы, что сильно сложнее. Вот пример проксирования из пайпа в пайп https://github.com/slavanap/ssifSource/blob/master/AvsTools/Tools.Pipe.cpp

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

Так он и есть синхронный.

Так он и есть синхронный.

в смысле, запрос - ответ

С copydata можно отправлять сообщение через sendmessage из другого потока, например. Чтобы окно не зависало, но была возможность обрабатывать ошибки отправки. Или отправлять через postmessage, а в нём указывать уникальный номер сообщения, чтобы потом понять, на какое сообщение ответ пришел. Этот уникальный номер сервер в ответном сообщении должен дублировать.

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

Мне кажется, у тебя немножко каша в голове по поводу "синхронный/асинхронный". Если ты что-то вызываешь, и чтобы получить результат, тебе не надо ждать специально, а вызов СРАЗУ даст тебе результат, это -- синхронный вызов. Так работает SendMessageXXX. Если ты что-то вызываешь, а потом другим вызовом тебе придёт результат -- это Асинхронный вызов. Так организован PostMessage.