Boolean typedefs

Boolean typedefs

[Alan Bowman]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

A few weeks ago, I posted a query about booleans on the ecos-discuss
list (http://ecos.sourceware.org/ml/ecos-discuss/2010-04/msg00035.html).
 There were no comments either way,  so here's a patch.  It should
mean that all booleans end up using GCC's _Bool type, instead of a mix
of _Bool and int.  It showed up a couple of places where a function
prototype didn't match the implementation, and this patch fixes them.

Do others think that there was a problem with boolean definitions, and
is this an appropriate fix?

Alan Bowman

[-- Attachment #2: bool_patch_hg --]
[-- Type: application/octet-stream, Size: 3326 bytes --]

diff -r ae816c83f082 -r bcbae058c6de packages/hal/common/current/include/drv_api.h
--- a/packages/hal/common/current/include/drv_api.h	Tue May 11 16:26:19 2010 +0000
+++ b/packages/hal/common/current/include/drv_api.h	Wed May 12 17:27:29 2010 +0100
@@ -126,7 +126,7 @@
 typedef cyg_uint32   cyg_priority_t;        /* type for priorities        */
 typedef cyg_uint32   cyg_vector_t;          /* Interrupt vector id        */
 typedef cyg_uint32   cyg_cpu_t;             /* CPU id                     */
-typedef int          cyg_bool_t;            
+typedef cyg_bool     cyg_bool_t;            
 typedef cyg_int32    cyg_code_t;            /* type for various codes     */
 
 typedef cyg_uint32 cyg_ISR_t( cyg_vector_t vector, cyg_addrword_t data);
diff -r ae816c83f082 -r bcbae058c6de packages/hal/common/current/src/drv_api.c
--- a/packages/hal/common/current/src/drv_api.c	Tue May 11 16:26:19 2010 +0000
+++ b/packages/hal/common/current/src/drv_api.c	Wed May 12 17:27:29 2010 +0100
@@ -440,7 +440,7 @@
 // wakeup only happens if there is a thread actually waiting on the CV
 // when the signal is sent.
 
-externC cyg_bool cyg_drv_cond_wait( cyg_drv_cond_t *cond )
+externC cyg_bool_t cyg_drv_cond_wait( cyg_drv_cond_t *cond )
 {
     CYG_REPORT_FUNCTION();
 
diff -r ae816c83f082 -r bcbae058c6de packages/infra/current/include/cyg_type.h
--- a/packages/infra/current/include/cyg_type.h	Tue May 11 16:26:19 2010 +0000
+++ b/packages/infra/current/include/cyg_type.h	Wed May 12 17:27:29 2010 +0100
@@ -135,7 +135,8 @@
 #endif
 
 #ifndef cyg_halbool
-# define cyg_halbool int
+# include <stdbool.h>
+# define cyg_halbool _Bool
 #endif
 
 #ifndef cyg_halatomic
@@ -168,7 +169,9 @@
 
 #ifndef __cplusplus
 
+# ifndef bool
 typedef cyg_halbool bool;
+# endif
 
 # ifndef false
 #  define false 0
diff -r ae816c83f082 -r bcbae058c6de packages/kernel/current/include/kapi.h
--- a/packages/kernel/current/include/kapi.h	Tue May 11 16:26:19 2010 +0000
+++ b/packages/kernel/current/include/kapi.h	Wed May 12 17:27:29 2010 +0100
@@ -80,7 +80,7 @@
 
 typedef cyg_uint64 cyg_tick_count_t;
 
-typedef int cyg_bool_t;
+typedef cyg_bool cyg_bool_t;
 
 /* Exception handler function definition                                     */
 typedef void cyg_exception_handler_t(
diff -r ae816c83f082 -r bcbae058c6de packages/kernel/current/src/common/kapi.cxx
--- a/packages/kernel/current/src/common/kapi.cxx	Tue May 11 16:26:19 2010 +0000
+++ b/packages/kernel/current/src/common/kapi.cxx	Wed May 12 17:27:29 2010 +0100
@@ -950,7 +950,7 @@
 #endif
 
 
-externC int cyg_semaphore_trywait( cyg_sem_t *sem ) __THROW
+externC cyg_bool_t cyg_semaphore_trywait( cyg_sem_t *sem ) __THROW
 {
     return ((Cyg_Counting_Semaphore *)sem)->trywait();
 }
diff -r ae816c83f082 -r bcbae058c6de packages/redboot/current/src/xyzModem.h
--- a/packages/redboot/current/src/xyzModem.h	Tue May 11 16:26:19 2010 +0000
+++ b/packages/redboot/current/src/xyzModem.h	Wed May 12 17:27:29 2010 +0100
@@ -73,7 +73,7 @@
 
 int   xyzModem_stream_open(connection_info_t *info, int *err);    
 void  xyzModem_stream_close(int *err);    
-void  xyzModem_stream_terminate(int method, int (*getc)(void));    
+void  xyzModem_stream_terminate(bool method, int (*getc)(void));    
 int   xyzModem_stream_read(char *buf, int size, int *err);    
 char *xyzModem_error(int err);
 

Re: Boolean typedefs

[Jonathan Larmour]

On 12/05/10 20:47, Alan Bowman wrote:
> A few weeks ago, I posted a query about booleans on the ecos-discuss
> list (http://ecos.sourceware.org/ml/ecos-discuss/2010-04/msg00035.html).
>  There were no comments either way,  so here's a patch.  It should
> mean that all booleans end up using GCC's _Bool type, instead of a mix
> of _Bool and int.  It showed up a couple of places where a function
> prototype didn't match the implementation, and this patch fixes them.
> 
> Do others think that there was a problem with boolean definitions, and
> is this an appropriate fix?

This might be tricky. I remember that early on in eCos development, we
started using GCC's boolean type. We had a problem that the type was
considered differently between GCC's C and C++ front-ends. The result was
that places where they were passed around - particularly in the kapidata.h
stuff - they could end up being either different sizes or aligned
differently in structures.

Now GCC has moved on a lot since then, so this problem may well have gone
away and probably has, but that's what I for one would prefer to have
confidence about - ABI compatibility between C and C++ boolean types. But
is there any way to get that confidence in practice, or is it just going
to have to be a case of "suck it and see"? Do you have any thoughts? Have
you run the kernel tests (particularly the k* ones)?

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Boolean typedefs

[Alan Bowman]

> Now GCC has moved on a lot since then, so this problem may well have gone
> away and probably has, but that's what I for one would prefer to have
> confidence about - ABI compatibility between C and C++ boolean types. But
> is there any way to get that confidence in practice, or is it just going
> to have to be a case of "suck it and see"? Do you have any thoughts? Have
> you run the kernel tests (particularly the k* ones)?

I hadn't considered the difference between C and C++.  I noticed this
as an issue when passing function pointers between non-eCos code (i.e.
using bools from stdbool.h) and eCos code (that was using built-in
bools), and I'm only using C in my application.

I think that there's two issues that are addressed in my patch - the
first is that there are some functions that have different prototypes
(bool/int mixup) that isn't an issue as long as bool typedefs to int,
but is an issue if something else happens.  This seems to me like an
obvious (if minor) thing to fix.

The second issue of which bool to use is one that I've got less
answers for.  I can't provide any real confidence that GCC handles C
and C++ bools in the same way across all platforms.  I am actually
using a slightly older eCos code base than top-of-trunk (or is that
"tip"), but I made sure that my changes applied in a reasonable
manner.  I haven't run any of the tests, although I'll give that a try
as soon as I can get my hands on some development hardware.

Re: Boolean typedefs

[Alan Bowman]

> manner.  I haven't run any of the tests, although I'll give that a try
> as soon as I can get my hands on some development hardware.

I managed to get a few minutes alone with a board, and have run a
random sprinkling of 5 or 6 k* tests, with no failures.  Not (yet) a
comprehensive test, but not an instant disaster either.

Re: Boolean typedefs

[Alan Bowman]

It's been a while, but I've run all of the kernel/k* tests, and a
sample of the others.  There were no failures.

While I have not investigated C\C++ compatibility any further, my
feeling is that this potential problem is less than the definite
problem that can occur with the situation that exists at the moment.
I can't see any reason why the correction of the function prototypes
should not occur too.

What do others think?

Alan