code style in the vfs

[Roland Illig]

Hi,

I have rewritten a small part of the vfs. I noticed that the function 
_vfs_get_class -- although declared to take a "const char *" cannot be 
fed with a string literal, because it modifies the path. This has led to 
two changes:

1. I extended my private src/global.h (which I will not commit unless 
asked to do it):

#ifdef strchr
#undef strchr
#endif
#define strchr(m_str, m_chr) (const char *) (strchr) (m_str, m_chr)
#define mod_strchr(m_str, m_chr) (strchr) (m_str, m_chr)

The point is that strchr takes a "const char *", but it returns a "char 
*", which can point to the "const char *", effectively discarding the 
"const". Using these definitions I get some more warnings which I will 
fix in the next time. There are many more functions which are declared 
inappropriately, like strchr, and I will try to find them all.

If you agree that there are actually two strchr functions, which could 
be overloaded in C++, perhaps we can discuss if we want to call them 
with distinct names, like I have done in my #defines above. The two 
strchr functions are:

const char *strchr(const char *, int);
char *strchr(char *, int);

2. Many vfs functions make a local copy of a string, change only one 
character and then pass that string to other functions. For example:

     slash = strchr (semi, PATH_SEP);
     if (slash)
         *slash = 0;
     ret = vfs_prefix_to_class (semi + 1);

This pattern requires the massive use of g_strdup, which can be 
annoying, because the string duplicates must be freed later.

My approach has been to change string parameters into two parameters, 
the string and the string_len. This eliminates the need for most of the 
cases like the example above.

So how do you think about it? Is it worth modifying some (mostly 
internal) functions to get to the (string,length) representation of strings?

Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mc-vfs-codingstyle.patch
Type: text/x-patch
Size: 2177 bytes
Desc: not available
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20040924/5827fd58/attachment.bin>