Questions about charset modules

[Benjamin Riefenstahl]

Hi Jelmer,


> Benjamin Riefenstahl wrote:
>> - I'd like to avoid memory management in these functions as much as
>>   possible.

Jelmer Vernooij <jelmer at vernstok.nl> writes:
> I don't think there's a fixed upper length limit of those
> buffers...  Perhaps a construction like the one below would be
> useful to you:
>
> [use realloc()]

Yes, that was plan B ;-). 

>> - The charset functions are called with invalid data from some places,

> They should indeed give an error and ignore those bytes. The code
> that's calling the function just needs to be fixed....

It's not only those bytes.  The OS functions on which I rely, do not
do *any* conversion in this case, even with the bytes before the
actual error.  Is that o.k., or do I need to add code to try and
convert as many bytes as possible?  That would involve doing my own
UTF-8 parsing, and I'd like to avoid that, of course.  It's not
inherently difficult, but it would add a considerable amount of code.

>> - How should the charset module be named?  I currently use
>>   modules/charset_macosxfs.c for the source and macosxfs.dylib for the
>>   binary.
> It should be named bin/charset_macosxfs. at LIBEXT@ while linking and
> should be installed to $SAMBALIBDIR/charset/macosxfs. at LIBEXT@.
>
> (Also see the Makefile rule for the 'weird' charset module and the
> configure.in macros for the 'weird' charset module)

I already use a copy of the Makefile and configure rules as the other
modules do it, and have this well integrated.  It's mostly about the
actual C file name.  Calling a charset module just
"modules/macosxfs.c" seems rather misleading to me (as does
"modules/weird.c", of course).  This module doesn't implement a
filesystem, it doesn't even implement filesystem bindings.  So I'd
prefer "modules/charset_macosxfs.c".  But I didn't want to step on
anybodys toes with introducing a new naming convention.


Thanks for your time,
benny