Как защитить память моей общей библиотеки?
Я предоставляю клиенту общую библиотеку C++, но у этого клиента есть инженер, который не пишет код должным образом, и он очень часто возвращается ко мне и говорит, что у него проблема с библиотекой, хотя на самом деле его приложение делает странные вещи (но с эффектом). в коде моей библиотеки).
Как я могу запретить пользователю изменять память моей библиотеки?
История: Однажды он сделал что-то странное с указателем, и некоторая часть кода (sleep_for()) не была выполнена, и это привело к потере большого количества времени на отладку моего кода. (конечно, он не предоставляет свой код)
Как вы справляетесь с этой ситуацией? Я вежливо говорю, что у меня нет времени, но в то же время не хочу из-за своей либеральности отвергать действительно позитивный вопрос.
Вам не хватает знаний, чтобы понять мой вопрос, я подожду кого-нибудь другого.
Если вы защитите от записи память, используемую вашей библиотекой, ваша библиотека также не сможет писать в нее. Невозможно контролировать доступ к памяти в зависимости от того, используется ли она библиотекой или приложением, если только библиотека не работает в другом процессе и не использует передачу сообщений для связи с приложением.
Если ваша библиотека не может справиться с тем, что пользователи делают «что-то странное», то это ваша проблема, а не пользователя. Это справедливо для любого программного обеспечения.
@Бармар, я этого боялся, я не хочу добавлять такую сложность (хотя это может быть легко).
@OldBoy Я уже говорил тебе, что тебе не хватает базовых знаний о том, как выделяется и защищается память. Пожалуйста, прочитайте несколько книг о процессах.
@OldBoy На самом деле библиотека ничего не может сделать, чтобы обнаружить, когда какая-то другая часть программы попирает вашу память. Они вызывают неопределенное поведение, и в любой части программы может произойти что угодно. Вы действительно не знаете, о чем говорите.
Это действительно организационная проблема, а не техническая. Когда вам говорят, что в вашей библиотеке есть ошибки, вы просите образец кода, чтобы воспроизвести проблему.
@Barmar Спасибо за добрые слова.
Согласен, это организационный вопрос. Есть причина, по которой большинство проектов с открытым исходным кодом будут рассматривать зарегистрированные проблемы только в том случае, если есть либо а) простой способ воспроизвести их, либо б) затронуто несколько пользователей. Вероятно, вам нужно поговорить со своим клиентом о том, как улучшить способ сообщения вам об этих проблемах.
Спасибо за ваш опыт! Я сделаю это тогда.
Обратите внимание: даже если бы вы смогли это сделать, это могло бы не решить вашу проблему с технической поддержкой. Когда их приложение попытается изменить вашу память, оно выйдет из строя с нарушением сегментации. Если они не умеют отлаживать свой код, они все равно сообщат вам об этом как о сбое, который происходит только при использовании вашей библиотеки.
Проще отказаться от поддержки segfault (обратная трассировка покажет и все). Труднее сказать, когда проблема, кажется, исходит из моей библиотеки.
Ответы 2
Если вы хотите вернуть память только для чтения своему клиентскому коду и не уверены, что она не выбросит const, то вы можете mmap() эту память и использовать mprotect() пометить ее как доступную только для чтения после того, как вы ее написали, прежде чем вернуться. это звонящему.
Но я действительно советую вам просто использовать const и информировать своих пользователей о том, что const_cast() вредно.
Если дело просто в том, что ваша библиотека вызывается с аргументами, которые вы не обрабатываете, добавьте эти случаи в свои модульные тесты и убедитесь, что вы делаете что-то разумное, например, генерируете исключение.
Я проверяю все параметры, переданные в библиотеку. В конце концов, проблемы, которые у меня возникли с этим пользователем, даже не связаны с библиотекой, а с тем, как они пишут код своего собственного приложения, которое в конечном итоге повреждает внутренние данные моей библиотеки.
Одна из проблем заключается в том, что мой код выполняется правильно, но что-то сломало std::this_thread::sleep_for, который я использую внутри (подтверждено отпечатками внутри моей библиотеки). Трудно отладить эту ситуацию... Спасибо!
Вы не можете сделать это в общей библиотеке. Надежный способ сделать это — поместить ваш код в отдельный процесс и иметь четко определенный протокол между вашим приложением и его приложением. Если сообщения верны, ваш процесс не должен аварийно завершиться. А если нет, вы отклоняете входящее сообщение.
Спасибо! Вы имеете в виду МПК? Я бы запустил свою библиотеку в приложении-демоне, и они бы связывались с ней вместо того, чтобы связывать библиотеку? IPC увеличил бы задержку, но если это так, я бы сделал это, по крайней мере, для первой интеграции, и предоставил бы оболочку для ее эмуляции. Как только я узнаю, что она стабильна, они смогут связать мою библиотеку в своем приложении.
@None: IPC действительно правильное сокращение. Вам нужно будет принять решение по экономическому обоснованию; мы здесь просто указываем на то, что вы можете технически сделать, чтобы защитить свою библиотеку.
Если в вашей библиотеке что-то пойдет не так, вы обязаны это исправить. Неважно, что делает пользователь, ваш код должен быть достаточно надежным, чтобы защитить себя от неправильного использования.