Kim Woelders wrote:
Tilman Sauerbeck wrote:
On Tue, 06 Sep 2005 21:44:40 +0200 Kim Woelders <[EMAIL PROTECTED]> wrote:
diff -u -3 -r1.24 -r1.25
--- Ecore.h 5 Sep 2005 10:17:08 -0000 1.24
+++ Ecore.h 6 Sep 2005 19:26:19 -0000 1.25
@@ -43,6 +43,14 @@
#include <sys/types.h>
#include <signal.h>
+#ifndef TRUE
+#define TRUE 1
+#endif
+
+#ifndef FALSE
+#define FALSE 0
+#endif
+
#ifdef __cplusplus
extern "C" {
#endif
Is this really a good idea? I have over the years seen way too many
cases of clashing definitions of TRUE/True/true, FALSE/False/false.
true/false are a very different story, since they are defined by C99.
Defining FALSE to zero is alright from my experience. Would you be
happier if we defined TRUE to !FALSE?
No. TRUE should definitely not be defined as !FALSE.
Booleans in C are a pain. Personally, I avoid using them entirely, as I
think they are more trouble than helpful, when they are not intrinsic
to the language.
How about stdbool.h, i.e. bool/true/false? I don't have much experience
with the portability of this one, but it's at least standardized thing.
Anyway, if nobody else is concerned, I'll just crawl back under my rock :)
On gcc 4 bool seems compatible with int, so return an int other then 0
or 1 will convert the return value to 1. So if we just change the return
value from int to bool, people used to 0/1, TRUE/FALSE can still use it.
Has to be checked for other system too, of course.
Sebastian
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
