9:32 a.m.
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.
10:42 a.m.
On 31/08/2011 14:32, Patrick Ohly wrote:
Isn't the TZNAME property of the STANDARD and DAYLIGHT
subcomponent a
better match for the StandardName and DaylightName?
possibly - I didn't write
this code, so I'm looking at it for the first
time...I'm not sure if Exchange actually stores it, properly anyway - I
think it ends up putting its own strings in there, so not sure if it
actually makes that much difference... might be worht running a couple
of tests
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.
yeah, not sure about that - i seem to remember something about a
mbslen() function/macro for multibyte string lengths , but its not a
standard, so may affect portability, and I don't know about its support
in meego...
3:07 a.m.
On Mi, 2011-08-31 at 15:42 +0100, Andy Gould wrote:
On 31/08/2011 14:32, Patrick Ohly wrote:
> Isn't the TZNAME property of the STANDARD and DAYLIGHT subcomponent a
> better match for the StandardName and DaylightName?
possibly - I didn't write this code, so I'm looking at it for the first
time...I'm not sure if Exchange actually stores it, properly anyway - I
think it ends up putting its own strings in there, so not sure if it
actually makes that much difference... might be worht running a couple
of tests
Indeed, it doesn't seem to matter much. Still, the code should be
correct or get removed if not needed.
One more question: I assume that g_utf8_to_utf16()/gunichar2 use the
native byte ordering. What byte order does ActiveSync specify? We seem
to lack byte-swapping.
--
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.
3:41 a.m.
On 01/09/11 08:07, Patrick Ohly wrote:
Indeed, it doesn't seem to matter much. Still, the code should
be
correct or get removed if not needed.
Again, I'm happy for you to make changes
to it - the mapping of
different schemas was always going to need a couple of passes to get
completely right, especially as we were doing it without a lot of domain
knowledge.
One more question: I assume that g_utf8_to_utf16()/gunichar2 use the
native byte ordering. What byte order does ActiveSync specify? We seem
to lack byte-swapping.
I can't find any documentation that specifies this...
3468
days inactive
3469
days old
syncevolution@synevolution.org
3 comments
2 participants
participants (2)
-
Andy Gould -
Patrick Ohly