C++ Comma Confusion via LightSleeper

Many C++ programmers are surprised by the effects of that little comma. In some cases (e.g. comma operator), the comma very clearly describes the order of operations. In other cases (e.g. function parameter separators), the comma does not describe the order. h() could execute before g() in the last example, and it often does in real compilers. Understanding the difference is well worth your time.

Original Post

awk Search script with prior and following line capability

#!/bin/sh

# *********************************************************

# This uses nawk to list lines coming prior to and after

# the given search string.

# Format: xgrep

# ********************************************************

if [ $# != 4 ]

then

echo "Usage: $0 "

exit

fi

STR=$1

BEF=$2

AFT=$3

while [ ! -z "$4" ] ; do

echo ========== $4

nawk 'c-->0{print NR ":\t" $0;};$0~s{if(b)for(c=b+1;c>1;c--) print (NR-c + 1) ":\t" r[(NR-c+1)%b];print NR ":\t" $0;c=a}b{r[NR%b]=$0;}' b=$BEF a=$AFT s=$STR $4 | sed "s/^/$4\

/"

shift

done

echo ==========

Took me a while to understand how awk worked and customized the command I found on the net for my own needs.

sed and Nix Quotation Confusion

I wanted to use "sed" inside a script to make changes to a text file. The file looked like this:

/*

** Project "OrderCache.7.7.29"

** Hint: deleting everything below the "cause" field will set

** the defaults appropriately for the cause you have chosen.

*/

brief_description = "none";

description = "none";

cause = internal_bug;

test_exempt = true;

test_baseline_exempt = true;

regression_test_exempt = true;

architecture =

[

"unspecified",

];

I wanted to replace the "brief_description" with a value given by the user. So:

#!/bin/csh

set DESC = "$<"

But when I tried to use sed with $DESC:

sed -i 's%brief_description\ \=\ \"none\"\;%brief_description\ \=\ \"$DESC\"\;%g' temp_next.txt

the command would only change "brief_description" as follows:

brief_description = "$DESC";

The reason for this is that the variable has to be inside double quotes in order to get it dereferenced back to the actual value. So the solution is:

sed -i 's%brief_description\ \=\ \"none\"\;%brief_description\ \=\ \"'"$DESC"'\"\;%g' temp_next.txt

posix_spawnp Failure with WEXITSTATUS 127

One problem with posix_spawnp is that if it fails after successfully spawning a new process, the exit status of the spawned process is always 127. This gives us no clue what so ever as to what caused the problem.

I came across this a few days ago and struggled with it for a while before re-writing the code using "fork()" and "execvpe" to achieve the same effect. The "exec" calls also failed but they gave a proper error value (via errno) from which the cause of the error could be found (perror(errno)).

In my case, errno was 14 and the error message said "Bad address" which turned out to be caused by an invalid argument list passed to execvpe. I wasn't terminating the argument list with NULL set as the last element.

Having a better error reporting system in posix_spawnp would have saved me alot of trouble

High precision floating point arithmatic in C++

One of my friens had a need for a floating point type that would allow a precision level upto 9 decimal points. "long double" would have been our choice if not for the differences in implementation and VC++ not supporting it (in VC++, long double = double).

We opted for doubledouble which has a precision level upto 30 decimal points.

Some other options are available here.

Posix Threads and FT Handling

We have a set of stringent FT mechanisms at our company since failure of a single process might spell disaster for the whole system. Threre are multiple instances of the same process running as primary and mirror. And there are multiple "Sets" which hold copies of the whole system so if one set goes down, another could take over.

If a primary process goes down, an "FT_CHANGE" happens and the mirror becomes the primary.

I came across an instance where the mirror process was made to "Fail over" just as it became "Ready" (A process is "Ready" once it finishes the initialization process and sends a message to the controlling system). This has resulted some bizarre behaviour.

After having a look at the logs, we came to the conclusion that this was due to the fact that the process gave the "Ready" signal before some "pthread_create" calls have finished executing. I check the return types of the code but this does not guarantee that the threads are up and running at that moment.

The lesson: Wait till the child thread comes up and sends the main thread an acknowledgement before making any calls to that thread (like we do in most of the other processes)