На просторах интернета нашел очень понравившуюся мне книгу посвященную работе с GNU Make – Managing Projects with GNU Make, 3.Xth Edition, которая еще и распространяется под GNU Free Documentation License. В книге подробно рассматривают работу с GNU Make начиная с азов и простейшего Makefile заканчивая вопросами производительности, отладкой Makefile и различными трюками.
Однозначно стоит прочесть!
Post Category → Software Engineering
Инициализация статического объекта в GCC
С удивлением узнал о том, что GCC гарантирует атомарность создания статического объекта. Поэтому следующий код будет корректен в многопоточном окружении:
template <typename T>
T& singleton()
{
static T obj;
return obj;
}
T& singleton()
{
static T obj;
return obj;
}
Если по каким-то причинам такое поведение кажется возмутительным, можно воспользоваться флагом -fno-threadsafe-statics
Кстати, кто знает как обстоят дела с инициализацией статических объектов у других компиляторов?
Легенда о константной ссылке.
Уже несколько раз в кругах C++ разработчиков слышал Легенду о константной ссылке. Легенда варьируется от “из функции можно вернуть константную ссылку на временный объект” до “можно сохранить константную ссылку на временный объект”. Как раз на прошлой неделе мы обсудили этот вопрос с коллегами, и мне захотелось в нем детально разобраться.
В стандарте данная ситуация освещена очень вскользь, так что пришлось покопаться. Во-первых, в пункте 12.2.5 сказано следующее:
Continue reading
Получаем стек вызовов в Mac OS X
Я давно хотел добавить поддержку получения стека вызовов к своему Tasks Explorer, но никакой публичной информации на этот счет мне не попадалось, а ковырять систему было некогда да и лень (зима, чтоб ее). С первыми лучиками весеннего солнца задача с получением стека вызов стала казаться не такой уж и скучной и дело сдвинулось.
Начал я с того, что нашел утилиту stackshot разработки Apple, только вот исходники приложения закрыты. Как вариант, stackshot можно было использовать напрямую, но в целом такая идея мне не понравилась, да и никаких новых и полезных знаний это не даст. Тем не менее, stackshot вполне сгодился в качестве отправной точки.
Continue reading
cURL & Proxy & HTTPS & Authorization == CURLE_RECV_ERROR
Да, баги в тулзах преследуют меня всю неделю. На сей раз отличился cURL с древним багом связанным с запросом отправляемым по HTTPS через прокси. Похоже что ситуация не слишком распространенная, т.к. надо не только работать через прокси, но еще на прокси должна быть включена авторизация и при отправке запроса пароль должен быть не указан. В принципе, в такой ситуации ожидаешь код 407, просишь пользователя ввести пароль и наступает счастье. Но вот cURL думает иначе. Вместо того чтоб вернуть 407 и страничку с ошибкой от прокси, которые судя по его логу присутствуют, зачем-то возвращается CURLE_RECV_ERROR.
Ignore 1380 bytes of response-body
Received HTTP code 407 from proxy after CONNECT
Closing connection #0
Failure when receiving data from the peer
Какого-либо корректного выхода из данной ситуации я не нашел. Так что, при работе через прокси, если пароль не задан и возникает ошибка CURLE_RECV_ERROR, единственное что остается – повторить запрос, предварительно указав параметры авторизации на проксе.
LLVM, чтоб его.
Баг 2008 года в LLVM портит мне жизнь. Берем тестовый файлик следующего содержания:
class RPC_Service
{
public:
virtual ~RPC_Service ();
};
class EventLoggingInterface
{
virtual void
Ev (const char *file, int line, int sev, const char *fmt,
...) const = 0;
};
class RPCCore : RPC_Service, EventLoggingInterface
{
virtual void
Ev (const char *file, int line, int sev, const char *fmt, ...) const;
};
void
RPCCore::Ev (const char *file, int line, int sev, const char *format, ...) const
{
}
{
public:
virtual ~RPC_Service ();
};
class EventLoggingInterface
{
virtual void
Ev (const char *file, int line, int sev, const char *fmt,
...) const = 0;
};
class RPCCore : RPC_Service, EventLoggingInterface
{
virtual void
Ev (const char *file, int line, int sev, const char *fmt, ...) const;
};
void
RPCCore::Ev (const char *file, int line, int sev, const char *format, ...) const
{
}
Выполняем команду:
/Developer/usr/bin/llvm-g++ thunk_error.cpp -c
И в результате получаем:
thunk_error.cpp:19: error: generic thunk code fails for method ‘virtual void RPCCore::Ev(const char*, int, int, const char*, ...) const’ which uses ‘...’
Неужели придется отказаться от LLVM? Интерфейс, в моем случае, поменять врятли удастся. Вобщем писать кроссплатформенный код это еще та засада
Квалификатор restraint
Последнее время я довольно много пишу на Си, да чистое Си, без никаких плюсов, обджектив и прочей радости. На первый взгляд, в Си все очень и очень просто. Но, как оказалось, это только кажется, на том же BrainBench в тесте по Си мне удалось набрать всего 3.25, против 4.34 по плюсам. А еще говорят что BB ни о чем не говорит, говорит и еще как
А вступление это вот к чему. Я решил написать небольшую серию заметок про Си, если говорить точнее, то про C99. Ведь лучший способ что-то запомнить – это написать.
В состав C99 был добавлен новый квалификатор типа – restraint.
Данный квалификатор используется применительно к указателям и говорит компилятору о том, что данные, на которые указывают такие указатели, не являются пересекающимися объектами. Чисто теоретически, подобная информаия позволяет компилятору произвести дополнительные виды оптимизации. Теоретически, т.к. покрутив этот квалификатор и так и сяк я не сумел заставить компилятор хоть как-то изменить генерируемый код.
Основные варианты использования квалификатора restraint:
Работаем с таймерами.
До появления вот этой темы на РСДНе я как-то не предавал особого значения таймерам в Mac OS X. Ну есть они и есть, как будет нужно так разберусь. Но как оказалось, стандартных POSIX вызовов, таких как timer_create/timer_delete у нас нет, а то что есть не всегда подходит.
Хорошенько поковырявшись в документации я пришел к следующему выводу. Всего доступны 3 способа работы с таймерами, дающие приблизительно одинаковый эффект:
- NSTimer из Foundation;
- RunLoop из CoreFoundation;
- Таймеры из Mach. Хотя у меня данный пункт вызвал некоторые трудности.
cURL и корневые сертификаты
В описанном раньше способе работы с HTTPS соединением есть одна проблема – необходимо каким-то способом тащить за собой актуальный список корневых сертификатов. А тащить, обновлять, следить за изменениями… Вобщем задача не из тривиальных.
Не знаю как на Венде, а в Mac OS X можно все это дело переложить на Apple:
sudo security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain > roots.pem
После чего передать полученный список корневых сертификатов в cURL.
HTTPS & cURL
В пятницу, работая над одной из наших подсистем, я занимался прикручиванием cURL и тихо охреневал с того, что пишет народ народ в интернете по поводу реализации работы с HTTPS при использовании cURL. Лично я всегда считал что HTTPS необходим для установки защищенного соединения. Из чего следует что, во-первых, данные передаются в шифрованном виде, и во-вторых, мы знаем с кем общаемся.
Так вот, как выяснилось на практике, если с шифрованием ни у кого вопросов не возникает, то вот на авторизацию все кладут болт.
Причем основательно, например так:
curl_easy_setopt( curl_, CURLOPT_SSL_VERIFYPEER, 0 );
Что отключает проверку полученного сертификата. Ну а особо одаренные делают даже так:
curl_easy_setopt( curl_, CURLOPT_SSL_VERIFYHOST, 0 );
Что отключает проверку соответствия хоста, указанного в сертификате, с хостом, с которым мы общаемся.
Что интересно, если проверку канала обычно отключают из за глупости и лени, то проверку хоста может отключить разве что феерический идит, но, как показал гугл, их полно. Подобное решение для меня большая загадка, зачем нужно шифровать данные, если не известно с кем идет общение?
Так вот, как оказалось все дело в том, что если не выключить проверку канала то возникают различные неприятные ошибки связанные с невозможностью проверки сертификата канала. Например вот такие:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
В то же время информации том, что делать в такой ситуации в интернете по большому счету нет. Но все не так уж и страшно, всего-то немного терпения и экспериментов.
Все решается довольно просто. Необходимо скачать набор сертификатов с сайта cURL и передать их в библиотеку при помощи CURLOPT_CAINFO. Хотя в документации к библиотеке и говорится что эта функция не работает под Windows, это не соответствует действительности. Она отлично работает как в Mac OS X так и в Windows. В cURL для установки сертификатов будет вызвана OpenSSL функция SSL_CTX_load_verify_locations, соответственно все сертификаты должны быть в PEM формате.
Собственно это все, после этого все должно отлично работать.