ucla.jamesyxu.comRants inside

Skip to content To UCLA we go! An EE Graduate Student's blog About Me Contact Me Log In Categories: Android Arduino Article Bayesian Networks C/C++ idioms Database Debugger Grad school Information iOS Java Linux Living MSP430 Perl Personal Python Qt Rant Technology Uncategorized C++ Idiom: Copy-and-Swap Adapted from this stackoverflow article Copy-and-swap idiom is a elegant solution that performs assignment while avoiding code duplication and strong exception guarantee . Conceptually, it utilizes the object’s copy-constructor to create a local copy of itself, performs assignment to the other object through a swap method and then destroys the other object’s old data when the swapped local copy’s destructor . Through the rule of three , the highlighted components (in bold) should all be present anyway except the swap method. The swap method must be non-throwing function. Notice that std::swap does not qualify as it uses the copy-constructor and assignment operator in its implementation (and we are trying to implement the assignment operator). From this point, see the stackoverflow article for an example Posted in C/C++ , idioms . Tagged with copy swap , copy-and-swap . By James January 5, 2014 Comments Off on C++ Idiom: Copy-and-Swap C++ Idiom: Rule of Three The rule of three idiom says that if a class needs any of: copy constructor assignment operator destructor Then it probably need all of them. The reason for this is that if any of the above is needed then the class likely manages its own resource (allocation/deletion) and this is likely to be needed for all of the actions. Posted in C/C++ , idioms . Tagged with assignment , copy , destructor , idiom , operator , rule of three . By James January 5, 2014 Comments Off on C++ Idiom: Rule of Three C/C++ – Casting int pointer to char pointer There was some interesting discussion around the following code, and I thought I would write it up here. // Part I: int i = 0x01234567; int* pi = &i; char* pc = pi; // Part II: char c = 0x80; int* pi = &c; Now, code in Part I is fine, while code in Part II has a problem. The C standard (C99) maintains that: ints are 4-byte aligned chars are 1-byte aligned data memory are byte addressable casting misaligned pointer types results in undefined operation This means that a char* can address any data (such as an int) while the reverse may not be true. In the particular case above this means that while any int* can be converted to a char* (and back again), a random char* may not be convertible to an int*. Even though an int* can be casted into a char*, notice that for big/little-endians, the byte orders are different so care should be taken when using this type of cast. Now, for a little more depth, why is it that an arbitrary char* cannot be converted into an int*? Most current CPUs are byte-addressable, meaning that each memory address points to an 8-bit block of memory cells. Many CPU instructions that operate on data stored in memory allow the data to have a size larger than 1 byte and would attempt to access the memory to read up to the size of the data type (e.g. 8 byte floating point operations). Data are naturally aligned if the starting address can be expressed as multiples of power of 2. For example 0x8 is aligned to 2,4… ( See here for a full definition ) Some CPUs (x86 for example) can read misaligned data by performing multiple memory accesses and piecing together the data (for example half of the float from 1 access and the other half from another). Many CPUs however (such as MIPS, IA-64 etc) will not read data that are misaligned and any attempt raises a bus error (SIGBUS on POSIX), so if you cast a char* to int* and the start address of the new int* is not aligned, then any 4-byte aligned access to that location fails with bus error. Posted in C/C++ , MSP430 . Tagged with aligned , C , memory access , misaligned . By James January 5, 2014 Comments Off on C/C++ – Casting int pointer to char pointer Fully statically linked Perl – Single executable with all modules, modules fully statically linked also (bundle Crypt::OpenSSL::AES) Recently I had to figure out how to distribute a single Perl that includes Crypt::OpenSSL::AES module that works across multiple Linux distributions and architectures. There are several problems: Perl has dependencies on shared libraries that may not exist on all systems. This is not by itself a huge problem because you can build a single 32 Bit Perl that work on major distributions Crypt::OpenSSL::AES is a thin wrapper for libcrypto and libssl. This means that when you install the module, it is compiled as a shared library. This is a significant problem because OpenSSL is not backward compatible, so you need all of your target machine to have the same version of libcrypto and libssl and built for the same architecture and using same or better version of libc (and other shared libraries). To see the dependencies, use ldd Statically linking the shared library built during installation of Crypt::OpenSSL::AES against libcrypto does solve the 2nd part of the problem but not the first. It also means that you are still bounded by the libc version requirements. After much research, I have found a way to build a fully static (alternatively static perl with dependency only on libc). The method uses App-Staticperl (http://search.cpan.org/~mlehmann/App-Staticperl-1.43/bin/staticperl). Reader should familiarize themselves with the documentation in the link first. Installation: Download and Build OpenSSL , the build require no special configuration parameters. If you need to build OpenSSL in a local directory refer to OpenSSL’s INSTALL file for the configuration flags Patch App-Staticperl. The standard download does not work out of the box due to a script error. Untar App-Staticperl Copy the staticperl.sh into the untarred directory Build perl from source using staticperl by running ‘./staticperl.sh install’, this installs by default Perl 5.12.4 to ~/.staticperl Copy ./mkbundle to ~/.staticperl/bin/SP-mkbundle. This step is required to work around a script error in staticperl.sh that prevents it from generating the mkbundle script Run ./staticperl.sh mkperl, if there are any missing module errors then install the corresponding module from CPAN using ~/.staticperl/bin/perl Build and install CBC::Crypt : Untar Crypt-CBC CD into the new directory and issue: ~/.staticperl/bin/perl Makefile.PL make make install Build and install Crypt::OpenSSL::AES . This require modification to Makefile.PL to statically link in the OpenSSL library built during step 1 Untar Crypt::OpenSSL::AES CD into the new directory and modify the Makefile.PL Comment out LIBS Add path to the build openssl's include dir to INC Add MYEXTLIB => 'POINT TO libcrypto.a FILE' # this gets directly added to the linker Issue commands: ~/.staticperl/bin/perl Makefile.PL make make install Build staticperl, CD into App-Staticperl and issue ./staticperl.sh mkperl --incglob '*' --static A new executable ‘perl’ should be generated in cwd, test this perl by running it against test.pl ./perl ../test.pl 53616c7465645f5f477a787c68a095cb9ba06fb7768140a623a2670aa1c3a4f553d3e64dc16fc5707c6c9a6eac5dcf32 1234567890123456 41f813eca9ddd189f7ff3280ada72c8a 1234567890123456 If the above match then the new single executable perl has been generated successfully Posted in Linux , Perl . Tagged with Crypt::OpenSSL::AES , libcrypto , linux , perl . By James December 21, 2013 Comments Off on Fully statically linked Perl – Single executable with all modules, modules fully statically linked also (bundle Crypt::OpenSSL::AES) printf (or other I/O) on MSP430 and Code Composer 5 Today I came across a funny problem: the following code would not print anything (in Code Composer you are supposed to get a console window that pops up and shows your the STDIO stuff). #include <stdio.h> int main() { printf("Hello!\n"); return 0; } Turns out this is because printf and other I/O functions require a huge stack an...