Hello Andy!
Some questions about the following code:
/**
* Process the VTIMEZONE component during parsing of an iCalendar
*
* @param vtimezone
* Pointer to the iCalendar VTIMEZONE component
* @param appData
* Pointer to the <ApplicationData> element to add parsed elements to
*/
static void _ical2eas_process_vtimezone (icalcomponent* vtimezone, xmlNodePtr
appData)
{
if (vtimezone) {
EasTimeZone timezoneStruct;
icalcomponent* subcomponent = NULL;
gchar* timezoneBase64 = NULL;
// Only one property in a VTIMEZONE: the TZID
icalproperty* tzid = icalcomponent_get_first_property
(vtimezone, ICAL_TZID_PROPERTY);
if (tzid) {
// Get the ASCII value from the iCal
gchar* tzidValue8 = (gchar*)
icalproperty_get_value_as_string (tzid);
// Convert to Unicode, max. 32 chars (including the
trailing 0)
gunichar2* tzidValue16 = g_utf8_to_utf16 (tzidValue8,
31, NULL, NULL, NULL);
// Copy this into the EasTimeZone struct as both
StandardName and DaylightName
2645 =>>> memcpy (& (timezoneStruct.StandardName), tzidValue16,
sizeof (timezoneStruct.StandardName));
memcpy (& (timezoneStruct.DaylightName), tzidValue16,
sizeof (timezoneStruct.DaylightName));
g_free (tzidValue8);
g_free (tzidValue16);
}
// Now process the STANDARD and DAYLIGHT subcomponents
for (subcomponent = icalcomponent_get_first_component
(vtimezone, ICAL_ANY_COMPONENT);
subcomponent;
subcomponent = icalcomponent_get_next_component
(vtimezone, ICAL_ANY_COMPONENT)) {
_ical2eas_process_xstandard_xdaylight (subcomponent,
&timezoneStruct, icalcomponent_isa (subcomponent));
}
Isn't the TZNAME property of the STANDARD and DAYLIGHT subcomponent a
better match for the StandardName and DaylightName?
What drew my attention to this is a valgrind warning:
==26768== Invalid read of size 1
==26768== at 0x4C25F98: memcpy (mc_replace_strmem.c:497)
==26768== by 0x7005CB9: _ical2eas_process_vtimezone
(eas-cal-info-translator.c:2645)
==26768== by 0x7005F11: eas_cal_info_translator_parse_request
(eas-cal-info-translator.c:2709)
==26768== by 0x6FF9603: eas_sync_msg_build_message (eas-sync-msg.c:265)
==26768== by 0x7009E49: eas_add_item_req_Activate (eas-add-item-req.c:207)
==26768== by 0x404304: eas_sync_add_items (eas-sync.c:400)
==26768== by 0x403613:
dbus_glib_marshal_eas_sync_VOID__STRING_UINT64_STRING_STRING_BOXED_POINTER
(eas-sync-stub.h:149)
==26768== by 0x55F29DA: ??? (in /usr/lib/libdbus-glib-1.so.2.1.0)
==26768== by 0x582578D: ??? (in /lib/libdbus-1.so.3.4.0)
==26768== by 0x581930B: dbus_connection_dispatch (in /lib/libdbus-1.so.3.4.0)
==26768== by 0x55EEBB4: ??? (in /usr/lib/libdbus-glib-1.so.2.1.0)
==26768== by 0x6AE5D3B: g_main_dispatch (gmain.c:2500)
==26768== Address 0xf129d6f is not stack'd, malloc'd or (recently) free'd
That's the memcpy(). I suspect it reads past the end of the allocated
string because of the fixed size, although I find it a bit puzzling that
valgrind does report that explicitly - usually it does.
What's the right way to determine the number of bytes to be copied?
strlen() is guaranteed to work for utf-8, but for utf-16 I am not so
sure.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
