On Wed, Nov 12, 2003 at 11:46:23AM -0800, Josh Coalson wrote: > that's correct; vorbis comments are not c strings and the API > does not expose them as such (you could argue that it should I > guess). they are a length plus a buffer in UTF-8.
A buffer in UTF-8? I thought it was just junk memory - and valgrind
seems to prove this:
==13477== Invalid read of size 1
==13477== at 0x40023F18: strlen (mac_replace_strmem.c:164)
==13477== by 0x80501F9: get_flac(Song*, char const*) (char_traits.h:143)
==13477== by 0x8050F9F: get_artist_title(Song*, std::string, char*)
(basic_string.h:717)
==13477== by 0x804E28C: traverse_dir(char*) (sstream:502)
==13477== Address 0x415CDE5A is 0 bytes after a block of size 22 alloc'd
==13477== at 0x4002CA4D: malloc (vg_replace_malloc.c:153)
==13477== by 0x402AAF1D: FLAC::Metadata::VorbisComment::Entry::parse_field() (in
/usr/lib/libFLAC++.so.2.1.2)
==13477== by 0x8050F9F: get_artist_title(Song*, std::string, char*)
(basic_string.h:717)
==13477== by 0x804E28C: traverse_dir(char*) (sstream:502)
However, the C++ API exposes the field names and values as C strings:
const char *get_field() const;
const char *get_field_name() const;
const char *get_field_value() const;
but there's still junk on the char* i get back from get_field_value().
Should the type be changed to prevent the ambiguity/assumption?
> char str[entry->length+1];
> memcpy(str, entry->entry);
> str[entry->length] = '\0';
That's about the size of what I've been doing.
--
Joshua Kwan
pgp00000.pgp
Description: PGP signature
