[E-devel] Patch for Ecore_Config ARGB parsing glitch
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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_Dlist_Append bug.
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 the invalid behavior in the current implementation:
= BEGIN CODE SNIPPET =
#include Ecore.h
#include Ecore_Data.h
#include string.h
#include stdlib.h
void print_list(Ecore_DList *list)
{
char *item;
/* Seek to end by looking for NULL */
ecore_dlist_goto_first(list);
while ((item = (char *)ecore_dlist_next(list)) != NULL)
{
printf(%p %s\n, item, item);
}
printf(\n);
}
int main(int argc, const char **argv)
{
char *first = first;
char *second = second;
char *p;
int i, nn;
Ecore_DList *list;
list = ecore_dlist_new();
ecore_dlist_append(list, first);
print_list(list);
ecore_dlist_append(list, second);
/* Now try another way: */
nn = ecore_dlist_nodes(list);
for (i = 0;i nn;i++)
{
p = ecore_dlist_goto_index(list, i);
printf(%d %p %s\n,i, p, p);
}
return EXIT_SUCCESS;
}
= END CODE SNIPPET =
One would expect the goto_index print list to print the list, instead
it prints the first element twice.
Below is the patch to CVS head that fixes this.
= BEGIN PATCH =
RCS file: /cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore/ecore_list.c,v
retrieving revision 1.15
diff -p -u -r1.15 ecore_list.c
--- ecore_list.c30 Jun 2005 16:47:29 -1.15
+++ ecore_list.c21 Jul 2005 18:22:30 -
@@ -372,6 +372,12 @@ static int _ecore_list_append_0(Ecore_Li
list-current = NULL;
}
+if (list-index = list-nodes) /* Index was out of bounds, ensure
that we don't make it in bounds
+ but with an invalid current
pointer by incrementing the nodes */
+list-index++;
+
+
+
list-nodes++;
return TRUE;
= END PATCH =
Dylan.
---
SF.Net email is Sponsored by the Better Software Conference EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Bug in ecore_dlist_remove_destroy(...)
The current implementation of ecore_dlist_remove_destroy() (see
e17/libs/ecore/src/lib/ecore/ecore_list.c) simply calls the same function for
singly linked-list. This is the incorrect behaviour because the ecore_list_
implementation does not deal with the previous pointer correctly. I propose
that the current function should be replaced with:
void ecore_dlist_remove_destroy(Ecore_Dlist * list)
{
void *data;
CHECK_PARAM_POINTER_RETURN(list, list, FALSE);
data = ecore_dlist_remove(list);
if (list-free_func)
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 dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch for Ecore_Config ARGB parsing.
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 be removed altogther? Dylan. --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_DList bugs
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 better idea...)
Take the ecore/examples/list_example.c
change line 23 from:
ecore_list_goto_index(list, 2);
to:
ecore_list_goto_index(list, 1);
Compile and run, and you'll get the following output:
--- Current List ---
first
second
last
Now, go through the source, replace every Ecore_List with Ecore_DList and
every ecore_list_ with ecore_dlist_
Compile and run again, you get:
--- Current List ---
first
last
second
I hunted around a bit to find the bug: the implemention of
ecore_dlist_goto_index has a slight issue when called with a list in which
list-current == NULL.
In the case of singly-linked list, there is a _ecore_list_goto_first which
obviously sets list-current.
But, it seems to me that list-index shouldn't ever be set to something without
the list-current pointing to that (except when the list is empty and
list-index == 0, or the list has items and list-index == x where x
list-nodes-1). If you agree, then it looks like _ecore_list_append_0(...)
should set the list-current = end, around line 370 (ecore_list.c)
Line 1326 should be:
if ( || index 0)
Because an index == 0 is perfectly acceptable (as it is fine for
list_goto_index)
Also Line 1329 should read:
if (ECORE_LIST(list)-index = ECORE_LIST(list)-nodes)
Because if list-index == list-nodes, and list-current == NULL, and then
searching
backward fails.
While on the topic of the ecore_list and ecore_dlist, I do feel that the
implementation is somewhat inadequate because there is no way to store an
pointer (or some contextual information) so that a particular element can be
returned to in \Theta(1) time. The current index stored within the list
provides only one such contextual pointer, but the user will generaly need an
unlimited number of them. The evas_list does far better in this regard,
maintaining numbered indicies makes this difficult for ecore_lists...
is there a reason why the ecore_lists use indicies?
Dylan.
Index: ecore_list.c
===
RCS file: /cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore/ecore_list.c,v
retrieving revision 1.13
diff -u -r1.13 ecore_list.c
--- ecore_list.c4 Jan 2005 22:45:05 - 1.13
+++ ecore_list.c25 Apr 2005 01:36:30 -
@@ -369,6 +369,7 @@
if (list-first == NULL) {
list-first = end;
list-index = 0;
+list-current = end;
}
list-nodes++;
@@ -1322,10 +1323,10 @@
if (ecore_list_is_empty(ECORE_LIST(list)))
return FALSE;
- if (index ecore_list_nodes(ECORE_LIST(list)) || index 1)
+ if (index ecore_list_nodes(ECORE_LIST(list)) || index 0)
return FALSE;
- if (ECORE_LIST(list)-index ECORE_LIST(list)-nodes)
+ if (ECORE_LIST(list)-index = ECORE_LIST(list)-nodes)
_ecore_list_goto_last(ECORE_LIST(list));
if (index ECORE_LIST(list)-index)
---
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
