* Boolean typedefs
@ 2010-05-12 19:48 Alan Bowman
2010-05-13 13:42 ` Jonathan Larmour
0 siblings, 1 reply; 5+ messages in thread
From: Alan Bowman @ 2010-05-12 19:48 UTC (permalink / raw)
To: ecos-patches
[-- 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);
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Boolean typedefs
2010-05-12 19:48 Boolean typedefs Alan Bowman
@ 2010-05-13 13:42 ` Jonathan Larmour
2010-05-13 14:16 ` Alan Bowman
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Larmour @ 2010-05-13 13:42 UTC (permalink / raw)
To: Alan Bowman; +Cc: ecos-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Boolean typedefs
2010-05-13 13:42 ` Jonathan Larmour
@ 2010-05-13 14:16 ` Alan Bowman
2010-05-13 14:59 ` Alan Bowman
0 siblings, 1 reply; 5+ messages in thread
From: Alan Bowman @ 2010-05-13 14:16 UTC (permalink / raw)
To: ecos-patches
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Boolean typedefs
2010-05-13 14:16 ` Alan Bowman
@ 2010-05-13 14:59 ` Alan Bowman
2010-07-30 10:14 ` Alan Bowman
0 siblings, 1 reply; 5+ messages in thread
From: Alan Bowman @ 2010-05-13 14:59 UTC (permalink / raw)
To: ecos-patches
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Boolean typedefs
2010-05-13 14:59 ` Alan Bowman
@ 2010-07-30 10:14 ` Alan Bowman
0 siblings, 0 replies; 5+ messages in thread
From: Alan Bowman @ 2010-07-30 10:14 UTC (permalink / raw)
To: ecos-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-07-30 10:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-12 19:48 Boolean typedefs Alan Bowman
2010-05-13 13:42 ` Jonathan Larmour
2010-05-13 14:16 ` Alan Bowman
2010-05-13 14:59 ` Alan Bowman
2010-07-30 10:14 ` Alan Bowman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).