Size of fhandler_fifo

[Ken Brown <kbrown@cornell.edu>]

Hi Corinna,

This is a followup to your question on IRC about why fhandler_fifo is so big. 
The main reason is the pipe_name_buf member, which occupies 96 bytes and stores 
the Windows named pipe name.

There's a similar need to store the pipe name for the fhandler_socket_unix 
class.  In that case you used pc.{set,get}_nt_native_path.  But the latter is 
already in use in the fhandler_fifo case, so I can't use that.  I see several 
possible ways to proceed:

0. Do nothing and live with fhandler_fifo being big (736 bytes on 64-bit).

1. Don't store the pipe name; just regenerate it whenever it's needed.

2. Add members to path_conv to handle pipe names, analogous to wide_path and 
uni_path.  This increases the size of path_conv from 336 to 360 on 64-bit (one 
pointer and one UNICODE_STRING).

3. Imitate in fhandler_fifo what's done in path_conv.  So we would replace 
'WCHAR pipe_name_buf[48]' by 'PWCHAR pipe_name_buf' and then malloc space for 
the pipe name.

These all have disadvantages.

#2 increases the size of path_conv for the sake of one class (although 
fhandler_socket_unix could use it too).  #3 requires fhandler_fifo to deal with 
a lot of malloc/free/strdup details that are normally handled by path_conv and 
are hidden from fhandler classes.

Ken