Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #41668 > unrolled thread

Is goto Still Considered Harmful?

Back to article view | Back to comp.lang.c

Contents

  Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 11:02 -0500
    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 12:17 -0400
    Re: Is goto Still Considered Harmful? nospam@see.signature (Richard Maine) - 2014-03-12 09:20 -0700
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:30 -0500
        Re: Is goto Still Considered Harmful? Geoff <geoff@invalid.invalid> - 2014-03-18 17:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 07:34 -0400
            Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-19 12:08 +0000
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 10:07 -0400
                Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-19 17:05 +0100
              Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:27 -0500
        Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-19 20:35 +1100
          Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:26 -0500
    Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 16:47 +0000
      Re: Is goto Still Considered Harmful? Jos Bergervoet <jos.bergervoet@xs4all.nl> - 2014-03-12 19:07 +0100
        Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-12 23:36 +0000
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 00:23 +0000
            Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 01:18 +0000
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 02:08 +0000
                Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 02:21 +0000
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:17 +0100
          Re: Is goto Still Considered Harmful? Melzzzzz <mel@zzzzz.invalid> - 2014-03-13 01:53 +0100
        Re: Is goto Still Considered Harmful? Les Cargill <lcargill99@comcast.com> - 2014-03-13 01:46 -0500
      Re: Is goto Still Considered Harmful? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-13 10:56 +0100
      Re: Is goto Still Considered Harmful? "Nasser M. Abbasi" <nma@12000.org> - 2014-03-16 08:18 -0500
        Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-16 15:18 +0000
          Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-20 11:36 -0700
    Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-12 18:50 +0000
      Re: Is goto Still Considered Harmful? <william@wilbur.25thandClement.com> - 2014-03-12 12:49 -0700
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-12 21:54 +0000
        Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 16:57 -0500
        Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 15:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 19:02 -0400
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:58 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 20:09 -0400
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:44 -0700
        Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-12 23:40 -0500
          Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:25 +0100
          Re: Is goto Still Considered Harmful? Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-03-14 11:24 +0100
            Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-14 23:32 -0500
            Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 13:43 +0000
              Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-15 16:28 +0100
                Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 16:01 +0000
                  Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-17 08:51 +0100
      Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:22 +0100
    Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-03-12 15:34 -0500
    Re: Is goto Still Considered Harmful? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-03-12 17:48 -0700
    Re: Is goto Still Considered Harmful? jt@toerring.de (Jens Thoms Toerring) - 2014-03-13 01:06 +0000
      Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 03:59 -0400
        Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 05:02 -0400
          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-13 08:42 -0400
            Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-13 14:45 +0000
      Re: Is goto Still Considered Harmful? Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2014-03-13 07:42 -0600
        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-13 14:56 +0100
    Re: Is goto Still Considered Harmful? Wolfgang Kilian <kilian@invalid.com> - 2014-03-13 09:10 +0100
    Re: Is goto Still Considered Harmful? mark.bluemel@gmail.com - 2014-03-13 08:02 -0700
    Re: Is goto Still Considered Harmful? Thomas Koenig <tkoenig@netcologne.de> - 2014-03-13 21:09 +0000
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-13 21:24 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-13 22:36 +0000
          Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:02 -0500
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 04:07 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:56 -0500
            Re: Is goto Still Considered Harmful? helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) - 2014-03-14 09:17 +0000
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 22:42 +0000
        Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 17:13 -0600
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-13 16:46 -0700
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 01:17 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:04 -0500
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 10:41 +0100
                  Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 09:55 +0000
                    Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 13:16 +0100
                    Re: Is goto Still Considered Harmful? Seebs <usenet-nospam@seebs.net> - 2014-03-18 21:08 +0000
                      Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-18 17:41 -0400
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 00:45 +0000
            Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 21:40 -0600
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 01:02 -0400
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:36 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:30 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:51 -0400
                    Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-14 13:12 -0700
                  Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 06:46 -0700
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:29 +0000
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:47 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:43 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:52 -0400
              Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-16 17:15 -0500
                Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-16 16:04 -0700
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:11 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 06:00 +0000
    Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-14 08:32 +1100
      Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-14 23:10 -0400
    Re: Is goto Still Considered Harmful? Rosario193 <Rosario@invalid.invalid> - 2014-03-14 02:18 +0100
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:14 -0500
    Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 07:52 -0700
      Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-24 11:20 -0400
        Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 17:08 +0000
        Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-25 14:06 -0400
          Re: Is goto Still Considered Harmful? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-03-26 13:31 -0400
      Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-24 16:31 +0000
      Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 16:46 +0000
        Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 16:10 -0700
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-24 17:19 -0700
            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 02:56 -0700
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-25 07:34 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 10:57 -0400
                Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-25 16:09 +0000
                Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-25 16:14 +0000
                  Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-03-26 08:06 +1300
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 12:49 -0700
                  Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 14:05 -0500
                    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 15:20 -0400
                      Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-04 14:56 -0500
                        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-04 17:11 -0400
                          Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 12:03 +1300
                          Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-04-05 00:17 -0500
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 20:14 +1300
                          Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-09 14:30 -0500
                            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-09 16:37 -0400
                              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-09 14:01 -0700
                        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-04-05 15:21 +0100
                    Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 11:04 +1300
                      Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 02:45 +0300
                        Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 13:03 +1300
                          Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 12:01 +0300
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-05-22 21:22 +1200
                        Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 11:53 +0300
                Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 12:10 -0400
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 10:39 -0700
                    Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 13:42 -0500
                      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 15:16 -0700
                        Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 00:24 -0700
                          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-04-01 08:26 -0400
                            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 06:50 -0700
                              Re: Are setters Stil Considered Harmful? (was: Is goto Still Considered Harmful?) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-02 10:49 -0700
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:30 +0000
                Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-27 09:33 -0400
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:37 +0000
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 00:30 -0400
          Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-27 11:47 -0700
            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-27 20:39 -0400
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 01:40 +0000
            Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-28 10:09 +0100
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 09:48 +0000
              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-28 03:24 -0700
                Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-28 18:52 +0000
                Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-30 02:45 -0700
      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-24 12:53 -0700
      Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 15:02 -0700
        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-24 19:11 -0400
    Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 05:56 -0700

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#41794

On Fri, 14 Mar 2014 04:07:05 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>In comp.lang.c Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>(snip, I wrote)
>>>Stories are that COMEFROM was once added to a PL/I compiler, I
>>>don't know about any Fortran compilers.  
>
>>>Especially interesting for Fortran would be the computed COMEFROM
>>>statement.
> 
>> AFAIK, the COMEFROM "statement" was from a humorous Datamation article
>> published in the late 70s during much of the structure programming
>> debate.  Makes me miss the old "Fortran Man" cartoons in that
>> publication...
>
>When I was in high school, so about 1975, I used to sometimes
>read Datamation in our city library. I think that is when I
>saw the one about the PL/I compiler. 


Of course there's a Wikipedia article...

https://en.wikipedia.org/wiki/COMEFROM

Apparently the Datamation article was in 1973.  Apparently we both
need to feel older...

[toc] | [prev] | [next] | [standalone]

#41800

In article <0lv4i95qk7qttjoia83k8hoditjpb3gh4o@4ax.com>, Robert Wessel
<robertwessel2@yahoo.com> writes: 

> AFAIK, the COMEFROM "statement" was from a humorous Datamation article
> published in the late 70s during much of the structure programming
> debate.  Makes me miss the old "Fortran Man" cartoons in that
> publication...

Time to post these again:

   http://www.pbm.com/~lindahl/real.programmers.html

and, of course, 

   http://www.pbm.com/~lindahl/mel.html

[toc] | [prev] | [next] | [standalone]

#41783

On 2014-03-13, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Remove debugging, and your program does something quite different.
>
>   In Java,
>
> boolean var = false;
> assert var = true;
> if( var )...

Why bring up Java; we have that in C:

  assert (var = true); /* doesn't happen if NDEBUG is on */

[toc] | [prev] | [next] | [standalone]

#41784

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20140313153944.695@kylheku.com...

> Why bring up Java; we have that in C:

>  assert (var = true); /* doesn't happen if NDEBUG is on */

At last!  A C programmer to inflict the Question on!  Now, what if
true is a const _Bool with internal representation B'00000010'
and var is also an _Bool.  Does the assert happen if NDEBUG is not
on?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[toc] | [prev] | [next] | [standalone]

#41786

"James Van Buskirk" <not_valid@comcast.net> writes:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
> news:20140313153944.695@kylheku.com...
>
>> Why bring up Java; we have that in C:
>
>>  assert (var = true); /* doesn't happen if NDEBUG is on */
>
> At last!  A C programmer to inflict the Question on!  Now, what if
> true is a const _Bool with internal representation B'00000010'
> and var is also an _Bool.  Does the assert happen if NDEBUG is not
> on?

Since `var = true` is an assignment, yes, the assert will fire.

Let's assume that the `= true` is replaced by `== true` (though it would
be better to omit it altogether and write `assert(var);`).

If there's a visible `#include <stdbool.h>` directive, then `true` is a
macro that expands to 1, so to satisfy your assumptions we have to
assume that the programmer has (foolishly) redefined `true` -- but how?

Converting any scalar value to _Bool yields 0 if the value is equal to
0, 1 if it's not, which makes it difficult to construct a _Bool value
other than 0 or 1.

If you manage do so, it's likely that your program's behavior has become
undefined while doing so, which means the assert happen, or it may not
happen, or the walls might start to bleed.

The simple answer is: Don't do that.

But if you want an answer beyond that, I suggest you show the specific C
code you're asking about.

(Incidentally, B'00000010' is not C syntax, but it's obvious enough what
you mean.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#41788

In comp.lang.c Keith Thompson <kst-u@mib.org> wrote:

(snip)

> (Incidentally, B'00000010' is not C syntax, but it's obvious 
> enough what you mean.)

It is, as far as I know, OS/360 (and successor) assembler syntax.

I more often use the hex constant X'123' syntax when describing
hex constants in a language independent context. 

PL/I syntax for binary constants is 00000010B (binary point is
allowed for scaled fixed binary). Leading zeros determine the
precision (bit width) of the constant, which sometimes matters.

Do newer C standards have a syntax for binary constants?

-- glen

[toc] | [prev] | [next] | [standalone]

#41792

On Fri, 14 Mar 2014 01:17:26 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>In comp.lang.c Keith Thompson <kst-u@mib.org> wrote:
>
>(snip)
>
>> (Incidentally, B'00000010' is not C syntax, but it's obvious 
>> enough what you mean.)
>
>It is, as far as I know, OS/360 (and successor) assembler syntax.
>
>I more often use the hex constant X'123' syntax when describing
>hex constants in a language independent context. 
>
>PL/I syntax for binary constants is 00000010B (binary point is
>allowed for scaled fixed binary). Leading zeros determine the
>precision (bit width) of the constant, which sometimes matters.
>
>Do newer C standards have a syntax for binary constants?


Nope.  One would think a trivial to implement addition, breaking no
existing code, with many requests, would get at least a little
attention from the C committee...

[toc] | [prev] | [next] | [standalone]

#41801

On 14/03/14 05:04, Robert Wessel wrote:
> On Fri, 14 Mar 2014 01:17:26 +0000 (UTC), glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
> 
>> In comp.lang.c Keith Thompson <kst-u@mib.org> wrote:
>>
>> (snip)
>>
>>> (Incidentally, B'00000010' is not C syntax, but it's obvious 
>>> enough what you mean.)
>>
>> It is, as far as I know, OS/360 (and successor) assembler syntax.
>>
>> I more often use the hex constant X'123' syntax when describing
>> hex constants in a language independent context. 
>>
>> PL/I syntax for binary constants is 00000010B (binary point is
>> allowed for scaled fixed binary). Leading zeros determine the
>> precision (bit width) of the constant, which sometimes matters.
>>
>> Do newer C standards have a syntax for binary constants?
> 
> 
> Nope.  One would think a trivial to implement addition, breaking no
> existing code, with many requests, would get at least a little
> attention from the C committee...
> 

gcc has binary literals such as 0b00100001 as an extension.  Since it is
in popular use, has an existing implementation, and no signs of
conflicting with existing code, it is probably a good candidate for
future C standards.

And although it is off-topic in both C and Fortran groups, 0b001 style
binary literals are due to be in C++14.

[toc] | [prev] | [next] | [standalone]

#41802

On 2014-03-14, David Brown <david.brown@hesbynett.no> wrote:
> gcc has binary literals such as 0b00100001 as an extension.  Since it is
> in popular use, has an existing implementation, and no signs of
> conflicting with existing code, it is probably a good candidate for
> future C standards.

But of course, the imbeciles will, again, do it in a completely different way
from GCC, like inline and variadic macros, so then, in turn, GCC will have GNU
boolean constants (warned about, if not outright disabled, in -pedantic mode),
and ISO boolean constants. 

[toc] | [prev] | [next] | [standalone]

#41805

On 14/03/14 10:55, Kaz Kylheku wrote:
> On 2014-03-14, David Brown <david.brown@hesbynett.no> wrote:
>> gcc has binary literals such as 0b00100001 as an extension.  Since it is
>> in popular use, has an existing implementation, and no signs of
>> conflicting with existing code, it is probably a good candidate for
>> future C standards.
> 
> But of course, the imbeciles will, again, do it in a completely different way
> from GCC, like inline and variadic macros, so then, in turn, GCC will have GNU
> boolean constants (warned about, if not outright disabled, in -pedantic mode),
> and ISO boolean constants. 
> 

That's possible - the C and C++ committees have an annoying habit of
doing things differently without reasons that are comprehensible to us
mere mortals.  But in this case I think there really are no other ways
to implement binary literals in a manner consistent with existing C.  So
I do hope they will be included in this form in later standards.

[toc] | [prev] | [next] | [standalone]

#41988

On 2014-03-14, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-03-14, David Brown <david.brown@hesbynett.no> wrote:
>> gcc has binary literals such as 0b00100001 as an extension.  Since it is
>> in popular use, has an existing implementation, and no signs of
>> conflicting with existing code, it is probably a good candidate for
>> future C standards.

> But of course, the imbeciles will, again, do it in a completely different way
> from GCC, like inline and variadic macros, so then, in turn, GCC will have GNU
> boolean constants (warned about, if not outright disabled, in -pedantic mode),
> and ISO boolean constants. 

In the case of inline, there were multiple competing implementations of
inline functions. May have been something similar for variadic macros.

Also, back in the 90s, there was pretty poor communication between gcc
people and the ISO committee. (My impression at the time was that this was
not a case with one party clearly at fault, but rather, one of those
complicated social interactions that programmers are so bad at.)

So far as I know, these days, things are much friendlier. Of particular
note, the gcc manual no longer blames ANSI for the behavior of backslashes
in #include directives. In gcc 2.95 or so and earlier, they said:
	 Thus, `#include "x\n\\y"' specifies a filename containing
	 three backslashes. It is not clear why this behavior is
	 ever useful, but the ANSI standard specifies it.
This wasn't actually true, but it stayed in the docs for ages for reasons
not known to me. It appears to be fixed by gcc-3.1 or so.

-s
-- 
Copyright 2013, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
Autism Speaks does not speak for me.  http://autisticadvocacy.org/
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#41991

On 03/18/2014 05:08 PM, Seebs wrote:
...
> Also, back in the 90s, there was pretty poor communication between gcc
> people and the ISO committee. (My impression at the time was that this was
> not a case with one party clearly at fault, but rather, one of those
> complicated social interactions that programmers are so bad at.)

One of the key problems seemed to be that there was little or no overlap
between those two groups. While many ISO committee members were familiar
with gcc, I believe that when C99 was being created, none of them were
gcc developers, and therefore they did not know any details about how it
was implemented. Committee membership is a volunteer activity (and least
in ANSI, the US member of the ISO C committee, which has a greatly
disproportionate amount of influence on the C committee), and I get the
impression that volunteers are seldom, if ever, rejected. Therefore, the
absence of gcc developers from the committee has to be attributed to a
failure by those developers to volunteer.

Full voting membership is moderately expensive for an individual,
particularly including the travel requirements, but it's not expensive
enough to prevent many members from being individuals representing only
themselves. Full membership is cheap by the standards of any
organization of reasonable size, and I believe that gcc has a fairly
large number of developers, with international coverage - for most of
the committee's meetings, I'd expect gcc to have at least one developer
within driving distance of the meeting. Even a single non-voting member
of the committee who was a gcc developer would probably have
substantially improved the gcc compatibility of the resulting standard.

[toc] | [prev] | [next] | [standalone]

#41787

["Followup-To:" header set to comp.lang.c.]
On 2014-03-13, James Van Buskirk <not_valid@comcast.net> wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
> news:20140313153944.695@kylheku.com...
>
>> Why bring up Java; we have that in C:
>
>>  assert (var = true); /* doesn't happen if NDEBUG is on */
>
> At last!  A C programmer to inflict the Question on!  Now, what if
> true is a const _Bool with internal representation B'00000010'
> and var is also an _Bool.  Does the assert happen if NDEBUG is not
> on?

The code generated by the assert macro, when NDEBUG is not present, should not
treat this expression any differently than  something like

   if (var = true) ...

The assignment must happen if NDEBUG is absent, and its result tests as
true.

[toc] | [prev] | [next] | [standalone]

#41790

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20140313174032.771@kylheku.com...
> ["Followup-To:" header set to comp.lang.c.]

Posted to clf because the nature of the question is central to
an issue due to Fortran interoperability (_Bool <-> LOGICAL(C_BOOL)).

> On 2014-03-13, James Van Buskirk <not_valid@comcast.net> wrote:

>> At last!  A C programmer to inflict the Question on!  Now, what if
>> true is a const _Bool with internal representation B'00000010'
>> and var is also an _Bool.  Does the assert happen if NDEBUG is not
>> on?

> The code generated by the assert macro, when NDEBUG is not present, should 
> not
> treat this expression any differently than  something like

>   if (var = true) ...

> The assignment must happen if NDEBUG is absent, and its result tests as
> true.

Yes, this last line of code above is perhaps a better illustration
of the issue.  My impression was that assignment between variables
of the same integer type in C was to copy all the bits, and that
the result of the assignment was the value that the variable got
assigned.

But what is that value in this case?  If the low bit of an _Bool
is the only significant bit, then the value of B'00000010' is 0;
if at least the two low bits are significant, then the value is
2, which, being nonzero, is true, and if any value but
B'00000000' and B'00000001' is a trap value, then the value is
undefined.   It seems to me that C99 allows the compiler to
choose any of these behaviors, or does it in fact require one
of them rather than the others?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[toc] | [prev] | [next] | [standalone]

#41795

On 03/13/2014 11:40 PM, James Van Buskirk wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
> news:20140313174032.771@kylheku.com...
>> ["Followup-To:" header set to comp.lang.c.]
> 
> Posted to clf because the nature of the question is central to
> an issue due to Fortran interoperability (_Bool <-> LOGICAL(C_BOOL)).
> 
>> On 2014-03-13, James Van Buskirk <not_valid@comcast.net> wrote:
> 
>>> At last!  A C programmer to inflict the Question on!  Now, what if
>>> true is a const _Bool with internal representation B'00000010'
>>> and var is also an _Bool.  Does the assert happen if NDEBUG is not
>>> on?
> 
>> The code generated by the assert macro, when NDEBUG is not present, should 
>> not
>> treat this expression any differently than  something like
> 
>>   if (var = true) ...
> 
>> The assignment must happen if NDEBUG is absent, and its result tests as
>> true.
> 
> Yes, this last line of code above is perhaps a better illustration
> of the issue.  My impression was that assignment between variables
> of the same integer type in C was to copy all the bits, ...

Not quite - the value of the right operand of an assignment expression
is determined (a process that may involve the usual arithmetic
conversions), and is then converted to the destination type (if
different). A representation of that value in the destination type is
then placed in the destination object. For any type where there are two
or more different ways to represent the same value, there's no guarantee
as to which of those ways gets chosen; it needn't be the same as the
representation used in the source object, even if they have exactly the
same type. Even if the value and sign bits are the same, the values of
the padding bits (if any) can be completely different.

> ... and that
> the result of the assignment was the value that the variable got
> assigned.
> 
> But what is that value in this case?  If the low bit of an _Bool
> is the only significant bit, then the value of B'00000010' is 0;
> if at least the two low bits are significant, then the value is
> 2, which, being nonzero, is true, and if any value but
> B'00000000' and B'00000001' is a trap value, then the value is
> undefined.   It seems to me that C99 allows the compiler to
> choose any of these behaviors, or does it in fact require one
> of them rather than the others?

A _Bool is only required to be able to store two values: 0 and 1, a
requirement that can be met by having 1 value bit and 7 padding bits.
Whether _Bool can store larger values is unspecified. Larger values
can't be assigned to a _Bool object, because conversion to _Bool is part
of the assignment process. Such values, if they can be stored, could
only be created by type punning.
The standard also doesn't specify that any particular bit must be the
value bit - in principle, the single bit that is set in B'00000010'
could be the only bit used by _Bool, though that seems unlikely.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#41808

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:lfu2h6$btd$1@dont-email.me...

> On 03/13/2014 11:40 PM, James Van Buskirk wrote:

>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> news:20140313174032.771@kylheku.com...
>>> ["Followup-To:" header set to comp.lang.c.]

>> Posted to clf because the nature of the question is central to
>> an issue due to Fortran interoperability (_Bool <-> LOGICAL(C_BOOL)).

>>> On 2014-03-13, James Van Buskirk <not_valid@comcast.net> wrote:

>>>> At last!  A C programmer to inflict the Question on!  Now, what if
>>>> true is a const _Bool with internal representation B'00000010'
>>>> and var is also an _Bool.  Does the assert happen if NDEBUG is not
>>>> on?

>>> The code generated by the assert macro, when NDEBUG is not present, 
>>> should
>>> not
>>> treat this expression any differently than  something like

>>>   if (var = true) ...

>>> The assignment must happen if NDEBUG is absent, and its result tests as
>>> true.

>> Yes, this last line of code above is perhaps a better illustration
>> of the issue.  My impression was that assignment between variables
>> of the same integer type in C was to copy all the bits, ...

> Not quite - the value of the right operand of an assignment expression
> is determined (a process that may involve the usual arithmetic
> conversions), and is then converted to the destination type (if
> different).

Part of the premise of this subthread is that both left and right
operands have the same intrinsic type, _Bool.  See above.
In n1124.pdf, section 6.3 I read:

"Conversion of an operand value to a compatible type causes no
change to the value or the representation."

Doesn't that mean that the compiler is just supposed to copy
bits?

>             A representation of that value in the destination type is
> then placed in the destination object. For any type where there are two
> or more different ways to represent the same value, there's no guarantee
> as to which of those ways gets chosen; it needn't be the same as the
> representation used in the source object, even if they have exactly the
> same type. Even if the value and sign bits are the same, the values of
> the padding bits (if any) can be completely different.

As noted above, this is inconsistent with my understanding of
the passage quoted above.

>> ... and that
>> the result of the assignment was the value that the variable got
>> assigned.

>> But what is that value in this case?  If the low bit of an _Bool
>> is the only significant bit, then the value of B'00000010' is 0;
>> if at least the two low bits are significant, then the value is
>> 2, which, being nonzero, is true, and if any value but
>> B'00000000' and B'00000001' is a trap value, then the value is
>> undefined.   It seems to me that C99 allows the compiler to
>> choose any of these behaviors, or does it in fact require one
>> of them rather than the others?

> A _Bool is only required to be able to store two values: 0 and 1, a
> requirement that can be met by having 1 value bit and 7 padding bits.
> Whether _Bool can store larger values is unspecified. Larger values
> can't be assigned to a _Bool object, because conversion to _Bool is part
> of the assignment process.

But it seems to me that they can when assigning from _Bool to
_Bool.

>                            Such values, if they can be stored, could
> only be created by type punning.

Creating the first _Bool with a value outside the set {0,1}
in an assignment chain is, of course, another matter entirely,
but there are several ways it can happen.  Painfully, it can
happen in pre-MIL-STD 1753 Fortran code which can be broken
in a newfangled compiler that supports C_BOOL /= -1.

> The standard also doesn't specify that any particular bit must be the
> value bit - in principle, the single bit that is set in B'00000010'
> could be the only bit used by _Bool, though that seems unlikely.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[toc] | [prev] | [next] | [standalone]

#41811

"James Van Buskirk" <not_valid@comcast.net> writes:

> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:lfu2h6$btd$1@dont-email.me...
<snip>
>> Not quite - the value of the right operand of an assignment expression
>> is determined (a process that may involve the usual arithmetic
>> conversions), and is then converted to the destination type (if
>> different).
>
> Part of the premise of this subthread is that both left and right
> operands have the same intrinsic type, _Bool.  See above.
> In n1124.pdf, section 6.3 I read:
>
> "Conversion of an operand value to a compatible type causes no
> change to the value or the representation."
>
> Doesn't that mean that the compiler is just supposed to copy
> bits?

That would be down to the definition of the assignment operator.  The
conversion causes no change, but I can't see any guarantee that the
assignment won't.  Specifically, assignment is described as storing a
value, and that might involve changing the representation if the
implementation wants to do that.

And implementations do seem to vary.  This program:

  #include <stdio.h>
   
  int main(void)
  {
       _Bool b1, b2;
       *(char *)&b1 = 2;
       b2 = b1;
       printf("%d\n", *(char *)&b2);
  }

prints 2 when compiled with gcc and 0 when compiled with clang.  Both
outputs (along with many others!) are permitted.

<snip>
>> A _Bool is only required to be able to store two values: 0 and 1, a
>> requirement that can be met by having 1 value bit and 7 padding bits.
>> Whether _Bool can store larger values is unspecified. Larger values
>> can't be assigned to a _Bool object, because conversion to _Bool is part
>> of the assignment process.
>
> But it seems to me that they can when assigning from _Bool to
> _Bool.

Yes, they can, but they don't have to.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#41813

On 03/14/2014 12:36 PM, James Van Buskirk wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:lfu2h6$btd$1@dont-email.me...
> 
>> On 03/13/2014 11:40 PM, James Van Buskirk wrote:
...
>>> of the issue.  My impression was that assignment between variables
>>> of the same integer type in C was to copy all the bits, ...
> 
>> Not quite - the value of the right operand of an assignment expression
>> is determined (a process that may involve the usual arithmetic
>> conversions), and is then converted to the destination type (if
>> different).
> 
> Part of the premise of this subthread is that both left and right
> operands have the same intrinsic type, _Bool.  See above.
> In n1124.pdf, section 6.3 I read:

n1124.pdf is quite old; I'm not sure which version of the standard it
describes.  I don't think anything relevant to this discussion has
changed recently, but uou should still get n1570.pdf, which is almost
identical to the current standard.

> "Conversion of an operand value to a compatible type causes no
> change to the value or the representation."
> 
> Doesn't that mean that the compiler is just supposed to copy
> bits?

The conversion may not change the representation (which matters for the
purpose of evaluating bit-wise operators), but "Where a value is stored
in an object using a type that has more than one object representation
for that value, it is unspecified which representation is used, ..."
(6.2.6.1p8). For _Bool, this could only apply to the padding bits (if
any), but you were making a more general statement about "assignment
between variables of the same integer type in C", so it could also apply
to signed types, if they support negative zeros, which are considered to
have the same value as positive zeros.

...
>> A _Bool is only required to be able to store two values: 0 and 1, a
>> requirement that can be met by having 1 value bit and 7 padding bits.
>> Whether _Bool can store larger values is unspecified. Larger values
>> can't be assigned to a _Bool object, because conversion to _Bool is part
>> of the assignment process.
> 
> But it seems to me that they can when assigning from _Bool to
> _Bool.

True, but only if you already have a _Bool object containing such a
representation, which pushes the issue one step back, but doesn't
resolve it. Somewhere along the line it is necessary to use type punning
to create the first such object, which can then be copied around.

>>                            Such values, if they can be stored, could
>> only be created by type punning.
> 
> Creating the first _Bool with a value outside the set {0,1}
> in an assignment chain is, of course, another matter entirely,
> but there are several ways it can happen.  Painfully, it can
> happen in pre-MIL-STD 1753 Fortran code which can be broken
> in a newfangled compiler that supports C_BOOL /= -1.

While this thread is cross-posted to comp.lang.fortran, but my answer
was only about C.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#41819

James Kuyper <jameskuyper@verizon.net> writes:
> On 03/14/2014 12:36 PM, James Van Buskirk wrote:
[...]
>> Part of the premise of this subthread is that both left and right
>> operands have the same intrinsic type, _Bool.  See above.
>> In n1124.pdf, section 6.3 I read:
>
> n1124.pdf is quite old; I'm not sure which version of the standard it
> describes.  I don't think anything relevant to this discussion has
> changed recently, but uou should still get n1570.pdf, which is almost
> identical to the current standard.

N1124 consists of the C99 standard with the first two Technical
Corrigenda merged into it.  N1256 is similar, but includes all three
TCs.

N1570 is a draft of the C11 standard, published shortly before the
official standard was released.  There are only a few differences.

There's probably no point in using N1124, but N1256 might be more useful
than N1570 if you're using a compiler with no support for any of the
changes in C11.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#42287

"James Van Buskirk" <not_valid@comcast.net> writes:

> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:lfu2h6$btd$1@dont-email.me...
>
>> On 03/13/2014 11:40 PM, James Van Buskirk wrote:
>>>
>>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>>> news:20140313174032.771@kylheku.com...
>>>> ["Followup-To:" header set to comp.lang.c.]
>>>
>>> Posted to clf because the nature of the question is central to an
>>> issue due to Fortran interoperability (_Bool <-> LOGICAL(C_BOOL)).
>>>
>>>> On 2014-03-13, James Van Buskirk <not_valid@comcast.net> wrote:
>>>>
>>>>> At last!  A C programmer to inflict the Question on!  Now, what
>>>>> if true is a const _Bool with internal representation B'00000010'
>>>>> and var is also an _Bool.  Does the assert happen if NDEBUG is
>>>>> not on?
>>>>
>>>> The code generated by the assert macro, when NDEBUG is not
>>>> present, should not treat this expression any differently than
>>>> something like
>>>>
>>>>   if (var = true) ...
>>>>
>>>> The assignment must happen if NDEBUG is absent, and its result
>>>> tests as true.
>>>
>>> Yes, this last line of code above is perhaps a better illustration
>>> of the issue.  My impression was that assignment between variables
>>> of the same integer type in C was to copy all the bits, ...
>>
>> Not quite - the value of the right operand of an assignment
>> expression is determined (a process that may involve the usual
>> arithmetic conversions), and is then converted to the destination
>> type (if different).
>
> Part of the premise of this subthread is that both left and right
> operands have the same intrinsic type, _Bool.  See above.  In
> n1124.pdf, section 6.3 I read:
>
> "Conversion of an operand value to a compatible type causes no
> change to the value or the representation."
>
> Doesn't that mean that the compiler is just supposed to copy bits?
> [snip elaboration]

The short answer is no, but it's instructive to look at why.

First, if the width of _Bool is 1, then it may only ever store
the values 0 and 1.  Any bit pattern occupying a _Bool object
will therefore denote either 0, or 1, or a trap representation.
If the bit pattern denotes a 0 value then 0 will be stored;  if
the bit pattern denotes a 1 value then 1 will be stored;  and if
the _Bool object holds a trap representation then any behavior at
all is permissible, either copying the bits, or storing a 0 or 1
value, or crashing the program.  So a compiler is not obliged to
exactly copy the bits in this case, although of course it may,
but the key thing is it doesn't have to.

Now consider the question when the width of _Bool is greater
than 1.  Under this assumption a _Bool may now hold an object
representation corresponding to the value 2 or 3 (and perhaps
others, but these are enough), and are legal values, ie, not
trap representations.  The Standard imposes two requirements:
one, that conversion to the same type causes no change to the
value or representation;  and two, that conversion to a _Bool
type produces 0 if the original value compares equal to 0, and 1
otherwise.  The only way both of these requirements can be
satisfied simultaneously is if a _Bool object may not definedly
hold a value other than 0 or 1.  Hence the possibility that the
width of a _Bool is greater than 1 is not satisfiable in a
conforming implementation.  Therefore we may conclude that _Bool
/must/ have a width of 1, which gives each implementation enough
freedom to either just copy the bits or not, as it chooses.

[toc] | [prev] | [next] | [standalone]

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web