ecore_config in CVS head has an error in its handling of ARGB colours.
Currently the ecore_config_typed_val function assumes that colours
are strings, whereas the __ecore_argbstr_to_long means that its
actually a long. Attached is a patch which seems to fix the glitch.
Dylan.
Currently ecore_dlist_append has a bug in that it increments the
list->nodes without considering whether it makes a previously invalid
list->index valid. If this happens, the list has a valid index, and thus
interprets the list->current member as pointing to node data.
Here is code that shows
list->free_func(data);
return TRUE;
}
Dylan Shell.
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and d
I've been messing w/ the Ecore Lists. I've found a simple example of a minor
inconsistency between Ecore_DList and Ecore_List when they ought to
behave similarly. (I've got an explanation of the changes in addition to
the patch because last time I sent a patch, it was immediately trumped
with a bet
On Sun, 24 Apr 2005, Bryan Kadzban wrote:
>
> Why not strtoul and unsigned longs?
>
Ahh, that sounds like a far better idea. I didn't know of strtoul.
I thought having to do a ">> 32" to check the string thereafter was
unnecessarily complicated.
Presumably the "less than zero" error would then
Current CVS has a minor bug where ARGB strings that use the 32nd bit are
lost. For example
"#" will parse into a = 0x7F, r,g,b = 0xFF.
Attached is a simple fix that replaces the strtol with a strtoll, fixing
the glitch.
Dylan.
Index: ecore_config.c
==
