Is it a 'char' or 'unsigned char' or 'signed char'?

I inherited a overly-loaded code something like this...

void func(boost::int8_t p)
{
std::cout << "boost::int8_t" << std::endl;
}
void func(boost::uint8_t p)
{
std::cout << "boost::uint8_t" << std::endl;
}
void f1(boost::int16_t s)
{
std::cout << "boost::int16_t" << std::endl;
}
void f1(boost::uint16_t s)
{
std::cout << "boost::uint16_t" << std::endl;
}
main()
{
short sh;
char c;
f1(sh);
func(c);
}

I tried to compile the above code but the compiler is refusing to proceed balking at "func(c)", while it is completely happy with f1(sh). For the uninitiated boost types are typedef-ed to the appropriate platform types like int8_t -> signed char uint8_t -> unsigned char.

It turned out that the language does not specify whether variables of type char are signed or unsigned quantities. So the compiler complains about the func(c) call because it is ambiguous. Whereas f1(sh) succeeds.

Changind the "char c" to "unsigned char" or "signed char" resolves the ambiguity and calms down the compiler. Curiously even forcing the compiler with -funsigned-char didn't help in this case.

Well my philosophy of solving any problem by an extra level of indirection also didn't work. I tried something like this...

template
void func_char_resolver(T c);

template<>
void func_char_resolver(boost::int8_t c) { /// dealing with singed char....
}

template<>
void func_char_resolver(boost::uint8_t c) { /// dealing with unsinged char....
}
void func(char c)
{
func_char_resolver(c);
}

I don't know may be because `char' is a distinct type (of undefined sign) hence none of the specializations matched. Oh well!

ssh error in locking authority file!

While ssh-ing to one of my remote machines I got this error and X forwarding kept failing because of thsi.

/usr/bin/X11/xauth: error in locking authority file

Who would have guessed the problem? I'm running out of my disk quota! It is a weird way of warning about quota over run! 'quota -v' did confirm the theory and after killing few MB's the problem indeed go away!

Problems with X11 Composite Extension

When I enabled trancelucency in my KDE the composite manager crashed with the
message asking to insert the following lines in xorg.conf.

Section "Extensions"
Option "Composite" "Enable"
EndSection

And so I did and forgot about it for a week. Last week when I tried to launch
gnucash it wouldn't . It cried something like this.

-------
Gdk-CRITICAL **: file gdkwindow.c: line 1406 (gdk_window_get_visual):
assertion `window != NULL' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 57 (gdk_colormap_new): assertion
`visual != NULL' failed.
SESSION_MANAGER=tcp/pdm1:53739

Gdk-CRITICAL **: file gdkwindow.c: line 1406 (gdk_window_get_visual):
assertion `window != NULL' failed.

Gdk-CRITICAL **: file gdkcolor.c: line 57 (gdk_colormap_new): assertion
`visual != NULL' failed.
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
serial 47 error_code 9 request_code 132 minor_code 5
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
serial 48 error_code 9 request_code 55 minor_code 0
--------

I thought one of yum update screwed it up. So I looked through the recent
update logs and couldn't find anything remotely connected to gnucash , X11,
gdk or my window manager. Frustrated like hell I stopped thinking about this
problem. I couldn't do my accounting for a week!

It wasn't until I tried to launch one more app which failed with the same
exception. I then started digging deep and found that the culprit was the
Composite extension option. So I disabled the following from xorg.conf

#Section "Extensions"
#Option "Composite" "Enable"
#EndSection

and yes I did my accounts immediately!

Kerberos on 64bit Linux with gcc 4.0

I was trying to compile kerberos on a 64 bit linux (CentOS). First I was getting configure errors about res_search(). Then I downloaded the latest and the greatest v5-1.5.1 from mit and tried to compile with gcc version 4.0. First the configure script was using the old compiler. So I need to teach it to use the gcc4. So I did...

export CC=gcc4
export CXX=g++4

After this configure script went fine. But the compilation was producing some errors like the following in the kadmin/test directory.

tcl_ovsec_kadm.c:85: `Tcl_HashEntry' undeclared (first use in this function)
tcl_ovsec_kadm.c:85: (Each undeclared identifier is reported only once
tcl_ovsec_kadm.c:85: for each function it appears in.)
tcl_ovsec_kadm.c:85: `entry' undeclared (first use in this function)
tcl_ovsec_kadm.c:93: warning: implicit declaration of function `Tcl_InitHashTable'
tcl_ovsec_kadm.c:93: `TCL_STRING_KEYS' undeclared (first use in this function)
tcl_ovsec_kadm.c:105: warning: implicit declaration of function`Tcl_CreateHashEntry'
tcl_ovsec_kadm.c:109: warning: implicit declaration of function `Tcl_SetHashValue'

Looks like I'm not alone -> http://mailman.mit.edu/pipermail/kerberos/2004-September/006391.html
So I followed it faitfully like this and everything went fine.

./configure --prefix=/home/test/krb5 --without-tcl