Questions about charset modules
Benjamin.Riefenstahl at epost.de
Sun Oct 5 14:35:27 GMT 2003
> Benjamin Riefenstahl wrote:
>> - I'd like to avoid memory management in these functions as much as
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
> 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,
More information about the samba-technical