Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.os.vms Subject: Re: basic BASIC question Date: Sun, 2 Feb 2025 03:57:42 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: References: <679e8b61$0$708$14726298@news.sunsite.dk> <679eb699$0$708$14726298@news.sunsite.dk> Injection-Date: Sun, 2 Feb 2025 03:57:42 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="7478"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Bytes: 4328 Lines: 95 In article <679eb699$0$708$14726298@news.sunsite.dk>, Arne Vajhøj wrote: >On 2/1/2025 6:38 PM, Craig A. Berry wrote: >> >> On 2/1/25 3:00 PM, Arne Vajhøj wrote: >>> (in case someone wonder about C bool, then it is 8 bit!) >> >> I don't think it has to be.  C99 says: >> >> "An object declared as type _Bool is large enough to store the values 0 >> and 1." >> >> 8 bits are enough, but any integral type has enough bits.  "bool," >> "true," and "false" in stdbool.h are macros that can be overridden, >> although doing so is described as "obsolescent" behavior.  It's probably >> necessary because of the uses of bool before the standard had it. Gone away in C23. `bool`, `false`, and `true` are now keywords, and thus reserved. See n3220, sec 6.4.1 paras (1) and (2). https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf >> I'm pretty sure I've seen bool defined as an int on VMS, but whether >> that was something VAX C did for you or was just some what some program >> did in the absence of anything available from the (old) compiler I don't >> remember. > >The C standard does not mandate 8 bit. Correct. The C standard doesn't really concern itself with the concerete representation of data types; that's up to the implementation. Most of the time, this is given by an ABI. For example, the SVR4 ABI for x86_64 used on most modern Unix-y systems on that platform defines the size of _Bool to be 1 byte. See https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build (See figure 3.1, "Scalar Types", on page 17.) Note that the OpenVMS calling standard for x86_64 closely follows the System V ABI. (https://vmssoftware.com/docs/VSI_CALLING_STD.pdf, sec C.2): >The VMS C documentation says 8 bit. Well - it says 1 byte >for whatever reason, but ... The VMS ABI is derived from the System V ABI, and specifically the AMD64 supplement, which defines "byte" to be an 8-bit quantity in sec. 3.1.2: |Within this specification, the term byte refers to a 8-bit |object. Note that the terms used in the SysV ABI for the larger multibyte quantities are explicitly called out as things that differ in the VMS Calling Standard, but this is understood to mean nomenclature, not actual data layout. >If one include stdbool.h then bool is _Bool. From C 99. > >Before C 99 then I think: > >typedef int bool; >#define TRUE 1 >#define FALSE 0 > >was common. There were all sorts of variations before C99; this has led to some headaches. Beyond the obvious issue of symbol conflicts, people have tried to play tricks with e.g. `enum`s, a la, typedef enum { false, true } bool; but the issue here is that enums are really `int`s, and so so if such things were used in, say, a `struct` in some public-facing header, perhaps as part of a library that is distributed in binary-form only,then you may have a breaking change if linked against code that uses the newer ABI-mandated representation. For example, consider a struct such as: struct foo { int a; bool b; char c; }; On a system following the SysV AMD64 ABI, this is an 8-byte type, with 4-byte alignment. But using the enum trick, it's a 12-byte type, with 4-byte alignment. Mismatched code beware. >(stdbool.h also defines true and false) These are also now reserved keywords in C23. - Dan C.