Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: On 12/06/11 20:10, Enlightenment SVN wrote: Log: NO! you break api. you made my e sit here with a segv in a getenv. because now many libraries and api's don't have prototyopes for malloc/calloc and much more and this goes horribly wrong especially on 64bit! the eina headers have provided these includes historically and removing them is a BREAK in api. apps that used to compile and run just fine now don't. it's unacceptable to break api. i'm stuck here in unity for crying out loud! this deservves a big FAT REVERT for that! :-P AHMEN !!! To force ANYONE into Unity, is just extra pain that we should not have to go through. Raster, I am with you on this one regardless of the reason. To force something to use Unity is pain enough...the fact that EFL in general would break this much is not acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. Joerg -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: On 12/06/11 20:10, Enlightenment SVN wrote: Log: NO! you break api. you made my e sit here with a segv in a getenv. because now many libraries and api's don't have prototyopes for malloc/calloc and much more and this goes horribly wrong especially on 64bit! the eina headers have provided these includes historically and removing them is a BREAK in api. apps that used to compile and run just fine now don't. it's unacceptable to break api. i'm stuck here in unity for crying out loud! this deservves a big FAT REVERT for that! :-P AHMEN !!! To force ANYONE into Unity, is just extra pain that we should not have to go through. Raster, I am with you on this one regardless of the reason. To force something to use Unity is pain enough...the fact that EFL in general would break this much is not acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. I agree. The eina header should just be self consistent (i mean : include what is really necessary). If no stdlib.h stuff is used in the headers, then stdlib.h can be removed. It's the source file including the eina header that is not including a necessary header file Vincent -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 7, 2011 at 11:50 AM, Vincent Torri vincent.to...@gmail.com wrote: On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: On 12/06/11 20:10, Enlightenment SVN wrote: Log: NO! you break api. you made my e sit here with a segv in a getenv. because now many libraries and api's don't have prototyopes for malloc/calloc and much more and this goes horribly wrong especially on 64bit! the eina headers have provided these includes historically and removing them is a BREAK in api. apps that used to compile and run just fine now don't. it's unacceptable to break api. i'm stuck here in unity for crying out loud! this deservves a big FAT REVERT for that! :-P AHMEN !!! To force ANYONE into Unity, is just extra pain that we should not have to go through. Raster, I am with you on this one regardless of the reason. To force something to use Unity is pain enough...the fact that EFL in general would break this much is not acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. I agree. The eina header should just be self consistent (i mean : include what is really necessary). If no stdlib.h stuff is used in the headers, then stdlib.h can be removed. It's the source file including the eina header that is not including a necessary header file That was my point of view to, but raster is right. As people using EFL weren't require to include stdlib.h in there file, they didn't. Changing this, break their apps, so it's an API break. That's sad and bad, but there is little we can do. For 2.0, in 10 years, we can fix that, but now we are stuck with this include. -- Cedric BAIL -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, 7 Dec 2011 12:06:46 +0100 Cedric BAIL cedric.b...@free.fr said: On Wed, Dec 7, 2011 at 11:50 AM, Vincent Torri vincent.to...@gmail.com wrote: On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: On 12/06/11 20:10, Enlightenment SVN wrote: Log: NO! you break api. you made my e sit here with a segv in a getenv. because now many libraries and api's don't have prototyopes for malloc/calloc and much more and this goes horribly wrong especially on 64bit! the eina headers have provided these includes historically and removing them is a BREAK in api. apps that used to compile and run just fine now don't. it's unacceptable to break api. i'm stuck here in unity for crying out loud! this deservves a big FAT REVERT for that! :-P AHMEN !!! To force ANYONE into Unity, is just extra pain that we should not have to go through. Raster, I am with you on this one regardless of the reason. To force something to use Unity is pain enough...the fact that EFL in general would break this much is not acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. I agree. The eina header should just be self consistent (i mean : include what is really necessary). If no stdlib.h stuff is used in the headers, then stdlib.h can be removed. It's the source file including the eina header that is not including a necessary header file That was my point of view to, but raster is right. As people using EFL weren't require to include stdlib.h in there file, they didn't. Changing this, break their apps, so it's an API break. That's sad and bad, but there is little we can do. For 2.0, in 10 years, we can fix that, but now we are stuck with this include. correct. if this is good or bad (we include stdlib.h and what not) is now irrelevant. applications depend on that feature - even our OWN efl libs (efreet, ecore etc. etc.) rely on it - thus me being grumpily stuck in unity with e barfing at some weird place - getenv(). reality is anyone else using eina may end up in a similar position and that makes for an api break - if we like it or not, it's compatibility we have to maintain. we can change it at 2.0 when we are allowed to break things - but until that day ... we can't :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 7, 2011 at 9:06 AM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Dec 7, 2011 at 11:50 AM, Vincent Torri vincent.to...@gmail.com wrote: On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: On 12/06/11 20:10, Enlightenment SVN wrote: Log: NO! you break api. you made my e sit here with a segv in a getenv. because now many libraries and api's don't have prototyopes for malloc/calloc and much more and this goes horribly wrong especially on 64bit! the eina headers have provided these includes historically and removing them is a BREAK in api. apps that used to compile and run just fine now don't. it's unacceptable to break api. i'm stuck here in unity for crying out loud! this deservves a big FAT REVERT for that! :-P AHMEN !!! To force ANYONE into Unity, is just extra pain that we should not have to go through. Raster, I am with you on this one regardless of the reason. To force something to use Unity is pain enough...the fact that EFL in general would break this much is not acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. I agree. The eina header should just be self consistent (i mean : include what is really necessary). If no stdlib.h stuff is used in the headers, then stdlib.h can be removed. It's the source file including the eina header that is not including a necessary header file That was my point of view to, but raster is right. As people using EFL weren't require to include stdlib.h in there file, they didn't. Changing this, break their apps, so it's an API break. That's sad and bad, but there is little we can do. For 2.0, in 10 years, we can fix that, but now we are stuck with this include. I agree... Though it would be better not to include them, once it's there there's not much we can do. Lucas De Marchi -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On 12/06/11 20:10, Enlightenment SVN wrote:
Log:
NO! you break api. you made my e sit here with a segv in a getenv.
because now many libraries and api's don't have prototyopes for
malloc/calloc and much more and this goes horribly wrong especially on
64bit! the eina headers have provided these includes historically and
removing them is a BREAK in api. apps that used to compile and run
just fine now don't. it's unacceptable to break api.
i'm stuck here in unity for crying out loud! this deservves a big FAT
REVERT for that! :-P
AHMEN !!! To force ANYONE into Unity, is just extra pain that we
should not have to go through. Raster, I am with you on this one
regardless of the reason. To force something to use Unity is pain
enough...the fact that EFL in general would break this much is not
acceptible...period.
dh
Author: raster
Date: 2011-12-06 17:10:43 -0800 (Tue, 06 Dec 2011)
New Revision: 65983
Trac: http://trac.enlightenment.org/e/changeset/65983
Modified:
trunk/eina/src/include/eina_array.h
trunk/eina/src/include/eina_inline_array.x
trunk/eina/src/include/eina_inline_f32p32.x
trunk/eina/src/include/eina_inline_str.x
trunk/eina/src/include/eina_inline_stringshare.x
trunk/eina/src/include/eina_list.h trunk/eina/src/include/eina_log.h
trunk/eina/src/include/eina_matrixsparse.h
trunk/eina/src/include/eina_rbtree.h trunk/eina/src/include/eina_str.h
trunk/eina/src/include/eina_unicode.h
Modified: trunk/eina/src/include/eina_array.h
===
--- trunk/eina/src/include/eina_array.h 2011-12-07 00:49:00 UTC (rev
65982)
+++ trunk/eina/src/include/eina_array.h 2011-12-07 01:10:43 UTC (rev
65983)
@@ -19,6 +19,8 @@
#ifndef EINA_ARRAY_H_
#define EINA_ARRAY_H_
+#includestdlib.h
+
#include eina_config.h
#include eina_types.h
Modified: trunk/eina/src/include/eina_inline_array.x
===
--- trunk/eina/src/include/eina_inline_array.x2011-12-07 00:49:00 UTC
(rev 65982)
+++ trunk/eina/src/include/eina_inline_array.x2011-12-07 01:10:43 UTC
(rev 65983)
@@ -21,6 +21,8 @@
#includestddef.h
+#includestdio.h
+
/**
* @cond LOCAL
*/
Modified: trunk/eina/src/include/eina_inline_f32p32.x
===
--- trunk/eina/src/include/eina_inline_f32p32.x 2011-12-07 00:49:00 UTC
(rev 65982)
+++ trunk/eina/src/include/eina_inline_f32p32.x 2011-12-07 01:10:43 UTC
(rev 65983)
@@ -19,6 +19,8 @@
#ifndef EINA_INLINE_F32P32_X_
# define EINA_INLINE_F32P32_X_
+#includestdlib.h
+
static inline Eina_F32p32
eina_f32p32_add(Eina_F32p32 a, Eina_F32p32 b)
{
Modified: trunk/eina/src/include/eina_inline_str.x
===
--- trunk/eina/src/include/eina_inline_str.x 2011-12-07 00:49:00 UTC (rev
65982)
+++ trunk/eina/src/include/eina_inline_str.x 2011-12-07 01:10:43 UTC (rev
65983)
@@ -19,8 +19,6 @@
#ifndef EINA_STR_INLINE_H_
#define EINA_STR_INLINE_H_
-#includestring.h
-
/**
* @addtogroup Eina_String_Group String
*
Modified: trunk/eina/src/include/eina_inline_stringshare.x
===
--- trunk/eina/src/include/eina_inline_stringshare.x 2011-12-07 00:49:00 UTC
(rev 65982)
+++ trunk/eina/src/include/eina_inline_stringshare.x 2011-12-07 01:10:43 UTC
(rev 65983)
@@ -19,6 +19,7 @@
#ifndef EINA_STRINGSHARE_INLINE_H_
#define EINA_STRINGSHARE_INLINE_H_
+#includestring.h
#include eina_stringshare.h
/**
* @addtogroup Eina_Stringshare_Group Stringshare
Modified: trunk/eina/src/include/eina_list.h
===
--- trunk/eina/src/include/eina_list.h2011-12-07 00:49:00 UTC (rev
65982)
+++ trunk/eina/src/include/eina_list.h2011-12-07 01:10:43 UTC (rev
65983)
@@ -19,6 +19,8 @@
#ifndef EINA_LIST_H_
#define EINA_LIST_H_
+#includestdlib.h
+
#include eina_config.h
#include eina_types.h
Modified: trunk/eina/src/include/eina_log.h
===
--- trunk/eina/src/include/eina_log.h 2011-12-07 00:49:00 UTC (rev 65982)
+++ trunk/eina/src/include/eina_log.h 2011-12-07 01:10:43 UTC (rev 65983)
@@ -19,6 +19,7 @@
#ifndef EINA_LOG_H_
#define EINA_LOG_H_
+#includestdlib.h
#includestdarg.h
#includesys/types.h
Modified: trunk/eina/src/include/eina_matrixsparse.h
===
--- trunk/eina/src/include/eina_matrixsparse.h2011-12-07 00:49:00 UTC
(rev 65982)
+++ trunk/eina/src/include/eina_matrixsparse.h2011-12-07 01:10:43 UTC
(rev 65983)
@@ -19,6 +19,8 @@
#ifndef EINA_MATRIXSPARSE_H_
#define
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Mon, 2 May 2011, Enlightenment SVN wrote:
Log:
formalise eina lock results to be equivalent to true/false with added
deadlock for try.
Author: raster
Date: 2011-05-02 01:24:06 -0700 (Mon, 02 May 2011)
New Revision: 59101
Trac: http://trac.enlightenment.org/e/changeset/59101
Modified:
trunk/eina/src/include/eina_inline_lock_posix.x
Modified: trunk/eina/src/include/eina_inline_lock_posix.x
===
--- trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-02 07:28:07 UTC
(rev 59100)
+++ trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-02 08:24:06 UTC
(rev 59101)
@@ -51,6 +51,19 @@
#endif
};
+#ifdef EINA_LOCK_DEBUG
+# define EINA_LOCK_INITIALIZER { PTHREAD_MUTEX_INITIALIZER, 0, { 0 }, 0, 0 }
+#else
+# define EINA_LOCK_INITIALIZER { PTHREAD_MUTEX_INITIALIZER }
please don't do that. There is no static definition on Windows. You are
adding an API which can not be used on Windows
Vincent
+#endif
+
+typedef enum
+{
+ EINA_LOCK_FAIL = EINA_FALSE,
+ EINA_LOCK_SUCCEED = EINA_TRUE,
+ EINA_LOCK_DEADLOCK
+} Eina_Lock_Result;
+
EAPI extern Eina_Bool _eina_threads_activated;
#ifdef EINA_HAVE_DEBUG_THREADS
@@ -59,7 +72,7 @@
EAPI extern int _eina_threads_debug;
#endif
-static inline Eina_Bool
+static inline Eina_Lock_Result
eina_lock_new(Eina_Lock *mutex)
{
pthread_mutexattr_t attr;
@@ -94,7 +107,7 @@
#endif
}
-static inline Eina_Bool
+static inline Eina_Lock_Result
eina_lock_take(Eina_Lock *mutex)
{
Eina_Bool ret;
@@ -128,7 +141,7 @@
return ret;
}
-static inline Eina_Bool
+static inline Eina_Lock_Result
eina_lock_take_try(Eina_Lock *mutex)
{
Eina_Bool ret = EINA_FALSE;
@@ -139,7 +152,7 @@
else if (ok == EDEADLK)
{
printf(ERROR ERROR: DEADLOCK on lock %p\n, mutex);
-ret = 2; // magic
+ret = EINA_LOCK_DEADLOCK; // magic
}
#ifdef EINA_LOCK_DEBUG
if (ret == EINA_TRUE)
@@ -152,7 +165,7 @@
return ret;
}
-static inline Eina_Bool
+static inline Eina_Lock_Result
eina_lock_release(Eina_Lock *mutex)
{
Eina_Bool ret;
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, 1 May 2011, Enlightenment SVN wrote:
Log:
oh dear. this new eina_lock thing is a bit of a mess isn't it now?
some fundamental errors there. don't go replacing pthread locks with
wrappers unless you know full well what u are doing. havnig threads
only work while threads are initted and then init/shtudown the thread
thing every time u spawn a thread.. is pretty silly. what if a thread
ends in the background WHILE u have a lock.. u try unlock.. u know
what ? your unlock DOES nothing. so you retain a lock. next time u
want to lock once a thread is around.. u have a deadlock issue.
even better - the checking if threads are initted and up is not
locked, so it can come up while it is being checked. more race
conditions. u need to clokc the init/shutdown AND lock the checking of
the value... and even then u STILl have problem #1 above. so that code
is now gone.
also trylock trturn inverse logic to the original pthread func and the
macros in evas that used it were not changed accordingly! aaagh!
i've also added backtrace debug ability to eina threads if compiled in
- u can get a bt of who last locked something. i had to do this just to
begin to grasp what on earth was going on. it's off by default.
also... the locks are error check locks to trylock can detect
deadlocks. speacil 2 return for now. better than a poke in the eye
with a sharp stick until we decide what to do. for now i hopew i have
killed this thread lock bug.
can i try to mimic that to debug threads on Windows too ?
Vincent
Author: raster
Date: 2011-05-01 06:24:08 -0700 (Sun, 01 May 2011)
New Revision: 59085
Trac: http://trac.enlightenment.org/e/changeset/59085
Modified:
trunk/eina/src/include/eina_inline_lock_posix.x
Modified: trunk/eina/src/include/eina_inline_lock_posix.x
===
--- trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-01 12:58:35 UTC
(rev 59084)
+++ trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-01 13:24:08 UTC
(rev 59085)
@@ -19,6 +19,7 @@
#ifndef EINA_INLINE_LOCK_POSIX_X_
#define EINA_INLINE_LOCK_POSIX_X_
+#include errno.h
#ifndef __USE_UNIX98
# define __USE_UNIX98
# include pthread.h
@@ -27,8 +28,29 @@
# include pthread.h
#endif
-typedef pthread_mutex_t Eina_Lock;
+/*
+#define EINA_LOCK_DEBUG 1
+*/
+#ifdef EINA_LOCK_DEBUG
+#include execinfo.h
+#define EINA_LOCK_DEBUG_BT_NUM 64
+typedef void (*Eina_Lock_Bt_Func) ();
+#endif
+
+typedef struct _Eina_Lock Eina_Lock;
+
+struct _Eina_Lock
+{
+ pthread_mutex_t mutex;
+#ifdef EINA_LOCK_DEBUG
+ pthread_t lock_thread_id;
+ Eina_Lock_Bt_Func lock_bt[EINA_LOCK_DEBUG_BT_NUM];
+ int lock_bt_num;
+ Eina_Bool locked : 1;
+#endif
+};
+
EAPI extern Eina_Bool _eina_threads_activated;
#ifdef EINA_HAVE_DEBUG_THREADS
@@ -44,12 +66,19 @@
if (pthread_mutexattr_init(attr) != 0)
return EINA_FALSE;
+/* use errorcheck locks. detect deadlocks.
#ifdef PTHREAD_MUTEX_RECURSIVE
if (pthread_mutexattr_settype(attr, PTHREAD_MUTEX_RECURSIVE) != 0)
return EINA_FALSE;
#endif
- if (pthread_mutex_init(mutex, attr) != 0)
+ */
+ if (pthread_mutexattr_settype(attr, PTHREAD_MUTEX_ERRORCHECK) != 0)
return EINA_FALSE;
+#ifdef EINA_LOCK_DEBUG
+ memset(mutex, 0, sizeof(Eina_Lock));
+#endif
+ if (pthread_mutex_init((mutex-mutex), attr) != 0)
+ return EINA_FALSE;
pthread_mutexattr_destroy(attr);
@@ -59,53 +88,95 @@
static inline void
eina_lock_free(Eina_Lock *mutex)
{
- pthread_mutex_destroy(mutex);
+ pthread_mutex_destroy((mutex-mutex));
+#ifdef EINA_LOCK_DEBUG
+ memset(mutex, 0, sizeof(Eina_Lock));
+#endif
}
static inline Eina_Bool
eina_lock_take(Eina_Lock *mutex)
{
- if (_eina_threads_activated)
- {
+ Eina_Bool ret;
#ifdef EINA_HAVE_DEBUG_THREADS
- if (_eina_threads_debug)
- {
- struct timeval t0, t1;
- int dt;
-
- gettimeofday(t0, NULL);
- pthread_mutex_lock((x));
- gettimeofday(t1, NULL);
-
- dt = (t1.tv_sec - t0.tv_sec) * 100;
- if (t1.tv_usec t0.tv_usec)
-dt += (t1.tv_usec - t0.tv_usec);
- else
-dt -= t0.tv_usec - t1.tv_usec;
- dt /= 1000;
-
- if (dt _eina_threads_debug) abort();
- }
+ if (_eina_threads_debug)
+ {
+struct timeval t0, t1;
+int dt;
+
+gettimeofday(t0, NULL);
+pthread_mutex_lock((x));
+gettimeofday(t1, NULL);
+
+dt = (t1.tv_sec - t0.tv_sec) * 100;
+if (t1.tv_usec t0.tv_usec)
+ dt += (t1.tv_usec - t0.tv_usec);
+else
+ dt -= t0.tv_usec - t1.tv_usec;
+dt /= 1000;
+
+if (dt _eina_threads_debug) abort();
+ }
#endif
-
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, 1 May 2011 16:16:43 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
On Sun, 1 May 2011, Enlightenment SVN wrote:
Log:
oh dear. this new eina_lock thing is a bit of a mess isn't it now?
some fundamental errors there. don't go replacing pthread locks with
wrappers unless you know full well what u are doing. havnig threads
only work while threads are initted and then init/shtudown the thread
thing every time u spawn a thread.. is pretty silly. what if a thread
ends in the background WHILE u have a lock.. u try unlock.. u know
what ? your unlock DOES nothing. so you retain a lock. next time u
want to lock once a thread is around.. u have a deadlock issue.
even better - the checking if threads are initted and up is not
locked, so it can come up while it is being checked. more race
conditions. u need to clokc the init/shutdown AND lock the checking of
the value... and even then u STILl have problem #1 above. so that code
is now gone.
also trylock trturn inverse logic to the original pthread func and the
macros in evas that used it were not changed accordingly! aaagh!
i've also added backtrace debug ability to eina threads if compiled in
- u can get a bt of who last locked something. i had to do this just to
begin to grasp what on earth was going on. it's off by default.
also... the locks are error check locks to trylock can detect
deadlocks. speacil 2 return for now. better than a poke in the eye
with a sharp stick until we decide what to do. for now i hopew i have
killed this thread lock bug.
can i try to mimic that to debug threads on Windows too ?
do you have a working backtrace. yes - gnu extensions. :) or you mean the
deadlock detection thats in pthread for error check locks?
Vincent
Author: raster
Date: 2011-05-01 06:24:08 -0700 (Sun, 01 May 2011)
New Revision: 59085
Trac: http://trac.enlightenment.org/e/changeset/59085
Modified:
trunk/eina/src/include/eina_inline_lock_posix.x
Modified: trunk/eina/src/include/eina_inline_lock_posix.x
===
--- trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-01
12:58:35 UTC (rev 59084) +++
trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-01 13:24:08
UTC (rev 59085) @@ -19,6 +19,7 @@
#ifndef EINA_INLINE_LOCK_POSIX_X_
#define EINA_INLINE_LOCK_POSIX_X_
+#include errno.h
#ifndef __USE_UNIX98
# define __USE_UNIX98
# include pthread.h
@@ -27,8 +28,29 @@
# include pthread.h
#endif
-typedef pthread_mutex_t Eina_Lock;
+/*
+#define EINA_LOCK_DEBUG 1
+*/
+#ifdef EINA_LOCK_DEBUG
+#include execinfo.h
+#define EINA_LOCK_DEBUG_BT_NUM 64
+typedef void (*Eina_Lock_Bt_Func) ();
+#endif
+
+typedef struct _Eina_Lock Eina_Lock;
+
+struct _Eina_Lock
+{
+ pthread_mutex_t mutex;
+#ifdef EINA_LOCK_DEBUG
+ pthread_t lock_thread_id;
+ Eina_Lock_Bt_Func lock_bt[EINA_LOCK_DEBUG_BT_NUM];
+ int lock_bt_num;
+ Eina_Bool locked : 1;
+#endif
+};
+
EAPI extern Eina_Bool _eina_threads_activated;
#ifdef EINA_HAVE_DEBUG_THREADS
@@ -44,12 +66,19 @@
if (pthread_mutexattr_init(attr) != 0)
return EINA_FALSE;
+/* use errorcheck locks. detect deadlocks.
#ifdef PTHREAD_MUTEX_RECURSIVE
if (pthread_mutexattr_settype(attr, PTHREAD_MUTEX_RECURSIVE) != 0)
return EINA_FALSE;
#endif
- if (pthread_mutex_init(mutex, attr) != 0)
+ */
+ if (pthread_mutexattr_settype(attr, PTHREAD_MUTEX_ERRORCHECK) != 0)
return EINA_FALSE;
+#ifdef EINA_LOCK_DEBUG
+ memset(mutex, 0, sizeof(Eina_Lock));
+#endif
+ if (pthread_mutex_init((mutex-mutex), attr) != 0)
+ return EINA_FALSE;
pthread_mutexattr_destroy(attr);
@@ -59,53 +88,95 @@
static inline void
eina_lock_free(Eina_Lock *mutex)
{
- pthread_mutex_destroy(mutex);
+ pthread_mutex_destroy((mutex-mutex));
+#ifdef EINA_LOCK_DEBUG
+ memset(mutex, 0, sizeof(Eina_Lock));
+#endif
}
static inline Eina_Bool
eina_lock_take(Eina_Lock *mutex)
{
- if (_eina_threads_activated)
- {
+ Eina_Bool ret;
#ifdef EINA_HAVE_DEBUG_THREADS
- if (_eina_threads_debug)
- {
- struct timeval t0, t1;
- int dt;
-
- gettimeofday(t0, NULL);
- pthread_mutex_lock((x));
- gettimeofday(t1, NULL);
-
- dt = (t1.tv_sec - t0.tv_sec) * 100;
- if (t1.tv_usec t0.tv_usec)
-dt += (t1.tv_usec - t0.tv_usec);
- else
-dt -= t0.tv_usec - t1.tv_usec;
- dt /= 1000;
-
- if (dt _eina_threads_debug) abort();
- }
+ if (_eina_threads_debug)
+ {
+struct timeval t0, t1;
+int dt;
+
+gettimeofday(t0, NULL);
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Mon, 2 May 2011, Carsten Haitzler (The Rasterman) wrote:
On Sun, 1 May 2011 16:16:43 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
On Sun, 1 May 2011, Enlightenment SVN wrote:
Log:
oh dear. this new eina_lock thing is a bit of a mess isn't it now?
some fundamental errors there. don't go replacing pthread locks with
wrappers unless you know full well what u are doing. havnig threads
only work while threads are initted and then init/shtudown the thread
thing every time u spawn a thread.. is pretty silly. what if a thread
ends in the background WHILE u have a lock.. u try unlock.. u know
what ? your unlock DOES nothing. so you retain a lock. next time u
want to lock once a thread is around.. u have a deadlock issue.
even better - the checking if threads are initted and up is not
locked, so it can come up while it is being checked. more race
conditions. u need to clokc the init/shutdown AND lock the checking of
the value... and even then u STILl have problem #1 above. so that code
is now gone.
also trylock trturn inverse logic to the original pthread func and the
macros in evas that used it were not changed accordingly! aaagh!
i've also added backtrace debug ability to eina threads if compiled in
- u can get a bt of who last locked something. i had to do this just to
begin to grasp what on earth was going on. it's off by default.
also... the locks are error check locks to trylock can detect
deadlocks. speacil 2 return for now. better than a poke in the eye
with a sharp stick until we decide what to do. for now i hopew i have
killed this thread lock bug.
can i try to mimic that to debug threads on Windows too ?
do you have a working backtrace. yes - gnu extensions. :) or you mean the
deadlock detection thats in pthread for error check locks?
For backtrace, I have that with vc++:
http://msdn.microsoft.com/en-us/library/ff552119%28VS.85%29.aspx
This function has already been used to capture the stack in Boost.
Otherwise, with mingw, I think that I have backtrace().
about deadlock, I don't know. I'm not very good with threads...
Vincent
Vincent
Author: raster
Date: 2011-05-01 06:24:08 -0700 (Sun, 01 May 2011)
New Revision: 59085
Trac: http://trac.enlightenment.org/e/changeset/59085
Modified:
trunk/eina/src/include/eina_inline_lock_posix.x
Modified: trunk/eina/src/include/eina_inline_lock_posix.x
===
--- trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-01
12:58:35 UTC (rev 59084) +++
trunk/eina/src/include/eina_inline_lock_posix.x 2011-05-01 13:24:08
UTC (rev 59085) @@ -19,6 +19,7 @@
#ifndef EINA_INLINE_LOCK_POSIX_X_
#define EINA_INLINE_LOCK_POSIX_X_
+#include errno.h
#ifndef __USE_UNIX98
# define __USE_UNIX98
# include pthread.h
@@ -27,8 +28,29 @@
# include pthread.h
#endif
-typedef pthread_mutex_t Eina_Lock;
+/*
+#define EINA_LOCK_DEBUG 1
+*/
+#ifdef EINA_LOCK_DEBUG
+#include execinfo.h
+#define EINA_LOCK_DEBUG_BT_NUM 64
+typedef void (*Eina_Lock_Bt_Func) ();
+#endif
+
+typedef struct _Eina_Lock Eina_Lock;
+
+struct _Eina_Lock
+{
+ pthread_mutex_t mutex;
+#ifdef EINA_LOCK_DEBUG
+ pthread_t lock_thread_id;
+ Eina_Lock_Bt_Func lock_bt[EINA_LOCK_DEBUG_BT_NUM];
+ int lock_bt_num;
+ Eina_Bool locked : 1;
+#endif
+};
+
EAPI extern Eina_Bool _eina_threads_activated;
#ifdef EINA_HAVE_DEBUG_THREADS
@@ -44,12 +66,19 @@
if (pthread_mutexattr_init(attr) != 0)
return EINA_FALSE;
+/* use errorcheck locks. detect deadlocks.
#ifdef PTHREAD_MUTEX_RECURSIVE
if (pthread_mutexattr_settype(attr, PTHREAD_MUTEX_RECURSIVE) != 0)
return EINA_FALSE;
#endif
- if (pthread_mutex_init(mutex, attr) != 0)
+ */
+ if (pthread_mutexattr_settype(attr, PTHREAD_MUTEX_ERRORCHECK) != 0)
return EINA_FALSE;
+#ifdef EINA_LOCK_DEBUG
+ memset(mutex, 0, sizeof(Eina_Lock));
+#endif
+ if (pthread_mutex_init((mutex-mutex), attr) != 0)
+ return EINA_FALSE;
pthread_mutexattr_destroy(attr);
@@ -59,53 +88,95 @@
static inline void
eina_lock_free(Eina_Lock *mutex)
{
- pthread_mutex_destroy(mutex);
+ pthread_mutex_destroy((mutex-mutex));
+#ifdef EINA_LOCK_DEBUG
+ memset(mutex, 0, sizeof(Eina_Lock));
+#endif
}
static inline Eina_Bool
eina_lock_take(Eina_Lock *mutex)
{
- if (_eina_threads_activated)
- {
+ Eina_Bool ret;
#ifdef EINA_HAVE_DEBUG_THREADS
- if (_eina_threads_debug)
- {
- struct timeval t0, t1;
- int dt;
-
- gettimeofday(t0, NULL);
- pthread_mutex_lock((x));
- gettimeofday(t1, NULL);
-
- dt = (t1.tv_sec - t0.tv_sec) * 100;
- if (t1.tv_usec t0.tv_usec)
-dt += (t1.tv_usec - t0.tv_usec);
- else
-dt -= t0.tv_usec - t1.tv_usec;
-
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Mon, 2 May 2011, Mike Blumenkrantz wrote: On Mon, 2 May 2011 07:01:36 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Mon, 2 May 2011, Carsten Haitzler (The Rasterman) wrote: On Sun, 1 May 2011 16:16:43 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Sun, 1 May 2011, Enlightenment SVN wrote: Log: oh dear. this new eina_lock thing is a bit of a mess isn't it now? some fundamental errors there. don't go replacing pthread locks with wrappers unless you know full well what u are doing. havnig threads only work while threads are initted and then init/shtudown the thread thing every time u spawn a thread.. is pretty silly. what if a thread ends in the background WHILE u have a lock.. u try unlock.. u know what ? your unlock DOES nothing. so you retain a lock. next time u want to lock once a thread is around.. u have a deadlock issue. even better - the checking if threads are initted and up is not locked, so it can come up while it is being checked. more race conditions. u need to clokc the init/shutdown AND lock the checking of the value... and even then u STILl have problem #1 above. so that code is now gone. also trylock trturn inverse logic to the original pthread func and the macros in evas that used it were not changed accordingly! aaagh! i've also added backtrace debug ability to eina threads if compiled in - u can get a bt of who last locked something. i had to do this just to begin to grasp what on earth was going on. it's off by default. also... the locks are error check locks to trylock can detect deadlocks. speacil 2 return for now. better than a poke in the eye with a sharp stick until we decide what to do. for now i hopew i have killed this thread lock bug. can i try to mimic that to debug threads on Windows too ? do you have a working backtrace. yes - gnu extensions. :) or you mean the deadlock detection thats in pthread for error check locks? For backtrace, I have that with vc++: http://msdn.microsoft.com/en-us/library/ff552119%28VS.85%29.aspx This function has already been used to capture the stack in Boost. Otherwise, with mingw, I think that I have backtrace(). about deadlock, I don't know. I'm not very good with threads... Vincent Vincent Do you have something like helgrind/drd tools from valgrind that you can use on Windows? That's probably what you would want to find an equivalent for debugging deadlocks. valgrind does not work on Windows, but I have found some doc in MSDN http://msdn.microsoft.com/en-us/library/ms810303.aspx I'll check that later. i have other problems, with ecore_con :) Vincent -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Mon, 2 May 2011 07:20:38 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Mon, 2 May 2011, Mike Blumenkrantz wrote: On Mon, 2 May 2011 07:01:36 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Mon, 2 May 2011, Carsten Haitzler (The Rasterman) wrote: On Sun, 1 May 2011 16:16:43 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Sun, 1 May 2011, Enlightenment SVN wrote: Log: oh dear. this new eina_lock thing is a bit of a mess isn't it now? some fundamental errors there. don't go replacing pthread locks with wrappers unless you know full well what u are doing. havnig threads only work while threads are initted and then init/shtudown the thread thing every time u spawn a thread.. is pretty silly. what if a thread ends in the background WHILE u have a lock.. u try unlock.. u know what ? your unlock DOES nothing. so you retain a lock. next time u want to lock once a thread is around.. u have a deadlock issue. even better - the checking if threads are initted and up is not locked, so it can come up while it is being checked. more race conditions. u need to clokc the init/shutdown AND lock the checking of the value... and even then u STILl have problem #1 above. so that code is now gone. also trylock trturn inverse logic to the original pthread func and the macros in evas that used it were not changed accordingly! aaagh! i've also added backtrace debug ability to eina threads if compiled in - u can get a bt of who last locked something. i had to do this just to begin to grasp what on earth was going on. it's off by default. also... the locks are error check locks to trylock can detect deadlocks. speacil 2 return for now. better than a poke in the eye with a sharp stick until we decide what to do. for now i hopew i have killed this thread lock bug. can i try to mimic that to debug threads on Windows too ? do you have a working backtrace. yes - gnu extensions. :) or you mean the deadlock detection thats in pthread for error check locks? For backtrace, I have that with vc++: http://msdn.microsoft.com/en-us/library/ff552119%28VS.85%29.aspx This function has already been used to capture the stack in Boost. Otherwise, with mingw, I think that I have backtrace(). about deadlock, I don't know. I'm not very good with threads... Vincent Vincent Do you have something like helgrind/drd tools from valgrind that you can use on Windows? That's probably what you would want to find an equivalent for debugging deadlocks. valgrind does not work on Windows, but I have found some doc in MSDN http://msdn.microsoft.com/en-us/library/ms810303.aspx I'll check that later. i have other problems, with ecore_con :) /me flees Vincent -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, Dec 9, 2010 at 12:32 AM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 09 Dec 2010 05:04:01 +0300 Brett Nash n...@nash.id.au said: +/* Why do this? Well PATH_MAX may vary from when eina itself is compiled + * to when the app using eina is compiled. exposing the path buffer below + * cant safely and portably vary based on how/when you compile. it should + * always be the same for both eina inside ANd for apps outside that use eina + * so define this ti 8192 minus ther other struct bits so that + * Eina_File_Direct_Info can take a nice round 2 pages. */ +#define EINA_PATH_MAX (8192 - (sizeof(size_t) * 3) - sizeof(Eina_File_Type)) Doesn't this logic only make sense if: - You use external tracking for your mallocs, or - You use a pool allocator? Since neither is true in the general case you've just made EINA_PATH_MAX incompatible with every path max on the planet, in return for a gain that will won't happen for anyway. iot was either $define it to 4096 or choose another number (i just chose 8192 - some little bits). Considering the only time it's used is INSIDE another structure... There is never a gain. So the result is more complex, always incompatible, and never a gain. its SIMPLY changing the size of 1 struct element that actually never had a fixed known size anyway (as PATH_MAX may vary in its value between compiling eina itself and app using eina headers and compiling its own code), depending on what system headers where happened to have been included. look at the only thing using it. thats the only reason it exists. that 1 struct member. PATH_MAX there should not be important, it's some buffer size, as it's read-only to the application, and the actual used size is in the structure and that should be always used, the only problem so far is that Raster added the type field AFTER the string... but he changed that already, so doesn't matter now :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, Dec 9, 2010 at 12:55 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: and if i'm breaking shit... i may as well put it at the end, so if size changes later to be bigger, existing code doesnt break (due to the way this is meant to be accessed). size_t path_length; /** size of the whole path */ size_t name_length; /** size of the filename/basename component */ size_t name_start; /** where the filename/basename component starts */ + Eina_File_Type type; /** file type */ char path[EINA_PATH_MAX]; /** the path */ - Eina_File_Type type; /** file type */ that's it! the actual value from PATH_MAX shouldn't matter as it's filled in the code, users should trust it's \0 terminated and size of name_length. HOWEVER, you did not update eina_file.c to use EINA_PATH_MAX, it's still using PATH_MAX that may be bigger than EINA_PATH_MAX (although it matches in most systems) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, 9 Dec 2010, Gustavo Sverzut Barbieri wrote: On Thu, Dec 9, 2010 at 12:55 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: and if i'm breaking shit... i may as well put it at the end, so if size changes later to be bigger, existing code doesnt break (due to the way this is meant to be accessed). size_t path_length; /** size of the whole path */ size_t name_length; /** size of the filename/basename component */ size_t name_start; /** where the filename/basename component starts */ + Eina_File_Type type; /** file type */ char path[EINA_PATH_MAX]; /** the path */ - Eina_File_Type type; /** file type */ that's it! the actual value from PATH_MAX shouldn't matter as it's filled in the code, users should trust it's \0 terminated and size of name_length. HOWEVER, you did not update eina_file.c to use EINA_PATH_MAX, it's still using PATH_MAX that may be bigger than EINA_PATH_MAX (although it matches in most systems) why not something like char path[1]; and allocating the memory ? (with path at the end, it's possible) Vincent-- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, Dec 9, 2010 at 11:24 AM, Vincent Torri vto...@univ-evry.fr wrote: On Thu, 9 Dec 2010, Gustavo Sverzut Barbieri wrote: On Thu, Dec 9, 2010 at 12:55 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: and if i'm breaking shit... i may as well put it at the end, so if size changes later to be bigger, existing code doesnt break (due to the way this is meant to be accessed). size_t path_length; /** size of the whole path */ size_t name_length; /** size of the filename/basename component */ size_t name_start; /** where the filename/basename component starts */ + Eina_File_Type type; /** file type */ char path[EINA_PATH_MAX]; /** the path */ - Eina_File_Type type; /** file type */ that's it! the actual value from PATH_MAX shouldn't matter as it's filled in the code, users should trust it's \0 terminated and size of name_length. HOWEVER, you did not update eina_file.c to use EINA_PATH_MAX, it's still using PATH_MAX that may be bigger than EINA_PATH_MAX (although it matches in most systems) why not something like char path[1]; and allocating the memory ? (with path at the end, it's possible) Because the current code doesn't do any allocation and we want to limit allocation. -- Cedric BAIL -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, Dec 9, 2010 at 8:34 AM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Dec 9, 2010 at 11:24 AM, Vincent Torri vto...@univ-evry.fr wrote: On Thu, 9 Dec 2010, Gustavo Sverzut Barbieri wrote: On Thu, Dec 9, 2010 at 12:55 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: and if i'm breaking shit... i may as well put it at the end, so if size changes later to be bigger, existing code doesnt break (due to the way this is meant to be accessed). size_t path_length; /** size of the whole path */ size_t name_length; /** size of the filename/basename component */ size_t name_start; /** where the filename/basename component starts */ + Eina_File_Type type; /** file type */ char path[EINA_PATH_MAX]; /** the path */ - Eina_File_Type type; /** file type */ that's it! the actual value from PATH_MAX shouldn't matter as it's filled in the code, users should trust it's \0 terminated and size of name_length. HOWEVER, you did not update eina_file.c to use EINA_PATH_MAX, it's still using PATH_MAX that may be bigger than EINA_PATH_MAX (although it matches in most systems) why not something like char path[1]; and allocating the memory ? (with path at the end, it's possible) Because the current code doesn't do any allocation and we want to limit allocation. actually that would work the same way for us, we do one single malloc there, it would be the same, but instead of just sizeof(struct), we'd add the EINA_PATH_MAX. same number of allocations and all. but does it matter? does it help? I don't think so. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, 9 Dec 2010, Cedric BAIL wrote: On Thu, Dec 9, 2010 at 11:24 AM, Vincent Torri vto...@univ-evry.fr wrote: On Thu, 9 Dec 2010, Gustavo Sverzut Barbieri wrote: On Thu, Dec 9, 2010 at 12:55 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: and if i'm breaking shit... i may as well put it at the end, so if size changes later to be bigger, existing code doesnt break (due to the way this is meant to be accessed). size_t path_length; /** size of the whole path */ size_t name_length; /** size of the filename/basename component */ size_t name_start; /** where the filename/basename component starts */ + Eina_File_Type type; /** file type */ char path[EINA_PATH_MAX]; /** the path */ - Eina_File_Type type; /** file type */ that's it! the actual value from PATH_MAX shouldn't matter as it's filled in the code, users should trust it's \0 terminated and size of name_length. HOWEVER, you did not update eina_file.c to use EINA_PATH_MAX, it's still using PATH_MAX that may be bigger than EINA_PATH_MAX (although it matches in most systems) why not something like char path[1]; and allocating the memory ? (with path at the end, it's possible) Because the current code doesn't do any allocation and we want to limit allocation. he, char path[***] will anyway be an allocation (on stack)... and with 8192, you certainly allocate a lot more than necessary Vincent-- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, Dec 9, 2010 at 8:50 AM, Vincent Torri vto...@univ-evry.fr wrote: On Thu, 9 Dec 2010, Cedric BAIL wrote: On Thu, Dec 9, 2010 at 11:24 AM, Vincent Torri vto...@univ-evry.fr wrote: On Thu, 9 Dec 2010, Gustavo Sverzut Barbieri wrote: On Thu, Dec 9, 2010 at 12:55 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: and if i'm breaking shit... i may as well put it at the end, so if size changes later to be bigger, existing code doesnt break (due to the way this is meant to be accessed). size_t path_length; /** size of the whole path */ size_t name_length; /** size of the filename/basename component */ size_t name_start; /** where the filename/basename component starts */ + Eina_File_Type type; /** file type */ char path[EINA_PATH_MAX]; /** the path */ - Eina_File_Type type; /** file type */ that's it! the actual value from PATH_MAX shouldn't matter as it's filled in the code, users should trust it's \0 terminated and size of name_length. HOWEVER, you did not update eina_file.c to use EINA_PATH_MAX, it's still using PATH_MAX that may be bigger than EINA_PATH_MAX (although it matches in most systems) why not something like char path[1]; and allocating the memory ? (with path at the end, it's possible) Because the current code doesn't do any allocation and we want to limit allocation. he, char path[***] will anyway be an allocation (on stack)... and with 8192, you certainly allocate a lot more than necessary it's not in the stack, see the eina_file.c -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, 9 Dec 2010 08:00:46 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Dec 9, 2010 at 12:32 AM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 09 Dec 2010 05:04:01 +0300 Brett Nash n...@nash.id.au said: +/* Why do this? Well PATH_MAX may vary from when eina itself is compiled + * to when the app using eina is compiled. exposing the path buffer below + * cant safely and portably vary based on how/when you compile. it should + * always be the same for both eina inside ANd for apps outside that use eina + * so define this ti 8192 minus ther other struct bits so that + * Eina_File_Direct_Info can take a nice round 2 pages. */ +#define EINA_PATH_MAX (8192 - (sizeof(size_t) * 3) - sizeof(Eina_File_Type)) Doesn't this logic only make sense if: - You use external tracking for your mallocs, or - You use a pool allocator? Since neither is true in the general case you've just made EINA_PATH_MAX incompatible with every path max on the planet, in return for a gain that will won't happen for anyway. iot was either $define it to 4096 or choose another number (i just chose 8192 - some little bits). Considering the only time it's used is INSIDE another structure... There is never a gain. So the result is more complex, always incompatible, and never a gain. its SIMPLY changing the size of 1 struct element that actually never had a fixed known size anyway (as PATH_MAX may vary in its value between compiling eina itself and app using eina headers and compiling its own code), depending on what system headers where happened to have been included. look at the only thing using it. thats the only reason it exists. that 1 struct member. PATH_MAX there should not be important, it's some buffer size, as it's read-only to the application, and the actual used size is in the structure and that should be always used, the only problem so far is that Raster added the type field AFTER the string... but he changed that already, so doesn't matter now :-) that was a break anyway - but size should be fixed and known in an exposed data struct no matter what. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
+/* Why do this? Well PATH_MAX may vary from when eina itself is compiled + * to when the app using eina is compiled. exposing the path buffer below + * cant safely and portably vary based on how/when you compile. it should + * always be the same for both eina inside ANd for apps outside that use eina + * so define this ti 8192 minus ther other struct bits so that + * Eina_File_Direct_Info can take a nice round 2 pages. */ +#define EINA_PATH_MAX (8192 - (sizeof(size_t) * 3) - sizeof(Eina_File_Type)) Doesn't this logic only make sense if: - You use external tracking for your mallocs, or - You use a pool allocator? Since neither is true in the general case you've just made EINA_PATH_MAX incompatible with every path max on the planet, in return for a gain that will won't happen for anyway. Considering the only time it's used is INSIDE another structure... There is never a gain. So the result is more complex, always incompatible, and never a gain. Regards, nash -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, 09 Dec 2010 05:04:01 +0300 Brett Nash n...@nash.id.au said: +/* Why do this? Well PATH_MAX may vary from when eina itself is compiled + * to when the app using eina is compiled. exposing the path buffer below + * cant safely and portably vary based on how/when you compile. it should + * always be the same for both eina inside ANd for apps outside that use eina + * so define this ti 8192 minus ther other struct bits so that + * Eina_File_Direct_Info can take a nice round 2 pages. */ +#define EINA_PATH_MAX (8192 - (sizeof(size_t) * 3) - sizeof(Eina_File_Type)) Doesn't this logic only make sense if: - You use external tracking for your mallocs, or - You use a pool allocator? Since neither is true in the general case you've just made EINA_PATH_MAX incompatible with every path max on the planet, in return for a gain that will won't happen for anyway. iot was either $define it to 4096 or choose another number (i just chose 8192 - some little bits). Considering the only time it's used is INSIDE another structure... There is never a gain. So the result is more complex, always incompatible, and never a gain. its SIMPLY changing the size of 1 struct element that actually never had a fixed known size anyway (as PATH_MAX may vary in its value between compiling eina itself and app using eina headers and compiling its own code), depending on what system headers where happened to have been included. look at the only thing using it. thats the only reason it exists. that 1 struct member. Regards, nash -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, 25 Aug 2010, Joerg Sonnenberger wrote: On Wed, Aug 25, 2010 at 10:22:19PM +0200, Vincent Torri wrote: On Wed, 25 Aug 2010, Raphael Kubo da Costa wrote: FWIW, on FreeBSD at least, limits.h includes both sys/limits.h and sys/syslimits.h (the latter only if __POSIX_VISIBLE is defined). All versions ? At least down to FreeBSD 4.9. Unless you are doing silly things like using -pedantic, but in that case you get what you ask for. I asked a guy using mac os x and it indeed works. So i'll remove the def's Vincent -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Mon, 23 Aug 2010, Joerg Sonnenberger wrote: On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? I was in contact with 2 mac os x users and one freebsd user. I try to fixed the compilation, and limits.h was not sufficient. Vincent -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Aug 25, 2010 at 08:32:28PM +0200, Vincent Torri wrote: On Mon, 23 Aug 2010, Joerg Sonnenberger wrote: On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? I was in contact with 2 mac os x users and one freebsd user. I try to fixed the compilation, and limits.h was not sufficient. Not enough for WHAT? Given that Mac OS X is supposedly certified for POSIX compliants, that would be surprising. It would also disagree what I have been told today when asking exactly this question. Joerg -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wednesday 25 August 2010 16:30:04 Joerg Sonnenberger wrote: On Wed, Aug 25, 2010 at 08:32:28PM +0200, Vincent Torri wrote: On Mon, 23 Aug 2010, Joerg Sonnenberger wrote: On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? I was in contact with 2 mac os x users and one freebsd user. I try to fixed the compilation, and limits.h was not sufficient. Not enough for WHAT? Given that Mac OS X is supposedly certified for POSIX compliants, that would be surprising. It would also disagree what I have been told today when asking exactly this question. FWIW, on FreeBSD at least, limits.h includes both sys/limits.h and sys/syslimits.h (the latter only if __POSIX_VISIBLE is defined). See http://svn.freebsd.org/viewvc/base/stable/8/include/limits.h?revision=196045view=markup -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, 25 Aug 2010, Raphael Kubo da Costa wrote: On Wednesday 25 August 2010 16:30:04 Joerg Sonnenberger wrote: On Wed, Aug 25, 2010 at 08:32:28PM +0200, Vincent Torri wrote: On Mon, 23 Aug 2010, Joerg Sonnenberger wrote: On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? I was in contact with 2 mac os x users and one freebsd user. I try to fixed the compilation, and limits.h was not sufficient. Not enough for WHAT? Given that Mac OS X is supposedly certified for POSIX compliants, that would be surprising. It would also disagree what I have been told today when asking exactly this question. FWIW, on FreeBSD at least, limits.h includes both sys/limits.h and sys/syslimits.h (the latter only if __POSIX_VISIBLE is defined). All versions ? Vincent See http://svn.freebsd.org/viewvc/base/stable/8/include/limits.h?revision=196045view=markup -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wednesday 25 August 2010 17:22:19 Vincent Torri wrote: On Wed, 25 Aug 2010, Raphael Kubo da Costa wrote: On Wednesday 25 August 2010 16:30:04 Joerg Sonnenberger wrote: On Wed, Aug 25, 2010 at 08:32:28PM +0200, Vincent Torri wrote: On Mon, 23 Aug 2010, Joerg Sonnenberger wrote: On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? I was in contact with 2 mac os x users and one freebsd user. I try to fixed the compilation, and limits.h was not sufficient. Not enough for WHAT? Given that Mac OS X is supposedly certified for POSIX compliants, that would be surprising. It would also disagree what I have been told today when asking exactly this question. FWIW, on FreeBSD at least, limits.h includes both sys/limits.h and sys/syslimits.h (the latter only if __POSIX_VISIBLE is defined). All versions ? I've looked at the contents of the 6-stable and 7-stable branches (the two other branches currently supported by the project, with 6 to be dropped in the end of November [1]), and the includes are there too. [1] http://security.freebsd.org/ -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Aug 25, 2010 at 10:22:19PM +0200, Vincent Torri wrote: On Wed, 25 Aug 2010, Raphael Kubo da Costa wrote: FWIW, on FreeBSD at least, limits.h includes both sys/limits.h and sys/syslimits.h (the latter only if __POSIX_VISIBLE is defined). All versions ? At least down to FreeBSD 4.9. Unless you are doing silly things like using -pedantic, but in that case you get what you ask for. Joerg -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
-#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, 22 Aug 2010 06:08:38 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: http://en.wikibooks.org/wiki/C_Programming/Reference_Tables since we are c99 - we can assume c90 too. :) -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, 22 Aug 2010, Carsten Haitzler (The Rasterman) wrote: On Sun, 22 Aug 2010 06:08:38 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: http://en.wikibooks.org/wiki/C_Programming/Reference_Tables since we are c99 - we can assume c90 too. :) the problem is not that limits.h exists everywhere or not, the problem is what we need as variable and if it is in limits.h or not. In case of FreeBSD and Mac OS X, limits.h was not sufficient Vincent -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Fri, 10 Apr 2009 02:45:47 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
On Thu, Apr 9, 2009 at 10:14 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 9 Apr 2009 10:24:19 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Eina.h already does the extern C before it #includes the other .h files...
yes, but even then we cannot have new as variable? AFAIU everything
correct. you can't. :)
inside extern C {...} is handled as C and no C++ keywords can get
in.
no :( unfortunately that's not the case. :(
On Thu, Apr 9, 2009 at 2:55 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
new - news. people with g++ using eina in their c++ stuff will be most
un-amused by the use of a variable called new.
shouldn't exter C {...} in eina_stringshare.h that includes
eina_inline_stringshare.x handle that?
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, 9 Apr 2009 10:24:19 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Eina.h already does the extern C before it #includes the other .h files...
On Thu, Apr 9, 2009 at 2:55 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
new - news. people with g++ using eina in their c++ stuff will be most
un-amused by the use of a variable called new.
shouldn't exter C {...} in eina_stringshare.h that includes
eina_inline_stringshare.x handle that?
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Thu, Apr 9, 2009 at 10:14 PM, Carsten Haitzler ras...@rasterman.com wrote:
On Thu, 9 Apr 2009 10:24:19 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Eina.h already does the extern C before it #includes the other .h files...
yes, but even then we cannot have new as variable? AFAIU everything
inside extern C {...} is handled as C and no C++ keywords can get
in.
On Thu, Apr 9, 2009 at 2:55 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
new - news. people with g++ using eina in their c++ stuff will be most
un-amused by the use of a variable called new.
shouldn't exter C {...} in eina_stringshare.h that includes
eina_inline_stringshare.x handle that?
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Fri, 10 Apr 2009, Gustavo Sverzut Barbieri wrote:
On Thu, Apr 9, 2009 at 10:14 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 9 Apr 2009 10:24:19 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Eina.h already does the extern C before it #includes the other .h files...
yes, but even then we cannot have new as variable? AFAIU everything
inside extern C {...} is handled as C and no C++ keywords can get
in.
i should check with vc++ :p
Vincent
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
