diff options
Diffstat (limited to '_posts')
45 files changed, 0 insertions, 2484 deletions
diff --git a/_posts/2015-07-03-std-call-once-bug.md b/_posts/2015-07-03-std-call-once-bug.md deleted file mode 100644 index 8191ad3..0000000 --- a/_posts/2015-07-03-std-call-once-bug.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -title: std::call_once bug in Visual C++ 2012/2013 -category: C++ ---- -I've recently come across a nasty standard library bug in the implementation -shipped with Microsoft Visual Studio 2012/2013. -[StackOverflow was of no help], so I had to somehow report the bug to the -maintainers. -Oddly enough, Visual Studio's [Connect page] wouldn't let me report one, -complaining about the lack of permissions, even though I was logged in from my -work account, associated with my Visual Studio 2013 installation. - -Fortunately, I've come across the personal website of this amazing guy, -[Stephan T. Lavavej], who appears to be the chief maintainer of Microsoft's -standard library implementation. -He seems to be your go-to guy when it comes to obvious standard library -misbehaviours. - -[StackOverflow was of no help]: https://stackoverflow.com/questions/26477070/concurrent-stdcall-once-calls -[Connect page]: https://connect.microsoft.com/VisualStudio -[Stephan T. Lavavej]: http://nuwen.net/stl.html - -C++11 and singletons --------------------- - -Anyway, the story begins with me trying to implement the singleton pattern -using C++11 facilities like this: - -```c++ -#include <mutex> - -template <typename Derived> -class Singleton { -public: - static Derived& get_instance() { - std::call_once(initialized_flag, &initialize_instance); - return Derived::get_instance_unsafe(); - } - -protected: - Singleton() = default; - ~Singleton() = default; - - static Derived& get_instance_unsafe() { - static Derived instance; - return instance; - } - -private: - static void initialize_instance() { - Derived::get_instance_unsafe(); - } - - static std::once_flag initialized_flag; - - Singleton(const Singleton&) = delete; - Singleton& operator=(const Singleton&) = delete; -}; - -template <typename Derived> -std::once_flag Singleton<Derived>::initialized_flag; -``` - -Neat, huh? -Now other classes can inherit from `Singleton`, implementing the singleton -pattern effortlessly: - -```c++ -class Logger : public Singleton<Logger> { -private: - Logger() = default; - ~Logger() = default; - - friend class Singleton<Logger>; -}; -``` - -Note that the [N2660] standard proposal isn't/wasn't implemented in the -compilers shipped with Visual Studio 2012/2013. -If it was, I wouldn't, of course, need to employ this `std::call_once` -trickery, and the implementation would be much simpler, i.e. something like -this: - -```c++ -class Logger { -public: - static Logger& get_instance() { - static Logger instance; - return instance; - } - -private: - Logger() = default; - ~Logger() = default; -}; -``` - -<div class="alert alert-info" markdown="1"> - -The point is that the `Logger::get_instance` routine above wasn't thread-safe -until C++11. -Imagine what might happen if `Logger`'s constructor takes some time to -initialize the instance. -If a couple of threads then call `get_instance`, the first thread might begin -the initialization process, making the other thread believe that the instance -had already been intialized. -This other thread might then return a reference to the instance which hasn't -yet completed its initialization and is most likely unsafe to use. - -Since C++11 includes the proposal mentioned above, this routine would indeed be -thread-safe in C++11. -Unfortunately, the compilers shipped with Visual Studio 2012/2013 don't/didn't -implement this particular proposal, which caused me to look at -`std::call_once`, which seemed to implement exactly what I needed. - -</div> - -[N2660]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm - -Problem -------- - -Unfortunately, matters became a bit more complicated when I tried to introduce -two singletons, one having a dependency on the other. -I had `Logger`, like in the example above, and some kind of a "master" -singleton (let's call it `Duke`). -`Duke`'s constructor was complicated and time-consuming, and definitely -required some logging to be done. -I thought that I could simply call `Logger::get_instance` inside `Duke`'s -constructor, and everything looked fine at first glance. - -```c++ -#include <chrono> -#include <thread> - -class Logger : public Singleton<Logger> { -public: - Logger& operator<<(const char* msg) { - // Actual logging is stripped for brevity. - return *this; - } - -private: - Logger() { - // Opening log files, etc. - std::this_thread::sleep_for(std::chrono::seconds{3}); - } - - ~Logger() = default; - - friend class Singleton<Logger>; -}; - -class Duke : public Singleton<Duke> { -private: - Duke() { - Logger::get_instance() << "started Duke's initialization"; - // It's a lot of work to be done. - std::this_thread::sleep_for(std::chrono::seconds{10}); - Logger::get_instance() << "finishing Duke's initialization"; - } - - ~Duke() = default; - - friend class Singleton<Duke>; -}; -``` - -Now, what happens if I have two threads, one using the `Duke` instance, and the -other logging something? -Like in this example: - -```c++ -#include <thread> - -namespace { - -void get_logger() { - entered(__FUNCTION__); - Logger::get_instance(); - exiting(__FUNCTION__); -} - -void get_duke() { - entered(__FUNCTION__); - Duke::get_instance(); - exiting(__FUNCTION__); -} - -} - -int main() { - std::thread t1{&get_duke}; - std::thread t2{&get_logger}; - t1.join(); - t2.join(); - return 0; -} -``` - -`entered` and `exiting` are utility functions to print timestamps. -The implementation is included in the [complete code sample]. -{: .alert .alert-info } - -The first thread is supposed to have the total running time of about 13 -seconds, right? -Three seconds to initialize the `Logger` instance and ten to initialize the -`Duke` instance. -The second thread, similarly, is supposed to be done in about 3 seconds -required for the initialization of `Logger`. - -Weirdly, this program produces the following output when compiled using Visual -Studio 2013's compiler: - - Entered `anonymous-namespace'::get_duke at Fri Jul 03 02:26:16 2015 - Entered `anonymous-namespace'::get_logger at Fri Jul 03 02:26:16 2015 - Exiting `anonymous-namespace'::get_duke at Fri Jul 03 02:26:29 2015 - Exiting `anonymous-namespace'::get_logger at Fri Jul 03 02:26:29 2015 - -Isn't it wrong that the second thread actually took the same 13 seconds as the -first thread? -Better check with some other compiler in case it was me who made a mistake. -Unfortunately, the program behaves as expected when compiled using GCC: - - Entered get_logger at Fri Jul 3 02:27:12 2015 - Entered get_duke at Fri Jul 3 02:27:12 2015 - Exiting get_logger at Fri Jul 3 02:27:15 2015 - Exiting get_duke at Fri Jul 3 02:27:25 2015 - -So it appears that the implementation of `std::call_once` shipped with Visual -Studio 2012/2013 relies on some kind of a global lock, which causes even the -simple example above to misbehave. - -The [complete code sample] to demonstrate the misbehaviour described above can -be found in this blog's repository. - -[complete code sample]: {{ site.github.repository_url }}/tree/master/std_call_once_bug - -Conclusion ----------- - -So, since I couldn't submit the bug via Visual Studio's [Connect page], I wrote -to Mr. Lavavej directly, not hoping for an answer. -Amazingly, it took him less than a day to reply. -He told me he was planning to overhaul `std::call_once` for Visual Studio 2015. -Meanwhile, I had to stick to something else; I think I either dropped logging -from `Duke`'s constructor or initialized all the singleton instances manually -before actually using any of them. -In a few months, Mr. Lavavej replied to me that the bug has been fixed in -Visual Studio 2015 RTM. -I would like to thank him for the professionalism and responsibility he's -shown. diff --git a/_posts/2017-01-07-building-boost.md b/_posts/2017-01-07-building-boost.md deleted file mode 100644 index cddba13..0000000 --- a/_posts/2017-01-07-building-boost.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -title: Building Boost on Windows -category: C++ ---- -Below you can find the steps required to build Boost libraries on Windows. -These steps tightly fit my typical workflow, which is to use Boost libraries in -CMake builds using either Visual Studio or the combination of Cygwin + -MinGW-w64. -I would expect, however, that the procedure for the latter toolset can easily -be adjusted for generic GCC distributions (including vanilla GCCs found in -popular Linux distributions). - -One of the features of this workflow is that I build throwaway, "run -everywhere, record the results, and scrap it" executables more often than not, -so I prefer to link everything statically, including, for instance, C/C++ -runtimes. -This is implemented by passing `runtime-link=static` to Boost's build utility -`b2`; change this to `runtime-link=dynamic` to link the runtime dynamically. - -Excerpts from shell sessions in this post feature a few different commands -besides Boost's `b2` and `cmake`, like `cd` and `cat`. -They are used to hint at my personal directory layout, display various -auxiliary files, etc. -Windows' `cd`, for example, simply prints the current working directory; -Cygwin's `pwd` serves the same purpose. -`cat` is used to display files. - -Visual Studio -------------- - -Statically-linked Boost libraries are built, both the debug and the release -versions of them (these are default settings). -While it is required to keep x86 and x64 libraries in different directories (to -avoid file name clashes), it's not necessary to separate debug libraries from -their release counterparts, because that information is actually encoded in -file names (the "gd" suffix). - -### x86 - -{% capture out1 %} -D:\workspace\third-party\boost_1_61_0\msvc -{% endcapture %} - -{% capture cmd3 %} -b2 --stagedir=stage\x86 ^ - runtime-link=static ^ - --with-filesystem ^ - --with-program_options ^ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cd' out=out1 %} -{% include jekyll-theme/shell.html cmd='bootstrap' %} -{% include jekyll-theme/shell.html cmd=cmd3 %} - -### x64 - -The only important difference is that you have to pass `address-model=64` to -`b2` (notice also the different "staging" directory). - -{% capture out1 %} -D:\workspace\third-party\boost_1_61_0\msvc -{% endcapture %} - -{% capture cmd3 %} -b2 --stagedir=stage\x64 ^ - runtime-link=static ^ - address-model=64 ^ - --with-filesystem ^ - --with-program_options ^ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cd' out=out1 %} -{% include jekyll-theme/shell.html cmd='bootstrap' %} -{% include jekyll-theme/shell.html cmd=cmd3 %} - -Cygwin + MinGW-w64 ------------------- - -Contrary to the Visual Studio example above, it is required to store debug and -release libraries *as well as* x86 and x64 libraries in different directories. -It is required to avoid file name clashes; unlike the Visual Studio "toolset" -(in Boost's terms), GCC-derived toolsets don't encode any information (like -whether the debug or the release version of a library was built) in file names. - -Also, linking the runtime statically doesn't really make sense for MinGW, as it -always links to msvcrt.dll, which is [simply the Visual Studio 6.0 runtime]. - -[simply the Visual Studio 6.0 runtime]: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ - -In the examples below, only the debug versions of the libraries are built. -Build the release versions by executing the same command, and substituting -`variant=release` instead of `variant=debug` and either -`--stagedir=stage/x86/release` or `--stagedir=stage/x64/release`, depending -on the target architecture. - -### x86 - -{% capture out1 %} -/cygdrive/d/workspace/third-party/boost_1_61_0/mingw -{% endcapture %} - -{% capture out3 %} -using gcc : : i686-w64-mingw32-g++ ; -{% endcapture %} - -{% capture cmd4 %} -./b2 toolset=gcc-mingw \ - target-os=windows \ - link=static \ - variant=debug \ - --stagedir=stage/x86/debug \ - --user-config=user-config-x86.jam \ - --with-filesystem \ - --with-program_options \ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='pwd' out=out1 %} -{% include jekyll-theme/shell.html cmd='./bootstrap.sh' %} -{% include jekyll-theme/shell.html cmd='cat user-config-x86.jam' out=out3 %} -{% include jekyll-theme/shell.html cmd=cmd4 %} - -The "user" configuration file above stopped working at some point; not sure as -to who's to blame, Cygwin or Boost. -If you see something like "`error: provided command 'i686-w64-mingw32-g++' not -found`", add ".exe" to the binary name above, so that the whole file reads -"`using gcc : : i686-w64-mingw32-g++.exe ;`". -{: .alert .alert-info } - -### x64 - -Notice the two major differences from the x86 example: - -* the addition of `address-model=64` (as in the example for Visual Studio), -* the different "user" configuration file, pointing to `x86_64-w64-mingw32-g++` -instead of `i686-w64-mingw32-g++`. - -Again, as in the example for Visual Studio, a different "staging" directory -needs to be specified using the `--stagedir` parameter. - -{% capture out1 %} -/cygdrive/d/workspace/third-party/boost_1_61_0/mingw -{% endcapture %} - -{% capture out3 %} -using gcc : : x86_64-w64-mingw32-g++ ; -{% endcapture %} - -{% capture cmd4 %} -./b2 toolset=gcc-mingw \ - address-model=64 \ - target-os=windows \ - link=static \ - variant=debug \ - --stagedir=stage/x64/debug \ - --user-config=user-config-x64.jam \ - --with-filesystem \ - --with-program_options \ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='pwd' out=out1 %} -{% include jekyll-theme/shell.html cmd='./bootstrap.sh' %} -{% include jekyll-theme/shell.html cmd='cat user-config-x64.jam' out=out3 %} -{% include jekyll-theme/shell.html cmd=cmd4 %} - -The "user" configuration file above stopped working at some point; not sure as -to who's to blame, Cygwin or Boost. -If you see something like "`error: provided command 'x86_64-w64-mingw32-g++' -not found`", add ".exe" to the binary name above, so that the whole file reads -"`using gcc : : x86_64-w64-mingw32-g++.exe ;`". -{: .alert .alert-info } - -Usage in CMake --------------- - -### Visual Studio - -Examples below apply to Visual Studio 2015. -You may want to adjust the paths. - -#### x86 - -{% capture out1 %} -D:\workspace\build\test_project\msvc\x86 -{% endcapture %} - -{% capture cmd2 %} -cmake -G "Visual Studio 14 2015" ^ - -D BOOST_ROOT=D:\workspace\third-party\boost_1_61_0\msvc ^ - -D BOOST_LIBRARYDIR=D:\workspace\third-party\boost_1_61_0\msvc\stage\x86\lib ^ - -D Boost_USE_STATIC_LIBS=ON ^ - -D Boost_USE_STATIC_RUNTIME=ON ^ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cd' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 %} - -#### x64 - -{% capture out1 %} -D:\workspace\build\test_project\msvc\x64 -{% endcapture %} - -{% capture cmd2 %} -cmake -G "Visual Studio 14 2015 Win64" ^ - -D BOOST_ROOT=D:\workspace\third-party\boost_1_61_0\msvc ^ - -D BOOST_LIBRARYDIR=D:\workspace\third-party\boost_1_61_0\msvc\stage\x64\lib ^ - -D Boost_USE_STATIC_LIBS=ON ^ - -D Boost_USE_STATIC_RUNTIME=ON ^ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cd' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 %} - -### Cygwin & MinGW-w64 - -Examples below only apply to debug CMake builds. -Notice that, contrary to the Visual Studio examples above, debug and release -builds must be kept in separate directories. -You may also want to adjust the paths. - -#### x86 - -{% capture out1 %} -/cygdrive/d/workspace/build/test_project/mingw/x86/debug -{% endcapture %} - -{% capture cmd2 %} -cmake -G "Unix Makefiles" \ - -D CMAKE_BUILD_TYPE=Debug \ - -D CMAKE_C_COMPILER=i686-w64-mingw32-gcc \ - -D CMAKE_CXX_COMPILER=i686-w64-mingw32-g++ \ - -D BOOST_ROOT=/cygdrive/d/workspace/third-party/boost_1_61_0/mingw \ - -D BOOST_LIBRARYDIR=/cygdrive/d/workspace/third-party/boost_1_61_0/mingw/stage/x86/debug/lib \ - -D Boost_USE_STATIC_LIBS=ON \ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='pwd' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 %} - -#### x64 - -{% capture out1 %} -/cygdrive/d/workspace/build/test_project/mingw/x64/debug -{% endcapture %} - -{% capture cmd2 %} -cmake -G "Unix Makefiles" \ - -D CMAKE_BUILD_TYPE=Debug \ - -D CMAKE_C_COMPILER=x86_64-w64-mingw32-gcc \ - -D CMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++ \ - -D BOOST_ROOT=/cygdrive/d/workspace/third-party/boost_1_61_0/mingw \ - -D BOOST_LIBRARYDIR=/cygdrive/d/workspace/third-party/boost_1_61_0/mingw/stage/x64/debug/lib \ - -D Boost_USE_STATIC_LIBS=ON \ - ... -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='pwd' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 %} diff --git a/_posts/2017-06-24-static-vs-inline-vs-unnamed-namespaces.md b/_posts/2017-06-24-static-vs-inline-vs-unnamed-namespaces.md deleted file mode 100644 index cb12867..0000000 --- a/_posts/2017-06-24-static-vs-inline-vs-unnamed-namespaces.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -title: static vs. inline vs. namespace { -category: C++ -snippets_root_directory: snippets/static_vs_inline_vs_unnamed_namespaces -snippets_language: c++ -snippets: - static: - - static/main.cpp - - static/proxy.cpp - - static/proxy.hpp - - static/shared.hpp - inline: - - inline/shared.hpp - inline_weird: - - inline/weird/main.cpp - - inline/weird/another.cpp - - inline/weird/another.hpp - unnamed_namespaces_weird: - - unnamed_namespaces/weird/main.cpp - - unnamed_namespaces/weird/another.cpp - - unnamed_namespaces/weird/another.hpp - unnamed_namespaces_ok: - - unnamed_namespaces/ok/main.cpp - - unnamed_namespaces/ok/another.cpp - - unnamed_namespaces/ok/another.hpp - static_and_inline: - - static_and_inline/main.cpp - - static_and_inline/proxy.cpp - - static_and_inline/proxy.hpp - - static_and_inline/shared.hpp - unnamed_namespace_and_inline: - - unnamed_namespace_and_inline/main.cpp - - unnamed_namespace_and_inline/proxy.cpp - - unnamed_namespace_and_inline/proxy.hpp - - unnamed_namespace_and_inline/shared.hpp - separate_method_definitions: - - separate_method_definitions/main.cpp - - separate_method_definitions/another.cpp - - separate_method_definitions/another.hpp - - separate_method_definitions/shared.hpp ---- -In this post I'll try to figure out whether I should use `static`, `inline` or -unnamed namespaces for function definitions. - -TL;DR ------ - -Here's my attempt to build an algorithm to decide whether a class/function -should be defined with either of the `static`/`inline` specifiers or put into -an unnamed namespace. -The first question I answer is: is the entity defined in a header file or in a -.cpp file? - -* **In a header** — Is it a class or a function? - * **Class** — There's no need to do anything. - * **Function** — Do you want it to behave differently for each -translation unit (may be useful, for example, for logging)? - * **Yes** — Use `static`. - * **No** — Use `inline`. -* **In a .cpp file** — Put it into an unnamed namespace. - -`static` --------- - -It's an old C-style method of defining functions in header files. -This way, every translation unit gets its own copy of a function. -What does that mean? -The most obvious implication that pops into my head is that every local static -variable defined inside that function gets an independent replica in every -translation unit. -For example, the program below would print - -``` -1 -1 -``` - -due to the fact that both main.cpp and proxy.cpp get their own versions of `n` -from `shared()`. - -{% include jekyll-theme/snippets/section.html section_id='static' %} - -In C, this is the only way to share function definitions between translation -units (apart from the usual way of declaring a function in a header file and -putting its definition to a .c file). - -### Properties - -* Using `static`, you can share function definitions between multiple -translation units. -* Each unit gets its own replica of the function: they have different -addresses, their local static variables are independent, etc. -* If different translation units define different functions with the same -name using the `static` specifier, each unit can use its function without any -issues. -This might seem like an trivial claim, but other approaches sometimes disallow -this, which is discussed below. - -`inline` --------- - -It's well-known that this keyword has pretty much nothing to do with whether a -function will actually be inlined or not. -It's used much more often to define functions in header files, since every -function defined this way will be the same (as in "will have the same address") -in every translation unit. -Let's try and adjust the definition of `shared()` accordingly: - -{% include jekyll-theme/snippets/section.html section_id='inline' %} - -The same program would then print - -``` -1 -2 -``` - -since both `main()` and `proxy()` would call the same `shared()`, incrementing -the same `n`. - -Weird things happen when different translation units define different `inline` -functions with the same name. - -{% include jekyll-theme/snippets/section.html section_id='inline_weird' %} - -According to my simple experiments, this program produces different output -based on which .cpp file was specified first on the command line during -compilation. -For example, this is the output of test.exe produced with either `cl /W4 /EHsc -main.cpp another.cpp /Fe:test.exe` or `g++ -Wall -Wextra -std=c++11 main.cpp -another.cpp -o test.exe`. - -``` -main.cpp: shared() -main.cpp: shared() -``` - -If we swap the order of .cpp files (`another.cpp main.cpp` instead of `main.cpp -another.cpp`), the output becomes - -``` -another.cpp: shared() -another.cpp: shared() -``` - -No warnings/errors are emitted, making the situation truly disturbing. -I tested this with GNU compiler version 5.4.0 and Microsoft compiler version -19.00.24210. - -This behavior can be easily fixed either by making these functions `static` or -by using unnamed namespaces (see below). - -### Properties - -* Using `inline`, you can share function definitions between multiple -translation units. -* Each translation unit will use the same function: it will have the same -address in every translation unit, its local static variables will be shared, -etc. -* Defining different `inline` functions with the same name in different -translation units is undefined behavior. - -Two inline functions might be different even if they are the same textually. -For example, they might reference two global variables which have the same -name, but are defined in different translation units. -{: .alert .alert-info } - -`namespace {` -------------- - -With respect to function definitions, unnamed namespaces are, according to my -understanding, quite similar to the `static` keyword. -The additional value they provide is that they provide a way to apply `static` -not only to functions, but to classes also. -Remember the weirdness that happens when multiple translation units define -different `inline` functions with the same name? -Arguably, it gets even worse if we add classes to the equation. - -{% include jekyll-theme/snippets/section.html section_id='unnamed_namespaces_weird' %} - -Compiling this program the same way we did in the `inline` example (`cl /W4 -/EHsc main.cpp another.cpp /Fe:test.exe`/`g++ -Wall -Wextra -std=c++11 main.cpp -another.cpp -o test.exe`) yields different outputs depending on which .cpp file -was specified first. - -``` -main.cpp: Test::Test() -1 -main.cpp: Test::Test() -``` - -``` -another.cpp: Test::Test() -1065353216 -another.cpp: Test::Test() -``` - -I'm not sure why anybody would want that. -This can be easily fixed by putting both `Test` classes into unnamed -namespaces. -The program than reads - -{% include jekyll-theme/snippets/section.html section_id='unnamed_namespaces_ok' %} - -After the adjustment, it produces the same output regardless of compilation -options. - -``` -main.cpp: Test::Test() -1 -another.cpp: Test::Test() -``` - -Notice how sharing classes defined in header files isn't discussed here. -The standard actually guarantees that if a class is defined in a header file, -all translation units that use it share the definition. - -### Properties - -* Essentially, unnamed namespaces allow the `static` keyword to be applied to -classes. -* Similar to the `static` approach, each translation unit gets its own replica -of a function/class, including their own local static variables, etc. -* Defining different classes with the same name in different translation units -(without utilizing unnamed namespaces) is undefined behavior. - -Tricky cases ------------- - -### `static` + `inline` - -In case a function is defined as `static inline`, `static` wins, and `inline` -is ignored. -The program below outputs - -``` -1 -1 -``` - -{% include jekyll-theme/snippets/section.html section_id='static_and_inline' %} - -In general, I can't think of a reason to define a `static inline` function. - -### `namespace {` + `inline` - -If an `inline` function is defined in an unnamed namespace, the unnamed -namespace wins. -The program below outputs - -``` -1 -1 -``` - -{% include jekyll-theme/snippets/section.html section_id='unnamed_namespace_and_inline' %} - -In general, I can't think of a reason to define an `inline` function in an -unnamed namespace. - -### Separate method definitions - -If you want to separate your class declaration from its method definitions -while keeping them in the same header file, each method must be explicitly -defined `inline`. -The program below outputs - -``` -1 -2 -``` - -{% include jekyll-theme/snippets/section.html section_id='separate_method_definitions' %} diff --git a/_posts/2018-02-18-peculiar-indentation.md b/_posts/2018-02-18-peculiar-indentation.md deleted file mode 100644 index c477382..0000000 --- a/_posts/2018-02-18-peculiar-indentation.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: Peculiar Haskell indentation -category: Haskell ---- -I've fallen into a Haskell indentation pitfall. -I think it must be common, so I'm describing it here. - -The problem is that indentation rules in `do` blocks are not intuitive to me. -For example, the following function is valid Haskell syntax: - -```haskell -foo1 :: IO () -foo1 = - alloca $ \a -> - alloca $ \b -> - alloca $ \c -> do - poke a (1 :: Int) - poke b (1 :: Int) - poke c (1 :: Int) - return () -``` - -In fact, this funnier version is also OK: - -```haskell -foo2 :: IO () -foo2 = alloca $ \a -> - alloca $ \b -> - alloca $ \c -> do - poke a (1 :: Int) - poke b (1 :: Int) - poke c (1 :: Int) - return () -``` - -If you add an outer `do` however, things become a little more complicated. -For example, this is the valid version of the functions above with an outer -`do`: - -```haskell -foo3 :: IO () -foo3 = do - alloca $ \a -> - alloca $ \b -> - alloca $ \c -> do - poke a (1 :: Int) - poke b (1 :: Int) - poke c (1 :: Int) - return () -``` - -Notice the extra indentation for each of the `alloca`s. -When I tried to remove these seemingly excessive indents, GHC complained with -the usual `parse error (possibly incorrect indentation or mismatched -brackets)`. - -```haskell -foo4 :: IO () -foo4 = do - alloca $ \a -> - alloca $ \b -> - alloca $ \c -> do - poke a (1 :: Int) - poke b (1 :: Int) - poke c (1 :: Int) - return () -``` - -The truth is, the rules for desugaring `do` blocks are surprisingly simple and -literal. -GHC inserts semicolons according to the rules [found in the Wikibook]. -So it inserts semicolons between the `alloca`s on the same level, so `foo4` -becomes: - -```haskell -foo4 :: IO () -foo4 = do - { alloca $ \a -> - ; alloca $ \b -> - ; alloca $ \c -> do - { poke a (1 :: Int) - ; poke b (1 :: Int) - ; poke c (1 :: Int) - ; return () - } - } -``` - -[found in the Wikibook]: https://en.wikibooks.org/wiki/Haskell/Indentation#Explicit_characters_in_place_of_indentation - -The semicolons after `->` are clearly invalid Haskell syntax, hence the error. - -P.S. To compile the functions above, you need to include them in a module and -add proper imports, e.g. - -```haskell -module PeculiarIndentation where - -import Foreign.Marshal.Alloc (alloca) -import Foreign.Storable (poke) -``` diff --git a/_posts/2020-02-24-ssh-tunnel-windows.md b/_posts/2020-02-24-ssh-tunnel-windows.md deleted file mode 100644 index fdbc134..0000000 --- a/_posts/2020-02-24-ssh-tunnel-windows.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -title: Persistent SSH tunnel ---- -SSH tunneling is awesome. -For some reason, I've only recently learned about this feature, but I've been -immediately blown away by how useful it can be. - -Basically, to use SSH tunneling (a.k.a. port forwarding) you need to have a SSH -client (`ssh`) with an access to a SSH server. -You can then access any host your SSH server has access to. -It works like this: - -* the client establishes a connection to the SSH server, -* the client asks the server to forward incoming requests to the destination -host, -* the client listens on a proxy port on the local machine, and forwards -requests to the SSH server. - -Say, you have access to SSH server `gateway` on port 22, and you want to gain -access to HTTPS server `dest` on port 443, which is only accessible from the -the SSH server. -You can then run something like - -{% include jekyll-theme/shell.html cmd='ssh -L 4433:dest:443 gateway -p 22' %} - -And now you can access `dest` at `https://localhost:4433/`. -That's brilliant, really. - -But there's more. -You can make a _reverse_ tunnel, allowing you to give access to any host your -client computer has access to, via a remote SSH server. -It works like this: - -* your SSH client establishes a connection to the SSH server, -* the client asks the server to listen on a port of your choosing and forward -incoming requests to the client, -* the client forwards incoming requests to the destination host. - -This, as I've recently learned, is a common pattern to subvert corporate -firewalls, which frequently forbid incoming connections. -Say, you want to access your work computer from home via RDP. -Both your home and your work computers have access to a SSH server `gateway` on -port 22 (you might want to change it to port 80 or 443 if your outside -connections are filtered). - -You can then run something like (notice the `-R`) - -{% include jekyll-theme/shell.html cmd='ssh -R 13389:127.0.0.1:3389 gateway -p 22' %} - -and now you can connect to `gateway:13389` from your home computer using a RDP -client. -Even more brilliant! - -You might need to set the `GatewayPorts` setting to `yes` or `clientspecified` -on your SSH server (typically in "/etc/ssh/sshd_config"). - -Batch mode ----------- - -If you want to establish a reverse SSH tunnel automatically, some tweaking is -required. -First, set some SSH client options: - -* `-F /dev/null` to disregard the user config, -* `-oBatchMode=yes` to run non-interactively, -* `-oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null` to disable server -verification (optional), -* `-oExitOnForwardFailure=yes` to exit if port forwarding fails, -* `-oServerAliveCountMax=3 -oServerAliveInterval=15` to break the connection if -the server or the network is down, -* `-N -n -T` to only forward the ports and not execute the shell or any -additional commands. - -Thus, the full command would be something like - -{% capture cmd1 %} -ssh \ - -F /dev/null \ - -oBatchMode=yes \ - -oStrictHostKeyChecking=no \ - -oUserKnownHostsFile=/dev/null \ - -oExitOnForwardFailure=yes \ - -oServerAliveCountMax=3 \ - -oServerAliveInterval=15 \ - -N -n -T \ - -R 13389:127.0.0.1:3389 \ - user@gateway -p 22 \ - -i ~/.ssh/tunnel -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 %} - -Adjust the `user@gateway -p 22` part accordingly. - -Notice also `-i ~/.ssh/tunnel`. -It's the path to the SSH key used to authenticate with the server. -It can't have a passphrase, since the command will be run non-interactively, -and the public key must be in the server's authorized_keys file. - -For best results, you should also adjust some settings on the SSH server. -Namely, you should enable client keep-alives on the server using something like - -``` -ClientAliveCountMax 3 -ClientAliveInterval 15 -``` - -Unless you do that, even if the client breaks the connection, you won't be able -to re-establish it for a long-ish time, since the server wouldn't know that the -original connection is no longer valid. - -As a service ------------- - -Cygwin is awesome. -I've been using for 10+ years, and it has never failed me. -It comes with a SSH server, a client (you need to install the `openssh` package -for both of these), and a service manager, `cygrunsrv`. -`cygrunsrv` is similar to [NSSM], as it allows to wrap any executable into a -native Windows service. - -[NSSM]: https://nssm.cc/ - -Using `cygrunsrv`, you can create a Windows service to establish a reverse SSH -tunnel automatically. - -{% capture cmd1 %} -cygrunsrv \ - -I ssh_tunnel \ - -p /usr/bin/ssh \ - --args '-F /dev/null -oBatchMode=yes -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oExitOnForwardFailure=yes -oServerAliveCountMax=3 -oServerAliveInterval=15 -N -n -T -R 13389:127.0.0.1:3389 user@gateway -p 22 -i ~/.ssh/tunnel' \ - --disp 'Reverse SSH tunnels' \ - --user user \ - --neverexits \ - --preshutdown -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 %} - -Adjust the `--user` and the `--args` values accordingly. - -You can then run `services.msc` and adjust the recovery settings for the -service to restart if `ssh` fails: - -<div class="row"> - <div class="col-xs-12 col-sm-8 col-md-6"> - <a href="{{ '/assets/img/ssh_tunnel_services.png' | relative_url }}" class="thumbnail"> - <img class="img-responsive" alt="services.msc" src="{{ '/assets/img/ssh_tunnel_services.png' | relative_url }}"> - </a> - </div> -</div> - -And voilà , you have an automatic reverse SSH tunnel on Windows for you! diff --git a/_posts/2020-05-06-docker-bind-mounts.md b/_posts/2020-05-06-docker-bind-mounts.md deleted file mode 100644 index 832c132..0000000 --- a/_posts/2020-05-06-docker-bind-mounts.md +++ /dev/null @@ -1,227 +0,0 @@ ---- -title: 'Docker: bind mounts & file ownership' ---- -If you want to: - -1. run your Docker service as a user other than root, -2. share a writable directory between your host and the container, - -you're in for a treat! -The thing is, files stored in the shared directory retain their ownership (and -by that I mean their UIDs and GIDs, as they're the only thing that matters) -after being mounted in the container. - -Case in point: - -{% capture cmd1 %} -docker run -it --rm -v "$( pwd ):/data" alpine touch /data/test.txt -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 %} - -would create file ./test.txt owned by root:root. - -You can fix that by using the `--user` parameter: - -{% capture cmd1 %} -docker run -it --rm -v "$( pwd ):/data" --user "$( id -u ):$( id -g )" alpine touch /data/test.txt -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 %} - -That would create file ./test.txt owned by the current user (if the current -working directory is writable by the current user, of course). - -More often though, instead of a simple `touch` call, you have a 24/7 service, -which absolutely mustn't run as root, regardless of whether `--user` was -specified or not. -In such cases, the logical solution would be to create a regular user in the -container, and use it to run the service. -In fact, that's what many popular images do, i.e. [Redis][Redis Dockerfile] and -[MongoDB][MongoDB Dockerfile]. - -[Redis Dockerfile]: https://github.com/docker-library/redis/blob/cc1b618d51eb5f6bf6e3a03c7842317b38dbd7f9/6.0/Dockerfile#L4 -[MongoDB Dockerfile]: https://github.com/docker-library/mongo/blob/5cbf7be9a486932b7e472a39e432c9a444628465/4.2/Dockerfile#L4 - -How do you run the service as regular user though? -It's tempting to use the `USER` directive in the Dockerfile, but that can be -overridden by `--user`: - -{% capture cmd1 %} -cat Dockerfile -{% endcapture %} -{% capture out1 %} -FROM alpine - -RUN addgroup --gid 9099 test-group && \ - adduser \ - --disabled-password \ - --gecos '' \ - --home /home/test-user \ - --ingroup test-group \ - --uid 9099 \ - test-user - -RUN touch /root.txt -USER test-user:test-group -RUN touch /home/test-user/test-user.txt - -CMD id && stat -c '%U %G' /root.txt && stat -c '%U %G' /home/test-user/test-user.txt -{% endcapture %} - -{% capture cmd2 %} -docker build -t id . -{% endcapture %} - -{% capture cmd3 %} -docker run -it --rm id -{% endcapture %} -{% capture out3 %} -uid=9099(test-user) gid=9099(test-group) -root root -test-user test-group -{% endcapture %} - -{% capture cmd4 %} -docker run -it --rm --user root id -{% endcapture %} -{% capture out4 %} -uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) -root root -test-user test-group -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 %} -{% include jekyll-theme/shell.html cmd=cmd3 out=out3 %} -{% include jekyll-theme/shell.html cmd=cmd4 out=out4 %} - -I suppose that's the reason why many popular images override ENTRYPOINT, using -a custom script (and `gosu`, which is basically `sudo`, I think) to forcefully -drop privileges (for example, see [Redis][Redis entrypoint], -[MongoDB][MongoDB entrypoint]). - -[Redis entrypoint]: https://github.com/docker-library/redis/blob/cc1b618d51eb5f6bf6e3a03c7842317b38dbd7f9/6.0/docker-entrypoint.sh#L11 -[MongoDB entrypoint]: https://github.com/docker-library/mongo/blob/5cbf7be9a486932b7e472a39e432c9a444628465/4.2/docker-entrypoint.sh#L12 - -Now, what if such service needs persistent storage? -A good solution would be to use Docker volumes. -For development though, you often need to just share a directory between your -host and the container, and it has to be writable by both the host and the -container process. -This can be accomplished using _bind mounts_. -For example, let's try to map ./data to /data inside a Redis container (this -assumes ./data doesn't exist and you're running as regular user with UID 1000; -press Ctrl+C to stop Redis): - -{% capture cmd1 %} -mkdir data -{% endcapture %} - -{% capture cmd2 %} -stat -c '%u' data -{% endcapture %} -{% capture out2 %} -1000 -{% endcapture %} - -{% capture cmd3 %} -docker run -it --rm --name redis -v "$( pwd )/data:/data" redis:6.0 -{% endcapture %} - -{% capture cmd4 %} -stat -c '%u' data -{% endcapture %} -{% capture out4 %} -999 -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 %} -{% include jekyll-theme/shell.html cmd=cmd2 out=out2 %} -{% include jekyll-theme/shell.html cmd=cmd3 %} -{% include jekyll-theme/shell.html cmd=cmd4 out=out4 %} - -As you can see, ./data changed its owner from user with UID 1000 (the host -user) to user with UID 999 (the `redis` user inside the container). -This is done in Redis' ENTRYPOINT script, just before dropping root privileges -so that the `redis-server` process owns the /data directory and thus can write -to it. - -If you want to preserve ./data ownership, Redis' image (and many others) -explicitly accommodates for it by _not_ changing its owner if the container is -run as anybody other than root. -For example: - -{% capture cmd1 %} -mkdir data -{% endcapture %} - -{% capture cmd2 %} -stat -c '%u' data -{% endcapture %} -{% capture out2 %} -1000 -{% endcapture %} - -{% capture cmd3 %} -docker run -it --rm --name redis -v "$( pwd )/data:/data" --user "$( id -u ):$( id -g )" redis:6.0 -{% endcapture %} - -{% capture cmd4 %} -stat -c '%u' data -{% endcapture %} -{% capture out4 %} -1000 -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 %} -{% include jekyll-theme/shell.html cmd=cmd2 out=out2 %} -{% include jekyll-theme/shell.html cmd=cmd3 %} -{% include jekyll-theme/shell.html cmd=cmd4 out=out4 %} - -Going hardcore --------------- - -Sometimes `--user` is not enough though. -The specified user is almost certainly missing from container's /etc/passwd, it -doesn't have a $HOME directory, etc. -All of that could cause problems with some applications. - -The solution often suggested is to create a container user with a fixed UID -(that would match the host user UID). -That way, the app won't be run as root, the user will have a proper entry in -/etc/passwd, it will be able to write to the bind mount owned by the host user, -and it won't have to change the directory's permissions. - -We can create a user with a fixed UID when - -1. building the image (using build `ARG`uments), -2. first starting the container by passing the required UID using environment -variables. - -The advantage of creating the user when building the image is that we can also -do additional work in the Dockerfile (like if you need to install dependencies -as that user). -The disadvantage is that the image would need to be rebuilt for every user on -every machine. - -Creating the user when first starting the container switches the pros and cons. -You don't need to rebuild the image every time, but you'll have to waste time -and resources by doing the additional work that could've been done in the -Dockerfile every time you create a container. - -For my project [jekyll-docker] I opted for the former approach, making sure the -`jekyll` process runs with the same UID as the user who built the image (unless -it was built by root, in which case it falls back to a custom UID of 999). -Seems to work quite nicely in practice. - -[jekyll-docker]: https://github.com/egor-tensin/jekyll-docker/tree/7d1824a5fac0ed483bc49209bbd89f564a7bcefe - -Useful links ------------- - -* [Docker and \-\-userns-remap, how to manage volume permissions to share data between host and container?](https://stackoverflow.com/q/35291520/514684) -* [What is the (best) way to manage permissions for Docker shared volumes?](https://stackoverflow.com/q/23544282/514684) -* [Handling Permissions with Docker Volumes](https://denibertovic.com/posts/handling-permissions-with-docker-volumes/) -* [File Permissions: the painful side of Docker](https://blog.gougousis.net/file-permissions-the-painful-side-of-docker/) -* [Avoiding Permission Issues With Docker-Created Files](https://vsupalov.com/docker-shared-permissions/) diff --git a/_posts/2020-05-20-makefile-escaping.md b/_posts/2020-05-20-makefile-escaping.md deleted file mode 100644 index d468cc3..0000000 --- a/_posts/2020-05-20-makefile-escaping.md +++ /dev/null @@ -1,439 +0,0 @@ ---- -title: Escaping characters in Makefile ---- -TL;DR: visit [this page] for a short and concise version of this article. -{: .alert .alert-success } - -[this page]: {% link _notes/makefile.md %} - -I'm a big sucker for irrelevant nitpicks like properly quoting arguments in -shell scripts. -I've also recently started using GNU make as a substitute for one-line shell -scripts (so instead of a bunch of scripts like build.sh, deploy.sh, test.sh I -get to have a single Makefile and can just run `make build`, `make deploy`, -`make test`). - -As a side note, there's an excellent [Makefile style guide] available on the -web. -I'm going to be using a slightly modified prologue suggested in the guide in -all Makefiles in this post: - -[Makefile style guide]: https://clarkgrubb.com/makefile-style-guide - -``` -MAKEFLAGS += --no-builtin-rules --no-builtin-variables --warn-undefined-variables -unexport MAKEFLAGS -.DEFAULT_GOAL := all -.DELETE_ON_ERROR: -.SUFFIXES: -SHELL := bash -.SHELLFLAGS := -eu -o pipefail -c -``` - -`make` invokes a shell program to execute recipes. -As issues of properly escaping "special" characters are going to be discussed, -the choice of shell is very relevant. -The Makefiles in this post specify `bash` explicitly using the `SHELL` -variable, but the same rules should apply for all similar `sh`-like shells. - -Quoting arguments ------------------ - -You should quote command arguments in `make` rule recipes, just like in shell -scripts. -This is to prevent a single argument from being expanded into multiple -arguments by the shell. - -{% capture out1 %} -# Prologue goes here... - -test_var := Same line? -export test_var - -test: - @printf '%s\n' $(test_var) - @printf '%s\n' '$(test_var)' - @printf '%s\n' $$test_var - @printf '%s\n' "$$test_var" -{% endcapture %} - -{% capture out2 %} -Same -line? -Same line? -Same -line? -Same line? -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd='make test' out=out2 %} - -This is quite often sufficient to write valid recipes. - -One thing to note is that you shouldn't use double quotes `"` for quoting -arguments, as they might contain literal dollar signs `$`, interpreted by the -shell as variable references, which is not something you always want. - -Escaping quotes ---------------- - -What if `test_var` included a single quote `'`? -In that case, even the quoted `printf` invocation would break because of the -mismatch. - -{% capture out1 %} -# Prologue goes here... - -test_var := Includes ' quote - -test: - printf '%s\n' '$(test_var)' -{% endcapture %} - -{% capture out2 %} -printf '%s\n' 'Includes ' quote' -bash: -c: line 0: unexpected EOF while looking for matching `'' -make: *** [Makefile:11: test] Error 2 -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd='make test' out=out2 %} - -One solution is to take advantage of how `bash` parses command arguments, and -replace every quote `'` by `'\''`. -This works because `bash` merges a string like `'Includes '\'' quote'` into -`Includes ' quote`. - -{% capture out1 %} -# Prologue goes here... - -escape = $(subst ','\'',$(1)) - -test_var := Includes ' quote - -test: - printf '%s\n' '$(call escape,$(test_var))' -{% endcapture %} - -{% capture out2 %} -printf '%s\n' 'Includes '\'' quote' -Includes ' quote -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd='make test' out=out2 %} - -Surprisingly, this works even in much more complicated cases. -You can have a recipe that executes a command that takes a whole other command -(with its own separate arguments) as an argument. -I guess the most common use case is doing something like `ssh 'rm -rf -$(junk_dir)'`, but I'll use nested `bash` calls instead for simplicity. - -{% capture out1 %} -# Prologue goes here... - -escape = $(subst ','\'',$(1)) - -test_var := Includes ' quote - -echo_test_var := printf '%s\n' '$(call escape,$(test_var))' -bash_test_var := bash -c '$(call escape,$(echo_test_var))' - -test: - printf '%s\n' '$(call escape,$(test_var))' - bash -c '$(call escape,$(echo_test_var))' - bash -c '$(call escape,$(bash_test_var))' -{% endcapture %} - -{% capture out2 %} -printf '%s\n' 'Includes '\'' quote' -Includes ' quote -bash -c 'printf '\''%s\n'\'' '\''Includes '\''\'\'''\'' quote'\''' -Includes ' quote -bash -c 'bash -c '\''printf '\''\'\'''\''%s\n'\''\'\'''\'' '\''\'\'''\''Includes '\''\'\'''\''\'\''\'\'''\'''\''\'\'''\'' quote'\''\'\'''\'''\''' -Includes ' quote -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd='make test' out=out2 %} - -That's somewhat insane, but it works. - -Shell output ------------- - -The `shell` function is one of the two most common ways to communicate with the -outside world in a Makefile (the other being environment variables). -This little `escape` function we've defined is actually sufficient to deal with -the output of the `shell` function safely. - -{% capture out1 %} -# Prologue goes here... - -escape = $(subst ','\'',$(1)) - -cwd := $(shell basename -- "$$( pwd )") - -simple_var := Simple value -composite_var := Composite value - $(simple_var) - $(cwd) - -.PHONY: test -test: - @printf '%s\n' '$(call escape,$(cwd))' - @printf '%s\n' '$(call escape,$(composite_var))' -{% endcapture %} - -{% capture cmd2 %} -mkdir "Includes ' quote" && \ - cd "Includes ' quote" && \ - make -f ../Makefile test -{% endcapture %} -{% capture out2 %} -Includes ' quote -Composite value - Simple value - Includes ' quote -{% endcapture %} - -{% capture cmd3 %} -mkdir 'Maybe a comment #' && \ - cd 'Maybe a comment #' && \ - make -f ../Makefile test -{% endcapture %} -{% capture out3 %} -Maybe a comment # -Composite value - Simple value - Maybe a comment # -{% endcapture %} - -{% capture cmd4 %} -mkdir 'Variable ${reference}' && \ - cd 'Variable ${reference}' && \ - make -f ../Makefile test -{% endcapture %} -{% capture out4 %} -Variable ${reference} -Composite value - Simple value - Variable ${reference} -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 out=out2 %} -{% include jekyll-theme/shell.html cmd=cmd3 out=out3 %} -{% include jekyll-theme/shell.html cmd=cmd4 out=out4 %} - -Environment variables ---------------------- - -Makefiles often have parameters that modify their behaviour. -The most common example is doing something like `make install -PREFIX=/somewhere/else`, where the `PREFIX` argument overrides the default -value "/usr/local". -These parameters are often defined in a Makefile like this: - -``` -param_name ?= Default value -``` - -They should be `escape`d and quoted when passed to external commands, of -course. -However, things get complicated when they contain dollar signs `$`. -`make` variables may contain references to other variables, and they're -expanded recursively either when defined (for `:=` assignments) or when used -(in all other cases, including `?=`). - -{% capture out1 %} -# Prologue goes here... - -escape = $(subst ','\'',$(1)) - -test_var ?= This is safe. -export test_var - -.PHONY: test -test: - @printf '%s\n' '$(call escape,$(test_var))' - @printf '%s\n' "$$test_var" -{% endcapture %} - -{% capture cmd2 %} -test_var='Variable ${reference}' make test -{% endcapture %} -{% capture out2 %} -Makefile:15: warning: undefined variable 'reference' -Variable -Variable ${reference} -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 out=out2 %} - -Here, `$(test_var)` is expanded recursively, substituting an empty string for -the `${reference}` part. -One attempt to solve this is to escape the dollar sign in the variable value, -but that breaks the `"$$test_var"` case: - -{% capture cmd1 %} -test_var='Variable $${reference}' make test -{% endcapture %} -{% capture out1 %} -Variable ${reference} -Variable $${reference} -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 out=out1 %} - -A working solution would be to use the `escape` function on the unexpanded -variable value. -Turns out, you can do just that using the `value` function in `make`. - -{% capture out1 %} -# Prologue goes here... - -escape = $(subst ','\'',$(1)) - -test_var ?= This is safe. -test_var := $(value test_var) -export test_var - -.PHONY: test -test: - @printf '%s\n' '$(call escape,$(test_var))' - @printf '%s\n' "$$test_var" -{% endcapture %} - -{% capture cmd2 %} -test_var="Quote '"' and variable ${reference}' make test -{% endcapture %} -{% capture out2 %} -Quote ' and variable ${reference} -Quote ' and variable ${reference} -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd=cmd2 out=out2 %} - -This doesn't quite work though when [overriding variables] on the command line. -For example, this doesn't work: - -[overriding variables]: https://www.gnu.org/software/make/manual/html_node/Overriding.html#Overriding - -{% capture cmd1 %} -make test test_var='Variable ${reference}' -{% endcapture %} -{% capture out1 %} -Makefile:16: warning: undefined variable 'reference' -make: warning: undefined variable 'reference' -Variable -Variable -{% endcapture %} - -{% include jekyll-theme/shell.html cmd=cmd1 out=out1 %} - -This is because `make` ignores all assignments to `test_var` if it's overridden -on the command line (including `test_var := $(value test_var)`). - -This can be fixed using the `override` directive for these cases only. -A complete solution that works for seemingly all cases looks like something -along these lines: - -``` -ifeq ($(origin test_var),environment) - test_var := $(value test_var) -endif -ifeq ($(origin test_var),environment override) - test_var := $(value test_var) -endif -ifeq ($(origin test_var),command line) - override test_var := $(value test_var) -endif -``` - -Here, we check where the value of `test_var` comes from using the `origin` -function. -If it was defined in the environment (the `environment` and `environment -override` cases), its value is prevented from being expanded using the `value` -function. -If it was overridden on the command line (the `command line` case), the -`override` directive is used so that the unexpanded value actually gets -assigned. - -The snippet above can be generalized by defining a custom function that -produces the required `make` code, and then calling `eval`. - -``` -define noexpand -ifeq ($$(origin $(1)),environment) - $(1) := $$(value $(1)) -endif -ifeq ($$(origin $(1)),environment override) - $(1) := $$(value $(1)) -endif -ifeq ($$(origin $(1)),command line) - override $(1) := $$(value $(1)) -endif -endef - -test_var ?= This is safe. - -$(eval $(call noexpand,test_var)) -``` - -I couldn't find a case where the combination of `escape` and `noexpand` -wouldn't work. -You can even safely use other variable as the default value of `test_var`, and -it works: - -{% capture out1 %} -# Prologue goes here... - -escape = $(subst ','\'',$(1)) - -define noexpand -ifeq ($$(origin $(1)),environment) - $(1) := $$(value $(1)) -endif -ifeq ($$(origin $(1)),environment override) - $(1) := $$(value $(1)) -endif -ifeq ($$(origin $(1)),command line) - override $(1) := $$(value $(1)) -endif -endef - -simple_var := Simple value - -test_var ?= $(simple_var) in test_var -$(eval $(call noexpand,test_var)) - -simple_var := New simple value -composite_var := Composite value - $(simple_var) - $(test_var) - -.PHONY: test -test: - @printf '%s\n' '$(call escape,$(test_var))' - @printf '%s\n' '$(call escape,$(composite_var))' -{% endcapture %} - -{% capture out2 %} -New simple value in test_var -Composite value - New simple value - New simple value in test_var -{% endcapture %} - -{% capture cmd3 %} -make test test_var='Variable ${reference}' -{% endcapture %} -{% capture out3 %} -Variable ${reference} -Composite value - New simple value - Variable ${reference} -{% endcapture %} - -{% capture cmd4 %} -test_var='Variable ${reference}' make test -{% endcapture %} -{% capture out4 %} -Variable ${reference} -Composite value - New simple value - Variable ${reference} -{% endcapture %} - -{% include jekyll-theme/shell.html cmd='cat Makefile' out=out1 %} -{% include jekyll-theme/shell.html cmd='make test' out=out2 %} -{% include jekyll-theme/shell.html cmd=cmd3 out=out3 %} -{% include jekyll-theme/shell.html cmd=cmd4 out=out4 %} diff --git a/_posts/2021-03-10-ubuntu-packaging.md b/_posts/2021-03-10-ubuntu-packaging.md deleted file mode 100644 index ad94f2a..0000000 --- a/_posts/2021-03-10-ubuntu-packaging.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: Basic Ubuntu packaging -snippets_root_directory: snippets/ubuntu_packaging -snippets_language: plain -snippets: - basic: - - basic/changelog - - basic/control - - basic/copyright - - basic/rules - install: - - install/test.install - gbp: - - gbp/gbp.conf ---- -It took me about an hour to make a PKGBUILD for my simple, non-compiled -piece of software to be published on [AUR]. -In contrast, it took me a few days to figure out how to build suitable .deb -packages for publishing in a PPA on [Launchpad]. -In this post, I'll try to describe some of the initial pain points of mine. - -[AUR]: https://aur.archlinux.org/ -[Launchpad]: https://launchpad.net/ - -Basics ------- - -The Debian package format is really old, and it shows. -There's a billion of metadata files to take care of, and barely any suitable -tutorials for beginners. -At best, you'll learn how to build _binary_ packages, not suitable for -publishing in a PPA (which only accept _source_ packages and builds the -binaries itself). - -First, you need to realize that there are source packages and binary packages. -Binary packages are the .deb files that actually contain the software. -A source package is, confusingly, multiple files, and you need to submit them -all to Launchpad. -You can distribute binary packages directly to your users, but they would have -to fetch & install the new version manually every time there's an upgrade. -If you could set up a repository and just point the users to it, they would get -the new versions naturally via the package manager (`apt`). - -Canonical's Launchpad provides a very handy PPA (Personal Package Archive) -service so that anyone can set up a repository. -Users could then use `add-apt-repository ppa:...` and get the packages in a -standard and convenient way. - -Tools ------ - -There's a myriad of tools to build and maintain Debian packages. -The [Debian New Maintainers' Guide] provides a [short summary] of how these -tools interact. -This tutorial assumes that your software lives in a Git repository and you'd -like to use Git to maintain the packaging metadata in the same repository. -This process is greatly aided by the [git-buildpackage] tool. -We still need to install a bunch of other stuff though; the complete command -line to install the required tools would be something like - -{% include jekyll-theme/shell.html cmd='sudo apt install -y build-essential devscripts dh-make git-buildpackage' %} - -Many of the tools pick up particular metadata (like the maintainer name and -email address) from environment variables. -You can put something like - - export DEBFULLNAME='John Doe' - export DEBEMAIL='John.Doe@example.com' - -in your .bashrc to set them globally. - -[Debian New Maintainers' Guide]: https://www.debian.org/doc/manuals/maint-guide -[short summary]: https://www.debian.org/doc/manuals/maint-guide/build.en.html#hierarchy -[git-buildpackage]: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html - -Getting started ---------------- - -Let's create a repository to try things out. -It'll contain a single executable shell script test.sh, which only outputs the -string "test". - -{% include jekyll-theme/shell.html cmd='mkdir test' %} -{% include jekyll-theme/shell.html cmd='cd test' %} -{% include jekyll-theme/shell.html cmd='git init' %} - -{% capture cmd1 %} -cat <<'EOF' > test.sh -#!/usr/bin/env bash -echo test -EOF -{% endcapture %} -{% include jekyll-theme/shell.html cmd=cmd1 %} - -{% include jekyll-theme/shell.html cmd='chmod +x test.sh' %} -{% include jekyll-theme/shell.html cmd='git add .' %} -{% include jekyll-theme/shell.html cmd='git commit -m \'initial commit\'' %} - -This is going to be version 1.0 of our project, let's tag it as such. - -{% include jekyll-theme/shell.html cmd='git tag -a -m \'Release 1.0\' v1.0' %} - -All of the Debian packaging tools are tailored to the following use-case. - -1. There's an upstream distribution, which releases the software in tarballs. -2. There's a maintainer (who's not the software author), who takes care of -packaging and is disconnected from the development. - -This disconnect means that maintaining the Debian packaging files in the -`master` branch is inconvenient using the existing tools. -At the very least, you should create a separate branch for doing packaging -work. - -In addition, Debian (and hence, Ubuntu) is not a rolling-release distribution. -That means that there're regular releases, and the software version shouldn't -change too much during a lifetime of a single release. -Once Debian makes a release, the software version is more or less fixed, and -security fixes from future versions should be backported separately for each of -the supported Debian/Ubuntu releases. - -Except there _is_ a rolling-release distribution of Debian, and it's called -"unstable" or "sid". -The bleeding-edge packaging work should target the "unstable" distribution. - -So, let's create a new branch `debian` for our packaging work: - -{% include jekyll-theme/shell.html cmd='git checkout -b debian' %} - -All the packaging tools assume there's a separate folder "debian" that contains -the package metadata files. -There's a handy tool `dh_make` that creates the directory and populates it with -a number of template metadata files. -Using it is not so simple though. -First of all, it assumes that there's a properly named tarball with the project -sources available in the parent directory. -Why? -Who knows. -Let's create said tarball: - -{% include jekyll-theme/shell.html cmd='git archive --format=tar --prefix=test_1.0/ v1.0 | gzip -c > ../test_1.0.orig.tar.gz' %} - -The tarball name should follow the NAME_VERSION.orig.tar.gz pattern exactly! -Anyway, now is the time to run `dh_make`: - -{% include jekyll-theme/shell.html cmd='dh_make --indep --copyright mit --packagename test_1.0 --yes' %} - -I'm using the MIT License for our little script, hence the `--copyright mit` -argument. -In addition, every package in Debian is either "single", "arch-independent", -"library" or "python". -I'm not sure what the exact differences between those are, but a shell script -is clearly CPU architecture-independent, hence the `--indep` argument. -If it was a compiled executable, it would be a "single" (`--single`) package. - -`dh_make` created the "debian" directory for us, filled with all kinds of -files. -The only required ones are "changelog", "control", "source", "rules" and the -"source" directory. -Let's remove every other file for now: - -{% include jekyll-theme/shell.html cmd='rm -f -- debian/*.ex debian/*.EX debian/README.* debian/*.docs' %} - -You can study the exact format of the metadata files in the [Debian New -Maintainers' Guide], but for now let's keep it simple: - -{% include jekyll-theme/snippets/section.html section_id='basic' %} - -The "control" and "copyright" files are fairly straighforward. -The "changelog" file has a strict format and is supposed to be maintained using -the `dch` tool (luckily, git-buildpackage helps with that; more on that later). - -The "rules" file is an _executable_ Makefile, and actually controls how the -software is built. -Building a package involves invoking many predefined targets in this Makefile; -for now, we'll resort to delegating everything to the `dh` tool. -It's the Debhelper tool; it's a magic set of scripts that contain an -unbelievable amount of hidden logic that's supposed to aid package maintainers -in building the software. -For example, if the package is supposed to be built using the standard -`./configure && make && make install` sequence, it'll do this automatically. -If it's a Python package with setup.py, it'll use the Python package-building -utilities, etc. -We don't want any of that, we just want to copy test.sh to /usr/bin. -It can be taken care of using the `dh_install` script. -While building the package, it'll get executed by `dh`, read the -"debian/test.install" file and copy the files listed there to the specified -directories. -Our test.install should look like this: - -{% include jekyll-theme/snippets/section.html section_id='install' %} - -At this point, we can actually build a proper Debian package! - -{% include jekyll-theme/shell.html cmd='dpkg-buildpackage -uc -us' %} - -This command will generate a bunch of files in the parent directory. -The one of interest to us is "test_1.0-1_all.deb". -We can install it using `dpkg`: - -{% include jekyll-theme/shell.html cmd='sudo dpkg -i ../test_1.0-1_all.deb' %} - -We can now execute `test.sh`, and it'll hopefully print the string "test". - -This .deb file can be distributed to other users, but is no good for uploading -to Launchpad. -For one, it's a binary package, and we need source packages for Launchpad to -build itself. -Second, it's unsigned, which is also a no-no. - -I'm not going to describe how to set up a GnuPG key and upload it to the Ubuntu -keyserver (keyserver.ubuntu.com), but it's pretty straightforward once you know -the basics of GnuPG key handling. - -One disadvantage of the `dpkg-buildpackage` tool is that it creates a lot of -files in the "debian" directory; their purpose is unclear to me. -For now, you can delete them, leaving only the original "changelog", "control", -"copyright", "rules", "test.install" and the "source" directory. - -git-buildpackage ----------------- - -git-buildpackage is a wonderful tool that helps with managing the packaging -work in the upstream repository. -Please refer to its manual to learn how to use it properly. -We need to configure it so that it knows how the release tags look like -(`vVERSION`), how the packaging branch is called (`debian`) and where to put -the generated files. -Create "debian/gbp.conf" with the following contents: - -{% include jekyll-theme/snippets/section.html section_id='gbp' %} - -One unclear line here is `pristine-tar = False`. -It turns out, a lot of Debian package maintainers use the `pristine-tar` tool -to create "pristine", byte-for-byte reproducible tarballs of the upstream -software. -This is just more headache for us, so we're not going to use that; -git-buildpackage will just use the normal `git archive` to create tarballs. - -First, commit the packaging work we just made: - -{% include jekyll-theme/shell.html cmd='git add debian/' %} -{% include jekyll-theme/shell.html cmd='git commit -m \'initial Debian release\'' %} - -We can now build the package using git-buildpackage: - -{% include jekyll-theme/shell.html cmd='gbp buildpackage' %} - -The tool will try to sign the packages, so this assumes that you have your -GnuPG key set up! - -If all went right, it just built the packages in the ../build-area directory. -And it hasn't crapped all over the working directory too! -Similar to `dpkg-buildpackage`, it builds binary packages by default. -To build _source_ packages, it needs to be invoked with the `-S` argument: - -{% include jekyll-theme/shell.html cmd='gbp buildpackage -S' %} - -It'll build the source package in the same directory (you'll notice a lot of -files having the "_source" suffix). -If all is well, we can tag the packaging work we've just completed: - -{% include jekyll-theme/shell.html cmd='gbp buildpackage --git-tag-only' %} - -This will create the `debian/1.0-1` tag in the repository. - -We are now ready to upload the source package to Launchpad. -It's done using the `dput` tool. -The naive way would fail: - -{% include jekyll-theme/shell.html cmd='dput ppa:john-doe/test ../build-area/test_1.0-1_source.changes' %} - -This is due to the fact that we've specified that we're targetting the -"unstable" distribution in debian/changelog. -There's no "unstable" distribution of Ubuntu though; we need to manually -specify the minimal-supported version (e.g. "bionic"): - -{% include jekyll-theme/shell.html cmd='dput ppa:john-doe/test/ubuntu/bionic ../build-area/test_1.0-1_source.changes' %} - -What about other distributions? -Well, if the binary package doesn't need recompiling, we can use Launchpad's -"Copy packages" feature; this is well-described in this [Ask Ubuntu question]. - -[Ask Ubuntu question]: https://askubuntu.com/q/23227/844205 - -New versions ------------- - -When a new version is released, git-buildpackage helps to integrate it to the -packaging branch. -Let's say the new version is tagged `v1.1`: - -{% include jekyll-theme/shell.html cmd='git checkout debian' %} -{% include jekyll-theme/shell.html cmd='git merge v1.1' %} -{% include jekyll-theme/shell.html cmd='gbp dch' %} - -The above command will update debian/changelog; modify it manually to target -the usual "unstable" distribution instead of "UNRELEASED" and update the -version to something like "1.1-1". - -{% include jekyll-theme/shell.html cmd='git add debian/' %} -{% include jekyll-theme/shell.html cmd='git commit -m \'Debian release 1.1\'' %} -{% include jekyll-theme/shell.html cmd='gbp buildpackage -S' %} - -This will build the source package for the new version in the ../build-area -directory; you can then upload it Launchpad and copy the built binary packages. - -Aftermath ---------- - -This fucking sucks. -What's the way to sanely manage the repository if the build/runtime -dependencies are different for different Ubuntu versions? -I have no idea. -Some pointers to help you understand what's going on in this tutorial more -deeply: - -* [When upstream uses Git: Building Debian Packages with git-buildpackage](https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html) -* [Using Git for Debian packaging](https://www.eyrie.org/~eagle/notes/debian/git.html) - -Good luck with this, because I'm definitely overwhelmed. diff --git a/_posts/2022-09-07-gdb-sleep-all.md b/_posts/2022-09-07-gdb-sleep-all.md deleted file mode 100644 index a575afd..0000000 --- a/_posts/2022-09-07-gdb-sleep-all.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Pause all userspace processes -snippets_root_directory: snippets/gdb_sleep_all -snippets_language: bash -snippets: - main: - - gdb_sleep_all.sh - gdb: - - sleep.gdb ---- -If you need to debug some kind of monitoring system (or just have some fun), -you might want to pause all userspace processes for a certain number of seconds -(to measure delays, etc.). - -You can easily do this using GDB like this: - -{% include jekyll-theme/snippets/section.html section_id='main' %} - -sleep.gdb is a very simple GDB script; it basically sleeps for a determined -amount of seconds: - -{% include jekyll-theme/snippets/section.html section_id='gdb' %} - -You can simply run - - sudo ./gdb_sleep_all.sh - -and all of your userspace processes should be frozen for 30 seconds. - -On a couple of servers, this worked quite well; not so well on my laptop with -Xfce installed. -Obviously, this would require a bit of work to adapt for containers as well. -Otherwise, pretty neat, huh? diff --git a/_posts/2022-11-07-ptrace-sigtraps.md b/_posts/2022-11-07-ptrace-sigtraps.md deleted file mode 100644 index 2f42a81..0000000 --- a/_posts/2022-11-07-ptrace-sigtraps.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: 'Fun with ptrace: SIGTRAPs galore' -date: 2022-11-07 13:00 +0100 ---- -When using `PTRACE_ATTACH` the `ptrace` mechanism reuses SIGTRAP for a number -of things by default. -This makes it unnecessarily hard to distinguish regular traps (possibly caused -by breakpoints we might place) from other events. - -1. After `ptrace(PTRACE_SYSCALL)`, syscall-stops will be reported as SIGTRAPs. - - ```c - int status; - - ptrace(PTRACE_SYSCALL, pid, 0, 0); - waitpid(pid, &status, 0); - - if (WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP) { - /* We don't know if the tracee has just entered/exited a syscall or - * received a regular SIGTRAP (could be caused by a breakpoint we - * placed). */ - } - ``` - - This is fixed by using the `PTRACE_O_TRACESYSGOOD` option. - - ```c - int status; - - ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_TRACESYSGOOD); - ptrace(PTRACE_SYSCALL, pid, 0, 0); - waitpid(pid, &status, 0); - - if (WIFSTOPPED(status) && WSTOPSIG(status) == (SIGTRAP | 0x80)) { - /* We know for sure that the tracee has just entered/exited a - * syscall. */ - } - ``` - -2. Every `execve` call will be reported as a SIGTRAP. - - ```c - int status; - - ptrace(PTRACE_CONT, pid, 0, 0); - waitpid(pid, &status, 0); - - if (WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP) { - /* We don't know if the tracee just called execve() or received a - * regular SIGTRAP (could be caused by a breakpoint we placed). */ - } - ``` - - This is fixed by using the `PTRACE_O_TRACEEXEC` option. - - ```c - int status; - - ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_TRACEEXEC); - ptrace(PTRACE_CONT, pid, 0, 0); - waitpid(pid, &status, 0); - - if (WIFSTOPPED(status) && status >> 8 == (SIGTRAP | PTRACE_EVENT_EXEC << 8)) { - /* We know for sure that the tracee has just called execve(). */ - } - ``` - - This point doesn't apply to tracees attached using `PTRACE_SEIZE`. - {: .alert .alert-info } - -As you can see, you should always use at least the `PTRACE_O_TRACESYSGOOD` and -`PTRACE_O_TRACEEXEC` options to be able to distinguish between SIGTRAPs. diff --git a/_posts/2022-11-07-ptrace-waitpid.md b/_posts/2022-11-07-ptrace-waitpid.md deleted file mode 100644 index b5f34fa..0000000 --- a/_posts/2022-11-07-ptrace-waitpid.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: 'Fun with ptrace: a waitpid pitfall' -date: 2022-11-07 12:00 +0100 ---- -When tracing a process using `ptrace`, one often uses the `waitpid` system call -to wait until something happens to the tracee. -It often goes like this (error handling is omitted for brevity): - -```c -/* We have previously attached to tracee `pid`. */ - -int status; - -waitpid(pid, &status, 0); - -if (WIFEXITED(status)) { - /* Tracee has exited. */ -} -if (WIFSIGNALED(status)) { - /* Tracee was killed by a signal. */ -} -/* Tracee was stopped by a signal WSTOPSIG(status). */ -``` - -What if a single thread is attached to multiple tracees? -Then we can use `-1` as the first argument to `waitpid`, and it will wait for -any child to change state. - -```c -int status; -pid_t pid = waitpid(-1, &status, __WALL); -``` - -What's little known, however, is that `waitpid(-1)` will by default consume -status changes from other thread's children. -So if you have two tracer threads A and B, and each of them is attached to a -tracee, then thread A might consume thread B's tracee status change by calling -`waitpid(-1)`. -Therefore, thread A would have thread B's tracee status. -A typical application could be completely unprepared for this scenario. - -To avoid that, use the `__WNOTHREAD` flag. -That way, thread A will only consume status changes from its own children only. - -```c -int status; -pid_t pid = waitpid(-1, &status, __WALL | __WNOTHREAD); -``` - -In my opinion, `__WNOTHREAD` should often be a default in well-structured -applications. diff --git a/_posts/snippets/gdb_sleep_all/gdb_sleep_all.sh b/_posts/snippets/gdb_sleep_all/gdb_sleep_all.sh deleted file mode 100755 index e923740..0000000 --- a/_posts/snippets/gdb_sleep_all/gdb_sleep_all.sh +++ /dev/null @@ -1,17 +0,0 @@ -#!/usr/bin/env bash - -set -o errexit -o nounset -o pipefail - -# Select all process IDs that are _not_ children of PID 2, [kthreadd]. -pids="$( ps -o pid --no-headers --ppid 2 -p 2 --deselect )" - -for pid in $pids; do - cmdline="$( cat "/proc/$pid/cmdline" | tr '\0' ' ' )" || continue - echo ------------------------------------------------------------------ - echo "PID: $pid" - echo "Command line: $cmdline" - echo ------------------------------------------------------------------ - gdb -p "$pid" -x sleep.gdb -batch & -done - -wait diff --git a/_posts/snippets/gdb_sleep_all/sleep.gdb b/_posts/snippets/gdb_sleep_all/sleep.gdb deleted file mode 100644 index 6b8f268..0000000 --- a/_posts/snippets/gdb_sleep_all/sleep.gdb +++ /dev/null @@ -1,2 +0,0 @@ -shell sleep 10 -quit diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/shared.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/shared.hpp deleted file mode 100644 index 796ea85..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/shared.hpp +++ /dev/null @@ -1,6 +0,0 @@ -#pragma once - -inline int shared() { - static int n = 0; - return ++n; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/another.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/another.cpp deleted file mode 100644 index 330ba80..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/another.cpp +++ /dev/null @@ -1,11 +0,0 @@ -#include "another.hpp" - -#include <iostream> - -inline void shared() { - std::cout << "another.cpp: shared()\n"; -} - -void another() { - shared(); -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/another.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/another.hpp deleted file mode 100644 index 9c26d3f..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/another.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -void another(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/main.cpp deleted file mode 100644 index e278b9f..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/inline/weird/main.cpp +++ /dev/null @@ -1,13 +0,0 @@ -#include "another.hpp" - -#include <iostream> - -inline void shared() { - std::cout << "main.cpp: shared()\n"; -} - -int main() { - shared(); - another(); - return 0; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/another.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/another.cpp deleted file mode 100644 index f13b3a1..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/another.cpp +++ /dev/null @@ -1,6 +0,0 @@ -#include "another.hpp" -#include "shared.hpp" - -void another() { - Test test; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/another.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/another.hpp deleted file mode 100644 index 9c26d3f..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/another.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -void another(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/main.cpp deleted file mode 100644 index b3118c1..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/main.cpp +++ /dev/null @@ -1,8 +0,0 @@ -#include "another.hpp" -#include "shared.hpp" - -int main() { - Test test; - another(); - return 0; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/shared.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/shared.hpp deleted file mode 100644 index ef4da34..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/separate_method_definitions/shared.hpp +++ /dev/null @@ -1,12 +0,0 @@ -#pragma once - -#include <iostream> - -struct Test { - Test(); -}; - -inline Test::Test() { - static int x = 0; - std::cout << ++x << '\n'; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/main.cpp deleted file mode 100644 index fde1a43..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/main.cpp +++ /dev/null @@ -1,10 +0,0 @@ -#include "proxy.hpp" -#include "shared.hpp" - -#include <iostream> - -int main() { - std::cout << shared() << '\n'; - std::cout << proxy() << '\n'; - return 0; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/proxy.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/proxy.cpp deleted file mode 100644 index 78e4611..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/proxy.cpp +++ /dev/null @@ -1,6 +0,0 @@ -#include "proxy.hpp" -#include "shared.hpp" - -int proxy() { - return shared(); -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/proxy.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/proxy.hpp deleted file mode 100644 index 7dfc52a..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/proxy.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -int proxy(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/shared.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/shared.hpp deleted file mode 100644 index 647f49e..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static/shared.hpp +++ /dev/null @@ -1,6 +0,0 @@ -#pragma once - -static int shared() { - static int n = 0; - return ++n; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/main.cpp deleted file mode 100644 index fde1a43..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/main.cpp +++ /dev/null @@ -1,10 +0,0 @@ -#include "proxy.hpp" -#include "shared.hpp" - -#include <iostream> - -int main() { - std::cout << shared() << '\n'; - std::cout << proxy() << '\n'; - return 0; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/proxy.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/proxy.cpp deleted file mode 100644 index 78e4611..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/proxy.cpp +++ /dev/null @@ -1,6 +0,0 @@ -#include "proxy.hpp" -#include "shared.hpp" - -int proxy() { - return shared(); -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/proxy.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/proxy.hpp deleted file mode 100644 index 7dfc52a..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/proxy.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -int proxy(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/shared.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/shared.hpp deleted file mode 100644 index 28de441..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/static_and_inline/shared.hpp +++ /dev/null @@ -1,6 +0,0 @@ -#pragma once - -static inline int shared() { - static int x = 0; - return ++x; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/main.cpp deleted file mode 100644 index fde1a43..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/main.cpp +++ /dev/null @@ -1,10 +0,0 @@ -#include "proxy.hpp" -#include "shared.hpp" - -#include <iostream> - -int main() { - std::cout << shared() << '\n'; - std::cout << proxy() << '\n'; - return 0; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/proxy.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/proxy.cpp deleted file mode 100644 index 78e4611..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/proxy.cpp +++ /dev/null @@ -1,6 +0,0 @@ -#include "proxy.hpp" -#include "shared.hpp" - -int proxy() { - return shared(); -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/proxy.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/proxy.hpp deleted file mode 100644 index 7dfc52a..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/proxy.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -int proxy(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/shared.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/shared.hpp deleted file mode 100644 index e21a00c..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespace_and_inline/shared.hpp +++ /dev/null @@ -1,10 +0,0 @@ -#pragma once - -namespace { - -inline int shared() { - static int x = 0; - return ++x; -} - -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/another.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/another.cpp deleted file mode 100644 index cc7556d..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/another.cpp +++ /dev/null @@ -1,19 +0,0 @@ -#include "another.hpp" - -#include <iostream> - -namespace { - -struct Test { - Test() { - std::cout << "another.cpp: Test::Test()\n"; - } - - float y = 1.; -}; - -} - -void another() { - Test test; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/another.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/another.hpp deleted file mode 100644 index 9c26d3f..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/another.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -void another(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/main.cpp deleted file mode 100644 index e383ded..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/ok/main.cpp +++ /dev/null @@ -1,22 +0,0 @@ -#include "another.hpp" - -#include <iostream> - -namespace { - -struct Test { - Test() { - std::cout << "main.cpp: Test::Test()\n"; - } - - int x = 1; -}; - -} - -int main() { - Test test; - std::cout << test.x << '\n'; - another(); - return 0; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/another.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/another.cpp deleted file mode 100644 index 0e0bff9..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/another.cpp +++ /dev/null @@ -1,15 +0,0 @@ -#include "another.hpp" - -#include <iostream> - -struct Test { - Test() { - std::cout << "another.cpp: Test::Test()\n"; - } - - float y = 1.; -}; - -void another() { - Test test; -} diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/another.hpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/another.hpp deleted file mode 100644 index 9c26d3f..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/another.hpp +++ /dev/null @@ -1,3 +0,0 @@ -#pragma once - -void another(); diff --git a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/main.cpp b/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/main.cpp deleted file mode 100644 index abd42b7..0000000 --- a/_posts/snippets/static_vs_inline_vs_unnamed_namespaces/unnamed_namespaces/weird/main.cpp +++ /dev/null @@ -1,18 +0,0 @@ -#include "another.hpp" - -#include <iostream> - -struct Test { - Test() { - std::cout << "main.cpp: Test::Test()\n"; - } - - int x = 1; -}; - -int main() { - Test test; - std::cout << test.x << '\n'; - another(); - return 0; -} diff --git a/_posts/snippets/ubuntu_packaging/basic/changelog b/_posts/snippets/ubuntu_packaging/basic/changelog deleted file mode 100644 index 6b7131e..0000000 --- a/_posts/snippets/ubuntu_packaging/basic/changelog +++ /dev/null @@ -1,5 +0,0 @@ -test (1.0-1) unstable; urgency=medium - - * Initial release. - - -- John Doe <John.Doe@example.com> Wed, 10 Mar 2021 16:15:19 +0000 diff --git a/_posts/snippets/ubuntu_packaging/basic/control b/_posts/snippets/ubuntu_packaging/basic/control deleted file mode 100644 index 55f8252..0000000 --- a/_posts/snippets/ubuntu_packaging/basic/control +++ /dev/null @@ -1,13 +0,0 @@ -Source: test -Section: utils -Priority: optional -Maintainer: John Doe <John.Doe@example.com> -Build-Depends: debhelper-compat (= 12) -Standards-Version: 4.4.1 -Homepage: https://example.com/test - -Package: test -Architecture: all -Depends: ${misc:Depends} -Description: This is a test package. - This is a test package, just trying out Debian packaging. diff --git a/_posts/snippets/ubuntu_packaging/basic/copyright b/_posts/snippets/ubuntu_packaging/basic/copyright deleted file mode 100644 index 8a67e52..0000000 --- a/_posts/snippets/ubuntu_packaging/basic/copyright +++ /dev/null @@ -1,31 +0,0 @@ -Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -Upstream-Name: test -Upstream-Contact: John Doe <John.Doe@example.com> -Source: https://example.com/test - -Files: * -Copyright: 2021 John Doe <John.Doe@example.com> -License: MIT - -Files: debian/* -Copyright: 2021 John Doe <John.Doe@example.com> -License: MIT - -License: MIT - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - . - The above copyright notice and this permission notice shall be included - in all copies or substantial portions of the Software. - . - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. - IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY - CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, - TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE - SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. diff --git a/_posts/snippets/ubuntu_packaging/basic/rules b/_posts/snippets/ubuntu_packaging/basic/rules deleted file mode 100644 index cbe925d..0000000 --- a/_posts/snippets/ubuntu_packaging/basic/rules +++ /dev/null @@ -1,3 +0,0 @@ -#!/usr/bin/make -f -%: - dh $@ diff --git a/_posts/snippets/ubuntu_packaging/gbp/gbp.conf b/_posts/snippets/ubuntu_packaging/gbp/gbp.conf deleted file mode 100644 index d9f7e5f..0000000 --- a/_posts/snippets/ubuntu_packaging/gbp/gbp.conf +++ /dev/null @@ -1,5 +0,0 @@ -[DEFAULT] -upstream-tag = v%(version)s -debian-branch = debian -pristine-tar = False -export-dir = ../build-area/ diff --git a/_posts/snippets/ubuntu_packaging/install/test.install b/_posts/snippets/ubuntu_packaging/install/test.install deleted file mode 100644 index 6222235..0000000 --- a/_posts/snippets/ubuntu_packaging/install/test.install +++ /dev/null @@ -1 +0,0 @@ -test.sh usr/bin |