stdbool.h and lcc 
Author Message
 stdbool.h and lcc

stdbool.h is a new addendum to C99, and defines at least bool,
true, false.

===== BACKGROUND - question follows at end ======

I was glad to see it implemented in LCC-win32, ver 3.2, available
at:

    http://www.*-*-*.com/ .{*filter*}ia.edu/~lcc-win32/

and used it in my code.  The usage, in one file, is of the form:

   #include "thisfile.h"
   bool myfunction(whatever)
   {
       ....
       if (something) return true;
       else           return false;
   }

with among other things
   /* thisfile.h */
   #include <stdbool.h>
   ...

and, in another file

   #include "thisfile.h"

   bool status;
   ...
   status = myfunction(foo);
   ...

and the system returns a compile time error on the assignment to
status.  On looking at the system file stdbool.h, I find a direct
copy from the draft C99 std N869, which includes a

   #define bool _Bool

or some such (still a direct copy from N869).  I find NO
definition of _Bool anywhere in the system files.  So my fixup is
to add, after the #include <stdbool.h> in thisfile.h:

   #undef bool
   #define bool int

and everything works.

======= End of BACKGROUND =====

The QUESTION is: am I missing something, or does LCC contain a
fundamental insect, which should be reported and fixed.
--

      http://www.*-*-*.com/
     (Remove "NOSPAM." from reply address. Above works unmodified)

--



Tue, 10 Jun 2003 04:40:43 GMT  
 stdbool.h and lcc

[...speaking of a recent lcc version...]

Quote:
> On looking at the system file stdbool.h, I find a direct
> copy from the draft C99 std N869, which includes a

>    #define bool _Bool

> or some such (still a direct copy from N869).  I find NO
> definition of _Bool anywhere in the system files.

There should be none.  _Bool is a reserved word in C99, like
`int' or `char', not a typedef or a #define.

Quote:
>   So my fixup is
> to add, after the #include <stdbool.h> in thisfile.h:

>    #undef bool
>    #define bool int

If LCC has C99 header files to some extent but not C99 support in
the compiler then I could see how this would work.

Quote:
> The QUESTION is: am I missing something, or does LCC contain a
> fundamental insect, which should be reported and fixed.

Sounds to me like not all of its parts are in sync with each
other yet wrt C99 compliance.  Not a big surprise, really: C99 is
a pretty big change from C89 in some areas.
--
"When in doubt, treat ``feature'' as a pejorative.
 (Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, _Software Tools_
--



Wed, 11 Jun 2003 06:41:58 GMT  
 stdbool.h and lcc
CBFalconer a crit dans le message ...

Quote:
>stdbool.h is a new addendum to C99, and defines at least bool,
>true, false.

<lcc supposed bug snipped>

Quote:
>The QUESTION is: am I missing something, or does LCC contain a
>fundamental insect, which should be reported and fixed.

Wrong question. The Good Question is "What's wrong with 0 and 1?"
Forget that bool crap. Save your typings.

--
-hs-    Tabs out, spaces in.
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
FAQ de FCLC : http://www.isty-info.uvsq.fr/~rumeau/fclc
--



Wed, 11 Jun 2003 06:42:49 GMT  
 stdbool.h and lcc

Quote:
>    #include "thisfile.h"
>    bool myfunction(whatever)
>    {
>        ....
>        if (something) return true;
>        else           return false;
>    }
> with among other things
>    /* thisfile.h */
>    #include <stdbool.h>
>    ...
> and, in another file
>    #include "thisfile.h"

>    bool status;
>    ...
>    status = myfunction(foo);
>    ...
> and the system returns a compile time error on the assignment to
> status.

what's the error?

Quote:
> I find NO
> definition of _Bool anywhere in the system files.

which should be expected.  _Bool is a keyword.  do you expect to find a
definition of int or return in your system files, too?

Quote:
> So my fixup is
> to add, after the #include <stdbool.h> in thisfile.h:
>    #undef bool
>    #define bool int
> and everything works.

strange.

Quote:
> The QUESTION is: am I missing something, or does LCC contain a
> fundamental insect, which should be reported and fixed.

what's the error?

--
 /"\                                                 m i k e   b u r r e l l

  X        AGAINST HTML MAIL,

--



Wed, 11 Jun 2003 06:42:52 GMT  
 stdbool.h and lcc

in comp.lang.c:

Quote:
> stdbool.h is a new addendum to C99, and defines at least bool,
> true, false.

> ===== BACKGROUND - question follows at end ======

> I was glad to see it implemented in LCC-win32, ver 3.2, available
> at:

>     http://www.*-*-*.com/ .{*filter*}ia.edu/~lcc-win32/

> and used it in my code.  The usage, in one file, is of the form:

>    #include "thisfile.h"
>    bool myfunction(whatever)
>    {
>        ....
>        if (something) return true;
>        else           return false;
>    }

> with among other things
>    /* thisfile.h */
>    #include <stdbool.h>
>    ...

> and, in another file

>    #include "thisfile.h"

>    bool status;
>    ...
>    status = myfunction(foo);
>    ...

> and the system returns a compile time error on the assignment to
> status.  On looking at the system file stdbool.h, I find a direct
> copy from the draft C99 std N869, which includes a

>    #define bool _Bool

> or some such (still a direct copy from N869).  I find NO
> definition of _Bool anywhere in the system files.  So my fixup is
> to add, after the #include <stdbool.h> in thisfile.h:

>    #undef bool
>    #define bool int

> and everything works.

> ======= End of BACKGROUND =====

> The QUESTION is: am I missing something, or does LCC contain a
> fundamental insect, which should be reported and fixed.

Well, you do have one misunderstanding.  You won't find a macro
definition or typedef for _Bool in a compiler that supports it
according to C99 because _Bool is **not** a macro or typedef, it is a
new fundamental type, just like char, int, or long.  Specifically it
is an unsigned integer type.

So having a C99 conforming <stdbool.h> header that defines bool as a
macro for _Bool is useless without a C99 conforming compiler that
supplies an fundamental _Bool type.  Apparently the header is ahead
(no pun intended) of the compiler itself.

Jack Klein
--
Home: http://www.*-*-*.com/
--



Wed, 11 Jun 2003 06:43:35 GMT  
 stdbool.h and lcc

Quote:

> CBFalconer a crit dans le message ...
> >stdbool.h is a new addendum to C99, and defines at least bool,
> >true, false.

> <lcc supposed bug snipped>

> >The QUESTION is: am I missing something, or does LCC contain a
> >fundamental insect, which should be reported and fixed.

> Wrong question. The Good Question is "What's wrong with 0 and 1?"
> Forget that bool crap. Save your typings.

Kind of a harsh way to put it, but it echos my sentiments on reading
about _Bool in the standard: why is it so ugly; and more importantly,
why is it worth adding complexity to the language?

--
--Ed Cashin                     integrit file-verification system:

    Note: If you want me to send you email, don't munge your address.
--



Thu, 12 Jun 2003 09:20:08 GMT  
 stdbool.h and lcc

Quote:
> stdbool.h is a new addendum to C99, and defines at least bool,
> true, false.

> ===== BACKGROUND - question follows at end ======

> I was glad to see it implemented in LCC-win32, ver 3.2, available
> at:

>     http://www.*-*-*.com/ .{*filter*}ia.edu/~lcc-win32/

> and used it in my code.  The usage, in one file, is of the form:

>    #include "thisfile.h"
>    bool myfunction(whatever)
>    {
>        ....
>        if (something) return true;
>        else           return false;
>    }

> with among other things
>    /* thisfile.h */
>    #include <stdbool.h>
>    ...

> and, in another file

>    #include "thisfile.h"

>    bool status;
>    ...
>    status = myfunction(foo);
>    ...

> and the system returns a compile time error on the assignment to
> status.  On looking at the system file stdbool.h, I find a direct
> copy from the draft C99 std N869, which includes a

>    #define bool _Bool

> or some such (still a direct copy from N869).  I find NO
> definition of _Bool anywhere in the system files.  So my fixup is
> to add, after the #include <stdbool.h> in thisfile.h:

>    #undef bool
>    #define bool int

> and everything works.

> ======= End of BACKGROUND =====

> The QUESTION is: am I missing something, or does LCC contain a
> fundamental insect, which should be reported and fixed.
> --

>       http://www.*-*-*.com/
>      (Remove "NOSPAM." from reply address. Above works unmodified)

> --


Nothing wrong with the _Bool in LCC.  It works just fine without your little
botch.  As others have mentioned, _Bool is a primative data type and
requires no definition in any header file any more then int does.  I have
LCC 3.2, _Bool works, bool works, it all works.  Jacob dun a good job. :-)
Ross
--



Thu, 12 Jun 2003 09:20:46 GMT  
 stdbool.h and lcc

Quote:

>> Wrong question. The Good Question is "What's wrong with 0 and 1?"
>> Forget that bool crap. Save your typings.

It's the same argument over whether to use 0 or NULL for null pointers.
The argument in favor of bool, true, and false is better internal
documentation of the code; it's clearer that a given value is a boolean
rather than a scalar.  It also allows the compiler to optimize bool in
some circumstances.

Quote:
> Kind of a harsh way to put it, but it echos my sentiments on reading
> about _Bool in the standard: why is it so ugly; and more importantly,
> why is it worth adding complexity to the language?

_Bool is very ugly, but you should never have to use it.  Just include
<stdbool.h> and use bool.  _Bool is only there for backwards compatibility
problems.

--

--



Sat, 14 Jun 2003 03:40:08 GMT  
 stdbool.h and lcc

Quote:



> > Kind of a harsh way to put it, but it echos my sentiments on reading
> > about _Bool in the standard: why is it so ugly; and more importantly,
> > why is it worth adding complexity to the language?

> _Bool is very ugly, but you should never have to use it.  Just include
> <stdbool.h> and use bool.  _Bool is only there for backwards compatibility
> problems.

Seems to me the intent is to make bool, true and false proper
keywords in some future standard.

n869:

    "7.26 Future library directions

     ...

     7.26.7 Boolean type and values <stdbool.h>

  1  The ability to undefine and perhaps then redefine the
     macros bool, true, and false is an obsolescent feature."

  --n
--



Sat, 14 Jun 2003 16:21:36 GMT  
 stdbool.h and lcc

Quote:


> > _Bool is very ugly, but you should never have to use it.  Just include
> > <stdbool.h> and use bool.  _Bool is only there for backwards compatibility
> > problems.
> Seems to me the intent is to make bool, true and false proper
> keywords in some future standard.

Possibly, as (I think) C++ has done.  The main idea was to
standardize something that everybody was doing in various
different ways.  There is a macro that can be tested before
#including <stdbool.h> to avoid trying to redefine bool,
true, and false if some other header has already provided
definitions.  As Russ said, people are expected to use
bool (via the header) rather than _Bool.

Note that _Bool needn't match an existing C89 integer type
but could be yet another integer type of its own, occupying
some integral number of "bytes".  So it's not possible for
it to be a 1-bit type for densely packed arrays of _Bool.
This is obviously not an ideal feature (on several counts),
but it was constrained by compatibility with already decided
properties of C and with existing usage by applications.

        - DAGwyn
--



Mon, 16 Jun 2003 14:05:54 GMT  
 stdbool.h and lcc


Quote:
>Note that _Bool needn't match an existing C89 integer type
>but could be yet another integer type of its own, occupying
>some integral number of "bytes".

_Bool _is_ a type of its own, it freely converts to other integer types
and almost certainly has a layout similar to some type of char but,
AFAIK, there are no requirements that it be layout compatible with any
form of char, or any other integer type.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
--



Tue, 17 Jun 2003 02:36:22 GMT  
 stdbool.h and lcc

Quote:

> _Bool _is_ a type of its own, ...

Yes, what I meant was that its representation doesn't necessarily
match any of the other integer types.
--



Tue, 17 Jun 2003 13:29:19 GMT  
 stdbool.h and lcc
Hi

I am the guy developing lcc-win32.


Quote:

> [...speaking of a recent lcc version...]
> > On looking at the system file stdbool.h, I find a direct
> > copy from the draft C99 std N869, which includes a

> >    #define bool _Bool

> > or some such (still a direct copy from N869).  I find NO
> > definition of _Bool anywhere in the system files.

Yes, I included the standard file, as the standard recommends. What is wrong
with this??? _Bool is now a compiler intrinsic type like int or double. The
user visible type is bool, not _Bool. Just include that stdbool.h and be
done with it.

There is no further definition needed. I have choosen
sizeof(_Bool) == 1
Since it would be weird to have
sizeof(_Bool) == 0.125 (1 bit :-)

Quote:

> There should be none.  _Bool is a reserved word in C99, like
> `int' or `char', not a typedef or a #define.

Exactly
> >   So my fixup is
> > to add, after the #include <stdbool.h> in thisfile.h:

> >    #undef bool
> >    #define bool int

NO!!!
DO NOT DO THAT!
This will{*filter*}everything completely!
There are SEMANTIC differences between int and bool, as implemented in
lcc-win32.

For instance
    bool b = 7;
    printf("%d\n",b);

will print
1
and NOT 7!!!!!
I FORCE all boolean values to either zero or one. I generate now code
(hopefully without bugs) to ignore all values other than zero or one for
boolean variables.

Quote:
> If LCC has C99 header files to some extent but not C99 support in
> the compiler then I could see how this would work.

Well, I added the header files after upgrading the compiler of course. I am
not THAT stupid!

Quote:
> > The QUESTION is: am I missing something, or does LCC contain a
> > fundamental insect, which should be reported and fixed.

A "fundamental insect"???
Mmm my English is not advanced enough. (Sorry, I'm French :-) What do you
mean?

Quote:

> Sounds to me like not all of its parts are in sync with each
> other yet wrt C99 compliance.  Not a big surprise, really: C99 is
> a pretty big change from C89 in some areas.

Well, I do what I can. Miracles take longuer please.
My goal is to have ALL C99 running. I have done the boolean stuff, the
floating point environment stuff, I added many new library functions needed
by the standard, I added the complex stuff (albeit implemented in a
non-standard way), etc etc. I work like a fool.

But there are BIG changes there.

Take for instance this bool stuff. It doesn't LOOK like a big deal, but
within the compiler it is quite complex, because ALL possible cases must be
handled, conversions from all other types, etc. Then there is the code
generation! I have implemented internally bools as bytes, since sizeof
requirements.  I have added code to cast all bools to 1, or zero in
assignments, etc. This makes for quite a lot of work just for this one
feature!
--



Wed, 25 Jun 2003 12:24:20 GMT  
 stdbool.h and lcc
**** posted and mailed ****

Quote:

> I am the guy developing lcc-win32.




> > [...speaking of a recent lcc version...]
> > > On looking at the system file stdbool.h, I find a direct
> > > copy from the draft C99 std N869, which includes a

> > >    #define bool _Bool

> > > or some such (still a direct copy from N869).  I find NO
> > > definition of _Bool anywhere in the system files.

> Yes, I included the standard file, as the standard recommends. What is wrong
> with this??? _Bool is now a compiler intrinsic type like int or double. The
> user visible type is bool, not _Bool. Just include that stdbool.h and be
> done with it.

> There is no further definition needed. I have choosen
> sizeof(_Bool) == 1
> Since it would be weird to have
> sizeof(_Bool) == 0.125 (1 bit :-)

> > There should be none.  _Bool is a reserved word in C99, like
> > `int' or `char', not a typedef or a #define.

> Exactly
> > >   So my fixup is
> > > to add, after the #include <stdbool.h> in thisfile.h:

> > >    #undef bool
> > >    #define bool int

> NO!!!
> DO NOT DO THAT!
> This will{*filter*}everything completely!
> There are SEMANTIC differences between int and bool, as implemented in
> lcc-win32.

> For instance
>     bool b = 7;
>     printf("%d\n",b);

> will print
> 1
> and NOT 7!!!!!
> I FORCE all boolean values to either zero or one. I generate now code
> (hopefully without bugs) to ignore all values other than zero or one for
> boolean variables.

> > If LCC has C99 header files to some extent but not C99 support in
> > the compiler then I could see how this would work.

> Well, I added the header files after upgrading the compiler of course. I am
> not THAT stupid!

> > > The QUESTION is: am I missing something, or does LCC contain a
> > > fundamental insect, which should be reported and fixed.

> A "fundamental insect"???
> Mmm my English is not advanced enough. (Sorry, I'm French :-) What do you
> mean?

> > Sounds to me like not all of its parts are in sync with each
> > other yet wrt C99 compliance.  Not a big surprise, really: C99 is
> > a pretty big change from C89 in some areas.

> Well, I do what I can. Miracles take longuer please.
> My goal is to have ALL C99 running. I have done the boolean stuff, the
> floating point environment stuff, I added many new library functions needed
> by the standard, I added the complex stuff (albeit implemented in a
> non-standard way), etc etc. I work like a fool.

> But there are BIG changes there.

> Take for instance this bool stuff. It doesn't LOOK like a big deal, but
> within the compiler it is quite complex, because ALL possible cases must be
> handled, conversions from all other types, etc. Then there is the code
> generation! I have implemented internally bools as bytes, since sizeof
> requirements.  I have added code to cast all bools to 1, or zero in
> assignments, etc. This makes for quite a lot of work just for this one
> feature!

I had no wish to do that - here is the original message.  I
expected everything to work without the kluge.  BTW, "fundamental
insect" means bug.  All in all LCC seems to be a very nice package
- I just wish it was easier to see full file names.

When I wrote it I did not realize that _Bool was a reserved word
in C99

-------- original message follows, dated 20 Dec 2000 12:36:52
---------

stdbool.h is a new addendum to C99, and defines at least bool,
true, false.

===== BACKGROUND - question follows at end ======

I was glad to see it implemented in LCC-win32, ver 3.2, available
at:

    http://www.*-*-*.com/ .{*filter*}ia.edu/~lcc-win32/

and used it in my code.  The usage, in one file, is of the form:

   #include "thisfile.h"
   bool myfunction(whatever)
   {
       ....
       if (something) return true;
       else           return false;
   }

with among other things
   /* thisfile.h */
   #include <stdbool.h>
   ...

and, in another file

   #include "thisfile.h"

   bool status;
   ...
   status = myfunction(foo);
   ...

and the system returns a compile time error on the assignment to
status.  On looking at the system file stdbool.h, I find a direct
copy from the draft C99 std N869, which includes a

   #define bool _Bool

or some such (still a direct copy from N869).  I find NO
definition of _Bool anywhere in the system files.  So my fixup is
to add, after the #include <stdbool.h> in thisfile.h:

   #undef bool
   #define bool int

and everything works.

======= End of BACKGROUND =====

The QUESTION is: am I missing something, or does LCC contain a
fundamental insect, which should be reported and fixed.

------------- end of original message ------------
Note that stdbool is included in thisfile.h, and thus in both
source files.

Unfortunate I cannot cut and patch from the error window, but this
is what appeared (more or less)

warning ... unsigned operand of unary -
ASGNBOOL(1)Error <filename>:13 Compiler error in _kids--
Bad rule number 0

The warning appears in compilation, and should not be a problem.
The ASGNBOOL apparently appears during the link phase.

this is the line that creates the warning:

         if (negative && (value <= 32768u)) *val = -value;

If you wish I can pack the whole thing up and send it to you.  It
is very early in this project and the result is small.

You say you ignore anything other than 0 or 1 for a bool in the
generated code.  I suggest you modify that slightly to use the low
order bit.  The result would work with packed fields, etc.  From
experience with a Pascal implementation, the only place to worry
about is on generation of the value - there the problem is to make
sure the ord(boolean), pred, succ functions work correctly, as I
recall.

I quite appreciate the effort involved in making the _Bool type
work correctly.  Been there - done that.

Please despam the 2nd address below for direct correspondence.

Merci

--


http://www.*-*-*.com/
   (Remove "NOSPAM." from reply address. my-deja works unmodified)

--



Thu, 26 Jun 2003 12:50:14 GMT  
 stdbool.h and lcc

Quote:

> and the system returns a compile time error on the assignment to
> status.

Most likely, "thisfile.h" does not contain a correct prototype
for myfunction.
--



Sun, 29 Jun 2003 12:39:40 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. stdbool.h and lcc

2. lcc-win32's editor

3. CFV: comp.compilers.lcc

4. RFD: comp.compilers.lcc

5. lcc win32 compiler

6. Sample graphics and MIDI programs in LCC-Win32

7. Don't know how to use Lcc-Win32

8. LCC Win32 specific

9. RFD: comp.compilers.lcc

10. Need help on LCC WIN32 compiler.

11. dos.h library missing in LCC-win32?????

12. lcc wont run dos

 

 
Powered by phpBB® Forum Software