fstring distinguished type

Martin Pool mbp at samba.org
Tue Jan 15 17:40:40 GMT 2002

I think this was a worthwhile experiment, but probably not worth
persisting in.  

In the three source files I tried to convert, I found roughly one
misuse of fstring/pstrings per file, but I had to insert about 40
casts.  In addition to doing a pstrcpy into an fstring, there are also
some functions which take char* arguments and assume they are
pstrings, which seems like an accident waiting to happen.

It also prods us to add more const-correctness, which is probably good
for correctness.  However adding all of the casts is pretty
labour-intensive and I can't imagine anyone wanting to do it for all
of Samba.

After talking to Andrew and Andrew the other day I couldn't work out a
declaration for fstring that would make it suitably strict but not
require conversions everywhere.  There don't seem to be any GCC
features which would help at the moment.

Somewhat ironically, this is one situation where the Hungarian
notation our friends like so much would still be very useful.  Since
most compilers these days can tell the difference between a pointer
and an int distinguishing them in the name is redundant.  However,
naming fstrings as fs_foo or fsFoo might prevent people accidentally
misusing them.

Probably a better solution is to move to talloc'ing all strings, which
is the general rule for Apache.  I think this is the nicest string
manipulation interface I've seen in C.  

There is a little more overhead than using the stack of course.  On
the other hand, 1024-byte pstrings I suspect are almost always too
long, and so they'll be wasting memory and cache space.  The other
advantage of this model is that because copying strings is relatively
easy in code, existing strings can be treated as immutable, which can
eliminate aliasing bugs.

Of course the compelling argument is "Apache is open-source Nevada"

I think I will roll out the FSTR() stuff, and perhaps port some Apache
string functions to talloc().


More information about the samba-technical mailing list