On 2023-08-05, Bart <bc@freeuk.com> wrote:
> On 05/08/2023 19:32, Kaz Kylheku wrote:
> > On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> >> On 2023-08-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
> >>>
> >>>> On 2023-07-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >>>>
> >>>>> Bart <bc@freeuk.com> writes:
> >>>>>
> >>>>>> On 24/07/2023 08:50, David Brown wrote:
> >>>>>>
> >>>>>>> Integer constants (since that is the correct term - "literal"
> >>>>>>> is only used for "string literal" in C)
> >>>>>>
> >>>>>> You're right, the C standard only uses that for string literals
> >>>>>> and compound literals. But in the wider world, 'integer
> >>>>>> literal' is commonly used to mean 'integer constant', including
> >>>>>> in this C++ reference:
> >>>>>>
> >>>>>> https://en.cppreference.com/w/cpp/language/integer_literal
> >>>>>
> >>>>> Yes, C++ calls them literals. But that site does use the same
> >>>>> terminology as the C standard when talking about C:
> >>>>>
> >>>>> https://en.cppreference.com/w/c/language/integer_constant
> >>>>>
> >>>>> I prefer C++'s usage, since "integer constant" can be so easily
> >>>>> confused for "integer constant expression".
> >>>>
> >>>> The term "literal constant" has a well-entrenched meaning in computer
> >>>> science.
> >>>>
> >>>> "literal" is a contraction of this, just like "deliverable" is
> short for
> >>>> "deliverable goods" and what not.
> >>>>
> >>>> "constant" is another contraction of "literal constant".
> >>>>
> >>>> [...]
> >>>
> >>> I see Kaz has been taking lessons from Kellyanne Conway, offering
> >>> up "alternative facts".
> >>
> >> What?
> >>
> >>> No doubt the phrase "literal constant" is used in many places
> >>> that discuss programming, but it is not a term with any special
> >>> meaning, simply an ordinary phrase put together under the usual
> >>> rules of normal English usage, with "literal" being an adjective
> >>> modifying "constant".
> >>
> >> Indeed, the phrase isn't a noncompositional compound, like
> >> "blackboard" or "blueberry".
> >>
> >> So what? And, nobody claimed that it is.
> >>
> >>> The point of the phrase is to distinguish
> >>> it from "symbolic constant", which many programming languages
> >>> have going back at least as far as the early 1970s.
> >>
> >> I believe I said almost exactly the same thing in another article,
> >> weeks ago.
> >>
> >> No, wait! It's actually in the same article you're replying to!
> >>
> >> KK> Another kinds [sic] of constant that is not a literal is a "symbolic
> >> KK> constant" a.k.a. "manifest constant". This is a symbolic name
> >> KK> arbitrarily given to a literal constant value.
> >>
> >>> none of that has any bearing on the use of "literal" as a noun
> >>> by itself, which is a distinct and unrelated construction.
> >>
> >> Sayss you. I believe it's just derived from "literal constant"
> >> or similar.
> >
> > Well, yes; I have to acknowledge misuses of "literal" here.
> >
> > For instance, Python calls [1, 2, 3] a literal, even though each time
> > that is evaluated, it must construct a new object (or else countless
> > applications will break). That's just Python people being stupid. (I'm
> > taking the prescriptivist stance, which is fair game in the scope of a
> > technical field.)
>
> In my dynamic language, I also call (1, 2, 3), as I write it, a literal,
> as I do several other like constructors. The reason in this case is so
> the language can say that it is immutable, although lists in general are
> mutable.
>
> This is exactly for the purpose of being able to construct such an
> object once during load-time, and not every time it is encountered in
> source code.

ANSI Common Lisp has a feature (load-time-value <expr>) whereby
the expression will be evaluated at load time, and then behave
as a literal object.

>
> To create a mutable version requires using copy() or a special
> assignment operator.
>
> (Previously, I used a form of 'copy-on-write', but that sometimes gave
> unexpected behaviours.)
>
> Actually, even (x, y, random()) is a literal, even though the values are
> not compile-time constants. This is so the language can have a
> consistent rule that says that:
>
> (a, b, c)
>
> is always immutable, without it depending on whether each of a, b, c was
> a constant, named constant, an expression yielding a compile-time
> constant, or runtime value.

In ANSI Common Lisp, a similar effect is achieved via the explicit
use of the load-time-value special operator.

An expression like:

(load-time-value (list a b c))

will, at least in compiled code, arrange for (list a b c) to be
evaluated once, at load time. (E.g. when the surrounding compiled file
is loaded.) The value of the expression will then be "treated as a
literal object at run time" (wording in ANSI CL).

The expression can only access the top-level environment;
lexical variables are invisible to it.

Lisp has true literals: quoted structure: '(1 2 3).

There are similar rules to C in that if a program tries to
modify a literal, the behavior is undefined.

> > There are also languages that give meaning to self-modifying programs.
> > It's posssible to have a dialect of C with writable string literals.
>
> I think most Cs let you modify string literals. The only thing that
> stops you doing so is the compiler storing the string data in read-only
> memory. For example:
>
> "ABC"[0] = 'Z';
>
> gcc only warns about this, it does not stop you trying to do it. Clang
> doesn't say anything.

Even if it is compiled, and the run-time deosn't crash, don't know which
other "ABC" literals in the program are mapped to the same object;
which other "ABC" you might be changing elsewhere in the image.

If the code is put into ROM, it could be that the write appears to work
silently (no exception or anything of the sort), but then when you read
the value, it is still 'A'. Possibly, if it's a shadow ROM, the write
actually happened, and went into a RAM bank under the ROM.

All that is allowed under "undefined behavior".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 06/08/2023 00:54, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 05/08/2023 23:11, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>> But this has not been addressed and I think it should be:
>>>
>>>> Here's one other quirky thing:
>>>>
>>>> double x = 0x123p10;
>>>> printf("x=%f\n",x);
>>>>
>>>> This a floating point constant using hexadecimal, supposedly.
>>>
>>> As far as I can tell, the only quirk is that it does not mean what you
>>> think (or supposed) it should. Floating-point constants mean what the
>>> language definition says they mean:
>>>
>>> "The significand part is interpreted as a (decimal or hexadecimal)
>>> rational number; the digit sequence in the exponent part is
>>> interpreted as a decimal integer."
>>>
>>> I have used this format fair amount (though more often as seen in the
>>> output generated by %a and %A) and found it very convenient.
>>> Consistency should not trump usability.
>>
>> Someone would reasonably expect that a hex floating point constant is
>> actually written exclusively in hex, not involving 3 different bases.
>
> And any reasonable programmer would then check their expectations.
> There may be (as there are in this case) good reasons to avoid
> consistency just for the sake if it.
>
>> Your quote also doesn't mention that the exponent represents a power
>> of 2, not a power of 16 nor a power of 10.
>
> The next two sentences cover it. Maybe I should have quoted the whole
> paragraph but you had already given the key details in your complaint.
>
>> In a regular decimal constant, the exponent represents a power of 10.
>>
>> (In my own stuff I've dropped support for hex float constants, after
>> previously dropping it for arbitrary bases. It was never used!
>>
>> But when I did support it, then 0x123p10 meant 0x123 * 0x10**0x10, or 0x123
>> * 16**16; everything is base-16.)
>
> Your position is that a notation that has actually been found to be
> useful should instead have been designed in a way that you found to have
> no uses.
>

You said you didn't use it yourself much, that is for hard-coded
constants in source code. As for output, when I ran this program:

#include <stdio.h>
int main(void) {
printf("%A\n", 0x1.23p10);
}

using my gcc 10.x, it gave this putput:

0X9.18P+7

although everything else I tried gave this more consistent result (the
number of trailing zeros varied):

0X1.230000P+10

If the source code was instead 0x123p10 however, the output was:

0X1.230000P+18

This was rather confusing at first, until you realised that the +10 or
+18 was a decimal value, and it's counting binary digits. So each
movement of the decimal point by one hex digit, means a difference of 4
binary digits.

BTW I would find macros like these more flexible (this is how I can
emulate differently-based floats in my language):

#define CHEXFLOAT(m, e) ((double)m*pow(2.0,e))
#define HEXFLOAT(m, e) ((double)m*pow(16.0,e))

Here, the caller can choose to use hex or decimal for either of the two
parts; they just have different rules as to the meaning of the exponent.

My example would be written as CHEXFLOAT(0x123, 10) to give the same
result. A regular float might use:

#define DECFLOAT(m, e) ((double)m*pow(10.0,e))

So there is a clear pattern: the three macros differ only by whether the
exponent is specified as binary, hex or decimal digits. The number-base
used, for any constant arguments, is irrelevant.

On 8/5/23 5:46 AM, Bart wrote:
> On 05/08/2023 03:44, Richard Damon wrote:
> > On 8/4/23 7:43 PM, Bart wrote:
> >> On 04/08/2023 22:47, Kaz Kylheku wrote:
> >>  > On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>  >> Presumably `__int32_t` is being defined on top of whatever 32-bit
> >> type
> >>  >> the C compiler has.
> >>  >>
> >>  >> So why doesn't it just define it on top of `int32_t`? Or better,
> >> forget
> >>  >> `__int32_t` and just use `int32_t`?
> >>  >>
> >>  >> Don't tell me, there is some really, really complicated reason
> why it
> >>  >> has to be done like this (maybe these are some of those
> >> programmers paid
> >>  >> by the line!).
> >>  >
> >>  > Mostly, the reasons can be summarized by that it's not some solo
> >>  > developer's recently started greenfield project, but something
> with a
> >>  > long history on various kinds of machines, and numerous
> >> implementations.
> >>  > C first had 18 bit int; most machines don't have that now.
> >>  >
> >>  > Good thing we are not stuck with int18, right?
> >>  >
> >>
> >> And the exact reason why that code can't just do:
> >>
> >>      #include <stdint.h>
> >>
> >>      typedef int32_t __int32_t;
> >>
> >> is? I can't imagine that it still needs to run on the PDP7, and with
> >> the code shown, it wouldn't work anyway.
> >>
> >> There have dozens of posts extolling the benefits of using stdint.h,
> >> and not rolling your own types, and now we have a piece of code that
> >> completely ignores that advice.
> >
> > System headers are not allowed to bring in identifiers from another
> > system header without explicit indication that it should do so in the
> > Standard.
> >
> > As int32_t is an identifier in the user namespace UNLESS <stdint.h> has
> > been included by USER code, or it is defined to be included by some
> > header that it includes.
> >
> > The header you are talking about, is an INTERNAL header, used by system
> > headers other than <stdint.h>, so it isn't allowed to define symbols
> > like int32_t
> >
> > Do you not understand the rules of namespace?
>
> So, despite C99 introducing those types in stdint.h, system headers are
> not allowed to use stdint.h because it int32_t cannot be exposed to user
> programs unless they explicitly include stdint.h?

Right. User namespace must be respected. A header only gets to use the
namespace authorized by THAT header, which doesn't include names used in
some other arbitrary header unless the Standard says it does.

>
> And those system headers cannot have stdint.h being included in any
> internal headerss that they call, for the same reason?

Yep. Can't use names that are still in the use namespace.

int32_t is in the user namespace until the USER does something to give
it back to the implementation, which is by including <stdint.h> or a
header DEFINED BY THE STANDARD to possible add that name.

>
> Does that mean that none of the functions of the C runtime declared in
> the system headers will ever be allowed to use C99 types?

None of the current headers can. It could introduce a new header that
defines that it also reserves the new type names, and functions in that
header could use the new types.

THe key point is that user namespace is respected, and no symbols in
that namespace can be used by the system without an explicit action of
the code (like including a header).

>
> It gets better and better!
>
> This explanation is anyway at odds with that provided by Kaz, where the
> code apparently is in an external library, not a component of the system
> library.

An external library has a similar restriction because it needs to be
compatible with code that has included <stdint.h> and thus those names
might be reserved for the system.

But in that case, it can't use __ names.

But, he said it was in something like _int_types.h, which could well be
a system header (and in fact is very likely a system header)
>
> If what you say is the case, then NO library should be allowed to use
> int32_t in their APIs, unless a prior '#include <stdint.h>' has been
> seen in any user code that wants to use that library.

A USER library just needs to define that it effectively includes
<stdint.h>, and then it can use those names for the standard defined
purpose.

The restriction is just on the implementation, it has no impact on what
"user libraries" can do. They need to respect the system namespace
division, and should define how they will interact with other code as
far as namespace.

>
> Because the user might be defining int32_t for their own purposes?
> (Isn't a _t suffix reserved?

To my knowledge, _t reservation was done by POSIX, not the C standard.
The C Standard defines these sort of names that will become reserved
when a given header is included.

Since in C, the "name" of a type is actually actually immaterial except
within that translation unit, there is no need to globally reserve the
names.

>
> I find that abolutely extraordinary.

You don't seem to understand backwards compatibility.

>
> I thought C's type system was already a complete mess. This is verging
> on unbelievable.
>
> So, basically, C doesn't really have int32_t as a type, not one you can
> just use anywhere; it is a privileged type.
>
>

It is usable BY THE USER, by just including <stdint.h>, if that type
exists in the system.

The IMPLEMENTATION can't use it by that name unless it KNOWS that
<stdint.h> has been included.

There is a hard line in namespaces between user code and implementation
code, as duplicating names in the same namespace is a big no-no.

On 8/5/23 9:17 AM, Bart wrote:
> On 05/08/2023 03:50, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 8/4/23 10:25 AM, Bart wrote:
>>>
>>>> [...]
>>>
>>> Maybe your problem is you dont understand [...]
>>
>> Bart's problem isn't that he doesn't understand.  Bart's
>> problem is that he doesn't _want_ to understand.
>
> Bart is the kid who questions the Emperor's new clothes.
>
> You have a software system that has accumulated a mountain of now
> unnecessary cruft. It's fair to ask why that mountain still exists.
>
> All I'm hearing is excuses.
>
> And after all this discussion about how great 'int32_t' is that we
> shouldn't need to create aliases, now apparently we're not allowed to
> use it unless we're an end-user?

And, unless you are the implementation, you are.

>
> Because the use of 'int32_t' in my library will expose it to a user who
> has not sanctioned the use of stdint.h.

So just docuement that your library uses stdint.h like any user code is
allowed to.

YOU aren't under the restrictions of an implementation (unless you ARE
the implementation).

>
> So much for C now having 'built-in' fixed-width types!

No, Bart doesn't understand that there still is a use for that "cruft".

On 06/08/2023 12:56, Richard Damon wrote:
> On 8/5/23 9:17 AM, Bart wrote:
>> On 05/08/2023 03:50, Tim Rentsch wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 8/4/23 10:25 AM, Bart wrote:
>>>>
>>>>> [...]
>>>>
>>>> Maybe your problem is you dont understand [...]
>>>
>>> Bart's problem isn't that he doesn't understand. Bart's
>>> problem is that he doesn't _want_ to understand.
>>
>> Bart is the kid who questions the Emperor's new clothes.
>>
>> You have a software system that has accumulated a mountain of now
>> unnecessary cruft. It's fair to ask why that mountain still exists.
>>
>> All I'm hearing is excuses.
>>
>> And after all this discussion about how great 'int32_t' is that we
>> shouldn't need to create aliases, now apparently we're not allowed to
>> use it unless we're an end-user?
>
> And, unless you are the implementation, you are.
>
>>
>> Because the use of 'int32_t' in my library will expose it to a user
>> who has not sanctioned the use of stdint.h.
>
> So just docuement that your library uses stdint.h like any user code is
> allowed to.
>
> YOU aren't under the restrictions of an implementation (unless you ARE
> the implementation).
>
>>
>> So much for C now having 'built-in' fixed-width types!
>
> No, Bart doesn't understand that there still is a use for that "cruft".

See Malcolm's post about one hour before this one.

It looks like introducing stdint.h doesn't magically solve the problem
of providing C with standard fixed width types. It just means endless
programs and libraries having conditional blocks like that shown in his
post.

I've seen worse in libraries like SDL2.

/I/ think that C99 could have introduced new 'int32_t' etc as proper
built-in types, not requiring a header, so always available. But with
the ability, for a probationary period of a decade, say, to allow those
built-ins to be overriden by user typedefs.

So:

int32_t x; // this always works just like 'int'

But:

typedef int int32_t; // this also works

In this case 'int32_t' becomes a user-identifier, just like it is know
when you don't use stdint.h.

I will need to check the viability of such a built-in 'int32_t' being
used for variable, function, struct/enum tag, member and label names.

C already allows a typedef 'int32_t' to be used for all those, which is
yet one more bizarre quirk (is there no end to them!). This program is
apparently legal:

#include <stdint.h>

struct int32_t {int32_t int32_t;} Int32_t;

It illustrates well why I consider the design of C, a systems language
just like mine, so whacko. In my syntax:

record int32 = (int32 int32)
int32 Int32

the first int32 is not allowed; int32 is already a type. If I fix that,
that third int32 is not allowed: you can't use a standard type as an
identifier.

The same applies to that Int32, since this is case-insensitive. This all
forces you to write saner programs.

> No, Bart doesn't understand that there still is a use for that "cruft".

Bart understands that it works poorly and that there could have been a
much better solution. Nearly 25 years on from C99:

* You still have code both pre-C99 and post-C99 that apparently needs to
conditionally define types like int32_t depending on compiler,
version, the presence of flags like __int32_t and so on

* You can't use int32_t in a system header

* The use of int32_t in a user library requires that the need for
stdint.h is documented, but can still cause problems as shown
in Malcolm's post

* As shown above, you can use the typedef int32_t as a user identifier
in several contexts. My proposal would not fix that until the
probationary period in over. Then it would need explicit enabling.

On 05/08/2023 01:43, Bart wrote:
> On 04/08/2023 22:47, Kaz Kylheku wrote:
> > On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> >> the C compiler has.
> >>
> >> So why doesn't it just define it on top of `int32_t`? Or better, forget
> >> `__int32_t` and just use `int32_t`?
> >>
> >> Don't tell me, there is some really, really complicated reason why it
> >> has to be done like this (maybe these are some of those programmers
> paid
> >> by the line!).
> >
> > Mostly, the reasons can be summarized by that it's not some solo
> > developer's recently started greenfield project, but something with a
> > long history on various kinds of machines, and numerous implementations.
> > C first had 18 bit int; most machines don't have that now.
> >
> > Good thing we are not stuck with int18, right?
> >
>
> And the exact reason why that code can't just do:
>
>     #include <stdint.h>
>
>     typedef int32_t __int32_t;
>
> is?

Library headers can't #include <stdint.h>, because it might conflict
with user identifiers. User code can't (or at least, shouldn't) define
identifiers starting with two underscores. So that code is bad for any
use-case.

Serious C compilers and libraries are very careful to follow the rules
as closely as possible, and to avoid any possibility of intruding on
programmers' freedom of coding if they can. Since the C standards allow
programmers to define a variable, function, macro or type called
"int32_t" as long as they don't include <stdint.h> or <inttypes.h>, then
the C libraries and compilers also allow that - no matter how silly it
might seem for a program to have a function "int32_t". The situation is
greatly complicated for libraries designed to work with a range of
compilers and targets, including ones with different sizes of basic
integers and other fundamental implementation-dependent behaviour. They
also like to support a range of C versions (including all minor
details), and perhaps other options and variants available in some
toolchains.

In that context, a bit messy definitions in a header that no one looks
at does not really matter. In hindsight, it's easy to see how the
language could have been designed a little differently to get the
features we have now, but C has evolved with backwards compatibility as
a major guiding factor. Simplicity of hidden headers or implementations
of C compilers and libraries, on the other hand, has always been
considered pretty much irrelevant in comparison.

On 05/08/2023 12:00, Bart wrote:
> On 05/08/2023 03:11, Kaz Kylheku wrote:

> > Newlib is a C library intended for use on embedded systems.
>
> And? I gave a link yesterday to a header designed for use on Arduino, it
> had:
>
>    typedef uint8_t byte;
>
> So breaking two rules at once: using stdint.h (imagine if a user program
> included arduino.h, but is inadvertently exposed to uint8_t which must
> be kept under wraps unless they explicitly use stdint.h), and defining a
> much better alias for a C99 type,.
>

The Arduino headers are not standard C library headers. The Arduino is
aimed as a system that is easy to get started with for learning,
testing, and proof of concepts. It does not use C, but a subset of C++,
and its IDE hides away many of the details and complexities of C++,
toolchains (it is based on gcc), and embedded development. This makes
it easy to get started and to make simple test code - but terrible for
serious work where you want repeatable builds, efficiency, reliability,
or other features that are usually important in embedded development of
actual products. It would have been better, IMHO, if it did not use C
or C++ at all, but rather was based on a language where ease of use was
already given more precedence than efficiency - perhaps BASIC would have
been a better fit.

Bart <bc@freeuk.com> writes:

> On 06/08/2023 00:54, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 05/08/2023 23:11, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> But this has not been addressed and I think it should be:
>>>>
>>>>> Here's one other quirky thing:
>>>>>
>>>>> double x = 0x123p10;
>>>>> printf("x=%f\n",x);
>>>>>
>>>>> This a floating point constant using hexadecimal, supposedly.
>>>>
>>>> As far as I can tell, the only quirk is that it does not mean what you
>>>> think (or supposed) it should. Floating-point constants mean what the
>>>> language definition says they mean:
>>>>
>>>> "The significand part is interpreted as a (decimal or hexadecimal)
>>>> rational number; the digit sequence in the exponent part is
>>>> interpreted as a decimal integer."
>>>>
>>>> I have used this format fair amount (though more often as seen in the
>>>> output generated by %a and %A) and found it very convenient.
>>>> Consistency should not trump usability.
>>>
>>> Someone would reasonably expect that a hex floating point constant is
>>> actually written exclusively in hex, not involving 3 different bases.
>> And any reasonable programmer would then check their expectations.
>> There may be (as there are in this case) good reasons to avoid
>> consistency just for the sake if it.
>>
>>> Your quote also doesn't mention that the exponent represents a power
>>> of 2, not a power of 16 nor a power of 10.
>> The next two sentences cover it. Maybe I should have quoted the whole
>> paragraph but you had already given the key details in your complaint.
>>
>>> In a regular decimal constant, the exponent represents a power of 10.
>>>
>>> (In my own stuff I've dropped support for hex float constants, after
>>> previously dropping it for arbitrary bases. It was never used!
>>>
>>> But when I did support it, then 0x123p10 meant 0x123 * 0x10**0x10, or 0x123
>>> * 16**16; everything is base-16.)
>> Your position is that a notation that has actually been found to be
>> useful should instead have been designed in a way that you found to have
>> no uses.
>
> You said you didn't use it yourself much, that is for hard-coded constants
> in source code.

I did not say that. I said that I use the output format /more/.

> As for output, ...

You don't like it. I get it.

--
Ben.

Bart <bc@freeuk.com> writes:

> when I ran this program:
>
> #include <stdio.h>
> int main(void) {
> printf("%A\n", 0x1.23p10);
> }
>
> using my gcc 10.x, it gave this putput:
>
> 0X9.18P+7

I was not going to comment on your objections to the output but then I
remembered that you do this all the time: you don't say what C library
you are using. gcc does not give any output. The output comes from
whatever library is providing the implementation of printf.

--
Ben.

Bart <bc@freeuk.com> writes:
>
> [...] As for output, when I ran this program:
>
> #include <stdio.h>
> int main(void) {
> printf("%A\n", 0x1.23p10);
> }
>
> using my gcc 10.x, it gave this putput:
>
> 0X9.18P+7

This is a case where what matters is which runtime library you're using,
not which compiler. gcc just generates a call to printf. Of course you
know this. If you'd care to let us know which *implementation* (not
just compiler) produced which output, that might be interesting.

> although everything else I tried gave this more consistent result (the
> number of trailing zeros varied):
>
> 0X1.230000P+10

I'm not sure why you say that's more consistent. Both are correct
representations of the double value 1164.0, and both conform to the
requirements in the standard.

I haven't used "%A" and "%a" much myself, wnhich is why I hadn't
realized that the output is more subject to implementation choices
than I had thought.

The standard requires one hexadecimal digit before the radix point.
That digit is nonzero if the value is nonzero [see footnote] and
normalized. But the implementation can choose to use 1, 2, 3, or 4 bits
for that first digit; for example, 1.0 can be printed as any of
"0X1P+0", "0X2P-1", "0X4P-2", or "0X8P-3".

As for trailing zeros, the standard says "if the precision is missing
and FLT_RADIX is a power of 2, then the precision is sufficient for an
exact representation of the value". Which means that an implementation
can add as many trailing zeros as it likes.

This flexibility isn't really a problem. For binary floating-point, the
output produced by "%a" or "%A" always represents the exact value of the
number. Binary floating-point emphasizes precision over readability.
It provides an unambiguous way to convert a floating-point to a
character string without losing information (if the floating-point
representation is binary). If you want a human-readable representation,
use decimal (%g, %f, %e).

And yes, the output can be confusing if you don't know how it's
specified. The solution to that problem is to learn how it's specified.
Anyone actually interested in doing so should read N1570 7.21.6.1p7, or
the equivalent in another edition.

[footnote]
I think there's a minor flaw in the standard's description of the a and
A length modifiers. Quoting the N3096 draft:

A double argument representing a floating-point number is converted
in the style [-]0xh.hhhhp±d, where there is one hexadecimal digit
(which is nonzero if the argument is a normalized floating-point
number and is otherwise unspecified) before the decimal-point
character ...

0.0 is not a "normalized" floating-point number (see the section
describing <float.h>). The standard makes the digit before the point
unspecified for printf("%a", 0.0). It should specify that it's '0'.
(I think that an implementation that used something other than '0'
would be non-conforming for other reasons.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 06/08/2023 22:40, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>>
>> [...] As for output, when I ran this program:
>>
>> #include <stdio.h>
>> int main(void) {
>> printf("%A\n", 0x1.23p10);
>> }
>>
>> using my gcc 10.x, it gave this putput:
>>
>> 0X9.18P+7
>
> This is a case where what matters is which runtime library you're using,
> not which compiler. gcc just generates a call to printf. Of course you
> know this. If you'd care to let us know which *implementation* (not
> just compiler) produced which output, that might be interesting.

How do I find out which library it uses? And what do I do with that
information?

To me 'gcc' is a black box just as it will be to very many people, used
as a complete driver to turn sources files into executable binaries.

You trust it to generate code for you and arrange for suitable libraries
to be employed.

It's not my job to try and debug such a hugely complex product. I mainly
use gcc as a reference implementation, and here it did a poor job.

It is just gcc 10.3.0 on Windows, part of the TDM distribution, that
showed that problem. Online compilers and a specially downloaded gcc
13.2 (part of wx64 or some such distribution) gave a correct result.

As did my bcc compiler using msvcrt.dll.

Bart <bc@freeuk.com> writes:
> On 06/08/2023 22:40, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>>
>>> [...] As for output, when I ran this program:
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> printf("%A\n", 0x1.23p10);
>>> }
>>>
>>> using my gcc 10.x, it gave this putput:
>>>
>>> 0X9.18P+7
>>
>> This is a case where what matters is which runtime library you're using,
>> not which compiler. gcc just generates a call to printf. Of course you
>> know this. If you'd care to let us know which *implementation* (not
>> just compiler) produced which output, that might be interesting.
>
> How do I find out which library it uses? And what do I do with that
> information?

Maybe by telling us which *implementation* you're using, not just which
*compiler*.

[...]
> It is just gcc 10.3.0 on Windows, part of the TDM distribution, that
> showed that problem. Online compilers and a specially downloaded gcc
> 13.2 (part of wx64 or some such distribution) gave a correct result.

There, that wasn't so hard, was it?

https://jmeubank.github.io/tdm-gcc/

I haven't yet checked what runtime library it uses. I'll look into it
later.

And what "problem" are you referring to? As far as I can tell, all the
sample outputs you showed were valid. If you think they're not, show us
exactly what requirement was violated.

Your expectation that "%A" always produces the same output is unfounded.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 06/08/2023 23:19, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 06/08/2023 22:40, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>>
>>>> [...] As for output, when I ran this program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>> printf("%A\n", 0x1.23p10);
>>>> }
>>>>
>>>> using my gcc 10.x, it gave this putput:
>>>>
>>>> 0X9.18P+7
>>>
>>> This is a case where what matters is which runtime library you're using,
>>> not which compiler. gcc just generates a call to printf. Of course you
>>> know this. If you'd care to let us know which *implementation* (not
>>> just compiler) produced which output, that might be interesting.
>>
>> How do I find out which library it uses? And what do I do with that
>> information?
>
> Maybe by telling us which *implementation* you're using, not just which
> *compiler*.
>
> [...]
>> It is just gcc 10.3.0 on Windows, part of the TDM distribution, that
>> showed that problem. Online compilers and a specially downloaded gcc
>> 13.2 (part of wx64 or some such distribution) gave a correct result.
>
> There, that wasn't so hard, was it?
>
> https://jmeubank.github.io/tdm-gcc/
>
> I haven't yet checked what runtime library it uses. I'll look into it
> later.
>
> And what "problem" are you referring to? As far as I can tell, all the
> sample outputs you showed were valid. If you think they're not, show us
> exactly what requirement was violated.

I showed the output above, it was:

0X9.18P+7

The others looked like this:

0X1.230000P+10

I expected you're going to tell me that 0x9.18p+7 conforms according to
the C standard.

In which case, I'd be left wondering, is there ANYTHING that C or its
compilers do that is actually wrong, or can you use C legalise to argue
that black is white?

On 8/5/23 6:00 AM, Bart wrote:
> On 05/08/2023 03:11, Kaz Kylheku wrote:
> > On 2023-08-05, Bart <bc@freeuk.com> wrote:
> >> On 05/08/2023 01:15, Kaz Kylheku wrote:
> >>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>>> On 04/08/2023 22:47, Kaz Kylheku wrote:
> >>>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>>>>> Presumably `__int32_t` is being defined on top of whatever
> 32-bit type
> >>>>>> the C compiler has.
> >>>>>>
> >>>>>> So why doesn't it just define it on top of `int32_t`? Or better,
> >> forget
> >>>>>> `__int32_t` and just use `int32_t`?
> >>>>>>
> >>>>>> Don't tell me, there is some really, really complicated reason
> why it
> >>>>>> has to be done like this (maybe these are some of those
> >> programmers paid
> >>>>>> by the line!).
> >>>>>
> >>>>> Mostly, the reasons can be summarized by that it's not some solo
> >>>>> developer's recently started greenfield project, but something
> with a
> >>>>> long history on various kinds of machines, and numerous
> >> implementations.
> >>>>> C first had 18 bit int; most machines don't have that now.
> >>>>>
> >>>>> Good thing we are not stuck with int18, right?
> >>>>>
> >>>>
> >>>> And the exact reason why that code can't just do:
> >>>>
> >>>>        #include <stdint.h>
> >>>>
> >>>>        typedef int32_t __int32_t;
> >>>
> >>> It appears that this thread is about something found in a
> >>> library header _default_types.h.
> >>>
> >>> I don't have a _default_types.h anywhere except a bunch
> >>> of Cygwin trees. It looks like a Newlib thing (a library from the
> >>> BSD world on which Cygwin is based).
> >>>
> >>> The reason the header cannot just do #include <stdint.h>
> >>> is that it is the basis for that header!
> >>>
> >>> $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
> >>> #include <machine/_default_types.h>
> >>> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> >>> /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> >>>
> >>> The library is designed such that it provides its own <stdint.h>
> >>> header, not relying on the compiler providing one. It defines
> >>> some underscored types in machine/_default_types.h and then it
> >>> uses those to declare the public, standard ones in <stdint.h>.
> >>
> >> Which is going around the houses.
> >>
> >> stdint.h should be provided by the C implementation, which knows the
> >> exact sizes of its char, short, int, long, long long types.
> >
> > <stdint.h> is described in the Library section of the standard.
> >
> > Cygwin's Newlib is a library.
> >
> > This is not rocket science.
> >
> > Some compilers are not complete C implementations. GCC isn't
> > a complete, hosted implementation.
> >
> > It becomes one when combined with a library.
> >
> > The GNU project, from the start, provided piecemeal replacement
> > for Unix tools. People used GNU C on Unix boxes, with the library
> > (including headers) from those Unix boxes.
> >
> > GNU has a C library, which is a separate project.
> >
> > GCC + { glibc, uCLibc, musl, Newlib, Bionic, ...} becomes a C
> > implementation.
> >
> > I /think/ GCC now does provide a stdint.h? But it wasn't historically
> > the case. A library that doesn't depend on the compiler providing
> > a header like stdint.h will just do it itself.
> >
> >> So int32_t is typically defined of top of int when it knows int is
> >> exactly 32 bits.
> >
> > Fair game for a library.
> >>
> >> Even it if prefers to go through all the basic types looking for the
> one
> >> with a suitable upper limit, why define the intermediate __int32_t at
> >> all, why not just define int32_t.
> >
> > This can only be explained by people familiar with the history
> > of Newlib and its ongoing maintenance.
> >
> > The code may date back to a time when you could not rely on
> > compilers providing <stdint.h>. Newlib wanted its users to
> > have that and so it "polyfilled" it.
> >
> > Maybe it would be easy to remove that, but nobody has
> > noticed and bothered.
> > p
> >>> I would do it similarly, if I had to.
> >> I have done it, and mine looks like this inside my stdint.h:
> >>
> >>       typedef int int32_t;
> >>
> >> A bit simpler, isn't it?
> >
> > Look at the machines Newlib supports:
> >
> >
> https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine
>
> So each of those dozens of targets (which mostly seem to use
> 8-16-32-64-bit word sizes) has its own set of headers?
>
> Even better! Use a dedicated header for each one that defines __int32_t
> using one typedef.
> > It may be that at least one of them doesn't have a 32 bit int.
> >
> > You can't compare your green field solo project to something like that.
>
> I've written compilers for five architectures, starting in 1979.
>
> I take a different approach: I don't try and support myriad different
> targets spanning decades using only a single file that is a mess of
> conditional code blocks.
>
> > Newlib is not just the basis for Cygwin.
> >
> > https://sourceware.org/newlib/
> >
> > Newlib is a C library intended for use on embedded systems.
>
> And? I gave a link yesterday to a header designed for use on Arduino, it
> had:
>
>    typedef uint8_t byte;
>
> So breaking two rules at once: using stdint.h (imagine if a user program
> included arduino.h, but is inadvertently exposed to uint8_t which must
> be kept under wraps unless they explicitly use stdint.h), and defining a
> much better alias for a C99 type,.
>
>
>

And, since arduino.h isn't listed in the C standard as an implementation
header, it required to follow the restrictions of an implementation
header, nor is it allowed to presume it can use implementation namespace.

You seem to not understand how "C" works, which really puts you at a big
disadvantage.

For every thing you need to look at where it is defined, and what rules
that means it needs to follow (and realize some things will cross the
line or just be "incorrect", even if it "works")

Bart <bc@freeuk.com> writes:
> On 06/08/2023 23:19, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 06/08/2023 22:40, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>> [...] As for output, when I ran this program:
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>> printf("%A\n", 0x1.23p10);
>>>>> }
>>>>>
>>>>> using my gcc 10.x, it gave this putput:
>>>>>
>>>>> 0X9.18P+7
>>>>
>>>> This is a case where what matters is which runtime library you're using,
>>>> not which compiler. gcc just generates a call to printf. Of course you
>>>> know this. If you'd care to let us know which *implementation* (not
>>>> just compiler) produced which output, that might be interesting.
>>>
>>> How do I find out which library it uses? And what do I do with that
>>> information?
>> Maybe by telling us which *implementation* you're using, not just
>> which
>> *compiler*.
>> [...]
>>> It is just gcc 10.3.0 on Windows, part of the TDM distribution, that
>>> showed that problem. Online compilers and a specially downloaded gcc
>>> 13.2 (part of wx64 or some such distribution) gave a correct result.
>> There, that wasn't so hard, was it?
>> https://jmeubank.github.io/tdm-gcc/
>> I haven't yet checked what runtime library it uses. I'll look into
>> it later.
>>
>> And what "problem" are you referring to? As far as I can tell, all
>> the sample outputs you showed were valid. If you think they're not,
>> show us exactly what requirement was violated.
>
> I showed the output above, it was:
>
> 0X9.18P+7
>
> The others looked like this:
>
> 0X1.230000P+10
>
> I expected you're going to tell me that 0x9.18p+7 conforms according
> to the C standard.

No, I'm going to let you figure it out for yourself.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Section 7.21.6.1, paragraph 8. It's a long paragraph; scroll down to
the part that describes the a and A modifiers. I've also commented on
it in this thread; free free to re-read my article.

Read and understand what the standard says. If you think either
or both of the above outputs (both of which specify the same value)
are incorrect, by all means tell us.

> In which case, I'd be left wondering, is there ANYTHING that C or its
> compilers do that is actually wrong,

Yes.

> or can you use C legalise to
> argue that black is white?

No.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-05, Bart <bc@freeuk.com> wrote:
> On 05/08/2023 03:11, Kaz Kylheku wrote:
> > On 2023-08-05, Bart <bc@freeuk.com> wrote:
> >> I have done it, and mine looks like this inside my stdint.h:
> >>
> >> typedef int int32_t;
> >>
> >> A bit simpler, isn't it?
> >
> > Look at the machines Newlib supports:
> >
> >
> https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine
>
> So each of those dozens of targets (which mostly seem to use
> 8-16-32-64-bit word sizes) has its own set of headers?
>
> Even better! Use a dedicated header for each one that defines __int32_t
> using one typedef.

For one reason or another, in spite having these separate directories
for machine-specific C and assembly code, they rolled that
_default_types.h thing into one header. Probably they found it quite
manageable that way. The content isn't very long or complicated.

I actually have some gripes with Newlib, but not this.

Newlib is based on some BSD code (I don't know the exact history)
which interprets feature selection macros in a silly way.

In BSD land, if you don't define feature selection macros like
-D_POSIX_C_SOURCE=whatever, your program is exposed to everything
by default: every extension available in every header.

The feature selection macros do not *enable* features, but *hide*.

Newlib inherits this problem. When we do this:

gcc -ansi -D_POSIX_SOURCE

then Newlib hides all the POSIX extensions in headers like <stdio.h>.

Why? Because -ansi turns on some GCC macro like __STDC__ or whatever,
which Newlib interprets as meaning "hide everything but ANSI C".
And it interprets _POSIX_SOURCE as "hide everything but 1990's POSIX
stuff". But there is nothing left to hide: the POSIX stuff is all
hidden.

The sane thing is for feature selection macros to enable
rather than disable.

If at least one feature selection macro is present, should enable the
union of all feature selection macros, and hide everything else. So
that, for instance, -ansi -D_POSIX_SOURCE gets the compiler to use the
C90 dialect, and _POSIX_SOURCE reveals classic POSIX identifiers like
fileno in <stdio.h> and strdup in <string.h>.

> > Newlib is not just the basis for Cygwin.
> >
> > https://sourceware.org/newlib/
> >
> > Newlib is a C library intended for use on embedded systems.
>
> And? I gave a link yesterday to a header designed for use on Arduino, it
> had:
>
> typedef uint8_t byte;
>
> So breaking two rules at once: using stdint.h (imagine if a user program
> included arduino.h, but is inadvertently exposed to uint8_t which must
> be kept under wraps unless they explicitly use stdint.h), and defining a
> much better alias for a C99 type,.

Since arduino.h isn't a standard C header, it can do whatever the
Arduino people want. They can document that <arduino.h> includes
<stdint.h> and then if it does exactly that, everthing is copacetic.
They could have it that including <arduino.h> causes the rest of the
translation unit to be parsed as Fortran.

When a C program includes a header that it doesn't provide, the
header is not in the standard language, the behavior is undefined.

- The header might be not found, in which case that's a diagnosable
error.

- A header might be found and bring in arbitrary content that can
cause any behavior imaginable. There could be an
#include <wipe_flash.h> which causes the compiled object file
to wipe the flash on the target machine without the program
having to call any function to do that.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 07/08/2023 01:20, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 06/08/2023 23:19, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 06/08/2023 22:40, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>>
>>>>>> [...] As for output, when I ran this program:
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> int main(void) {
>>>>>> printf("%A\n", 0x1.23p10);
>>>>>> }
>>>>>>
>>>>>> using my gcc 10.x, it gave this putput:
>>>>>>
>>>>>> 0X9.18P+7
>>>>>
>>>>> This is a case where what matters is which runtime library you're
using,
>>>>> not which compiler. gcc just generates a call to printf. Of
course you
>>>>> know this. If you'd care to let us know which *implementation* (not
>>>>> just compiler) produced which output, that might be interesting.
>>>>
>>>> How do I find out which library it uses? And what do I do with that
>>>> information?
>>> Maybe by telling us which *implementation* you're using, not just
>>> which
>>> *compiler*.
>>> [...]
>>>> It is just gcc 10.3.0 on Windows, part of the TDM distribution, that
>>>> showed that problem. Online compilers and a specially downloaded gcc
>>>> 13.2 (part of wx64 or some such distribution) gave a correct result.
>>> There, that wasn't so hard, was it?
>>> https://jmeubank.github.io/tdm-gcc/
>>> I haven't yet checked what runtime library it uses. I'll look into
>>> it later.
>>>
>>> And what "problem" are you referring to? As far as I can tell, all
>>> the sample outputs you showed were valid. If you think they're not,
>>> show us exactly what requirement was violated.
>>
>> I showed the output above, it was:
>>
>> 0X9.18P+7
>>
>> The others looked like this:
>>
>> 0X1.230000P+10
>>
>> I expected you're going to tell me that 0x9.18p+7 conforms according
>> to the C standard.
>
> No, I'm going to let you figure it out for yourself.
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> Section 7.21.6.1, paragraph 8. It's a long paragraph; scroll down to
> the part that describes the a and A modifiers. I've also commented on
> it in this thread; free free to re-read my article.

OK, so the peculiar looking representation is to do with exactly the
fact that it mixes up HEX digits with BINARY exponents.

That means that adding +/- 1 to the exponent doesn't just shift the
'decimal' point one digit as happens with pure decimal, it moves inside
the hex digit, so radically changing the appearance of the number that
follows 0x.

I guess we're all expected to sit and say with a straight face that
that's alright then; so long as C says that it conforms, that's all that
matters.

With decimal, a number printed in scientific notation is normalised so
that it starts off as a single value between 1.0 and 9.999, followed by
an exponent. If that was done in hex, the number would be between 1.0
and F.FFF, and if in binary, between 1.0 and 1.111.

But the behaviour here allows multiple values between 1.0 and F.FFF.

Looking at it again, my view then is that they're both wrong; I would
keep the exponent as a multiple of 4, thus keeping the main number
consistent, and between 1.0 and F.FFF... for non-zero values.

But then, that's just my opinion. After all what does it matter if
you're trying to compare the hex-float output of the same value from two
programs, and both look completely different? Forget about normalising!

>> In which case, I'd be left wondering, is there ANYTHING that C or its
>> compilers do that is actually wrong,
>
> Yes.
>
>> or can you use C legalise to
>> argue that black is white?
>
> No.

It can spout a load of nonsense, but that's OK because it says so.

Bart <bc@freeuk.com> writes:
> On 07/08/2023 01:20, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> I showed the output above, it was:
>>>
>>> 0X9.18P+7
>>>
>>> The others looked like this:
>>>
>>> 0X1.230000P+10
>>>
>>> I expected you're going to tell me that 0x9.18p+7 conforms according
>>> to the C standard.
>>
>> No, I'm going to let you figure it out for yourself.
>>
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>> Section 7.21.6.1, paragraph 8. It's a long paragraph; scroll down to
>> the part that describes the a and A modifiers. I've also commented on
>> it in this thread; free free to re-read my article.
>
> OK, so the peculiar looking representation is to do with exactly the
> fact that it mixes up HEX digits with BINARY exponents.
>
> That means that adding +/- 1 to the exponent doesn't just shift the
> 'decimal' point one digit as happens with pure decimal, it moves
> inside the hex digit, so radically changing the appearance of the
> number that follows 0x.
>
> I guess we're all expected to sit and say with a straight face that
> that's alright then; so long as C says that it conforms, that's all
> that matters.

So you agree that both outputs conform to the requirements of the C
standard, right?

Of course you couldn't just say that without also whining that you don't
like what those requirements are.

[...]

> But then, that's just my opinion. After all what does it matter if
> you're trying to compare the hex-float output of the same value from
> two programs, and both look completely different? Forget about
> normalising!

You expect hex-float output to be easily human readable. You assume
that's its purpose.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 07/08/2023 02:12, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/08/2023 01:20, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
> [...]
>>>> I showed the output above, it was:
>>>>
>>>> 0X9.18P+7
>>>>
>>>> The others looked like this:
>>>>
>>>> 0X1.230000P+10
>>>>
>>>> I expected you're going to tell me that 0x9.18p+7 conforms according
>>>> to the C standard.
>>>
>>> No, I'm going to let you figure it out for yourself.
>>>
>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>>> Section 7.21.6.1, paragraph 8. It's a long paragraph; scroll down to
>>> the part that describes the a and A modifiers. I've also commented on
>>> it in this thread; free free to re-read my article.
>>
>> OK, so the peculiar looking representation is to do with exactly the
>> fact that it mixes up HEX digits with BINARY exponents.
>>
>> That means that adding +/- 1 to the exponent doesn't just shift the
>> 'decimal' point one digit as happens with pure decimal, it moves
>> inside the hex digit, so radically changing the appearance of the
>> number that follows 0x.
>>
>> I guess we're all expected to sit and say with a straight face that
>> that's alright then; so long as C says that it conforms, that's all
>> that matters.
>
> So you agree that both outputs conform to the requirements of the C
> standard, right?
>
> Of course you couldn't just say that without also whining that you don't
> like what those requirements are.

Is it not in your nature to be critical at all?

Do you not see the problem of a hex format, which is already confusing
because it is hex, representing the same value in different ways?

In decimal, pi is always going to involve the digits 314159... with the
decimal position depending on the exponent.

With %A format (I've made 0x and p lower case for clarity; another
issue), I can get either:

0xC.90FDAA22168Cp-2

or:

0x1.921FB5p+1

That's perfectly alright!

On 05/08/2023 11:46, Bart wrote:
> On 05/08/2023 03:44, Richard Damon wrote:

> > System headers are not allowed to bring in identifiers from another
> > system header without explicit indication that it should do so in the
> > Standard.
> >
> > As int32_t is an identifier in the user namespace UNLESS <stdint.h> has
> > been included by USER code, or it is defined to be included by some
> > header that it includes.
> >
> > The header you are talking about, is an INTERNAL header, used by system
> > headers other than <stdint.h>, so it isn't allowed to define symbols
> > like int32_t
> >
> > Do you not understand the rules of namespace?
>
> So, despite C99 introducing those types in stdint.h, system headers are
> not allowed to use stdint.h because it int32_t cannot be exposed to user
> programs unless they explicitly include stdint.h?
>

"System headers" is perhaps not an ideal term to use, because the term
is not clear.

C standard library headers cannot define any identifiers other than
those they say they will define, or that are within the reserved formats
(like starting with two underscores). They also have to work regardless
of the order people use them, and regardless of what identifiers user
code has defined before the #include. This means that a C library
header such as <string.h> that needs, say, "size_t" from <stddef.h>
can't just include that file itself - maybe the user wants to make their
own definition of NULL. The header can't just do a typedef for
"size_t", since perhaps the user has included <stddef.h> before
<string.h>. So you need guard macros around the typedef. The
declaration of a function or a macro in a standard header can't use
informative parameter names like "format" or "filename", because someone
might have defined these as macros before including the header.

These kinds of subtleties may be lost on you, because - like most C
programmers - you put your standard library headers at the start of your
C file, and don't do weird stuff in your coding. But serious libraries
and C standard headers have to take all this kind of thing into account,
and it makes them messy. But really, it doesn't matter - this is all
part of the implementation, and not something users need to examine or
understand - they should get their information from the documentation,
not the standard library headers.

Of course it is easy to see how this could all have been much better if
the C standard library (and C language itself) were re-done to get the
features of modern C without the need of backwards compatibility. So
when the C++ library was made, everything (except what it inherited from
C) was put inside the std:: namespace. Then any standard library
headers can freely include any others, since all the identifiers are in
a reserved namespace.

The term "system headers" could also refer to headers specific to the OS
- Windows headers, Linux headers, or whatever. These kinds of headers
most certainly /can/ use <stdint.h> and any other standard library
headers. They can also use whatever of their own headers they like, as
long as any identifier usage is documented. (But like many OS's, these
have histories stretching back before C99, and rarely use C99 headers
and types.)

> And those system headers cannot have stdint.h being included in any
> internal headerss that they call, for the same reason?
>
> Does that mean that none of the functions of the C runtime declared in
> the system headers will ever be allowed to use C99 types?
>

New ones certainly can. Old ones cannot.

So when C11 introduced <threads.h> and <stdatomic.h>, if the people
behind these APIs thought the <stdint.h> types would have been useful,
they could happily use them. But they would only have done so if there
were real benefits - they would not add dependencies unnecessarily.

> It gets better and better!
>

We are hoping that your understanding will get better and better. (Some
might say such optimism is unrealistic.) Your opinions, of course, are
your own - no one expects them to change. (And I don't think many
others have expressed opinions - we understand how C works, and why it
works that way, but that does not imply that any particular person here
likes every aspect of C or agrees with every design decision.)

> This explanation is anyway at odds with that provided by Kaz, where the
> code apparently is in an external library, not a component of the system
> library.
>

I believe the headers mentioned by Kaz were used for providing the C
standard library headers on some platform. Again, it really doesn't
matter how these are implemented or what other headers they use - it
only matters that the conform to the documented specifications for the
headers, providing the public interface that is documented without
interfering with any user-level symbols.

> If what you say is the case, then NO library should be allowed to use
> int32_t in their APIs, unless a prior '#include <stdint.h>' has been
> seen in any user code that wants to use that library.
>

User code can do what it likes. Library headers should conform to the
documentation for the library (or the documentation should match the
headers, whichever way works best). The C standard library headers have
to match the C standards documentation - other libraries make their own
choices.

But it is generally considered a good idea for most C headers that they
be usable stand-alone. That is, if a header makes use of <stdint.h>
types, then it should include <stdint.h> itself. Headers should also
have guards so that they can safely be included multiple times.
Well-designed headers should be usable regardless of the ordering of the
includes, and regardless of how many or how few are included. They
should at least work for code that puts the includes at the start and
does not go out of its way to be awkward. This restricts user coding
style more than the C standard library headers are allowed to do, but it
is more convenient for users and for the writers of the library headers.

> Because the user might be defining int32_t for their own purposes?

They can do, as long as they don't include <stdint.h> (or <inttypes.h>).

> (Isn't a _t suffix reserved?

By POSIX - not by C.

>
> I find that abolutely extraordinary.
>
> I thought C's type system was already a complete mess. This is verging
> on unbelievable.
>
> So, basically, C doesn't really have int32_t as a type, not one you can
> just use anywhere; it is a privileged type.
>

It is a type defined in a standard library header.

On 8/7/23 5:35 AM, Bart wrote:
> On 07/08/2023 02:12, Keith Thompson wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 07/08/2023 01:20, Keith Thompson wrote:
> >>> Bart <bc@freeuk.com> writes:
> > [...]
> >>>> I showed the output above, it was:
> >>>>
> >>>>        0X9.18P+7
> >>>>
> >>>> The others looked like this:
> >>>>
> >>>>        0X1.230000P+10
> >>>>
> >>>> I expected you're going to tell me that 0x9.18p+7 conforms according
> >>>> to the C standard.
> >>>
> >>> No, I'm going to let you figure it out for yourself.
> >>>
> >>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> >>> Section 7.21.6.1, paragraph 8.  It's a long paragraph; scroll down to
> >>> the part that describes the a and A modifiers.  I've also commented on
> >>> it in this thread; free free to re-read my article.
> >>
> >> OK, so the peculiar looking representation is to do with exactly the
> >> fact that it mixes up HEX digits with BINARY exponents.
> >>
> >> That means that adding +/- 1 to the exponent doesn't just shift the
> >> 'decimal' point one digit as happens with pure decimal, it moves
> >> inside the hex digit, so radically changing the appearance of the
> >> number that follows 0x.
> >>
> >> I guess we're all expected to sit and say with a straight face that
> >> that's alright then; so long as C says that it conforms, that's all
> >> that matters.
> >
> > So you agree that both outputs conform to the requirements of the C
> > standard, right?
> >
> > Of course you couldn't just say that without also whining that you don't
> > like what those requirements are.
>
> Is it not in your nature to be critical at all?
>
> Do you not see the problem of a hex format, which is already confusing
> because it is hex, representing the same value in different ways?
>
> In decimal, pi is always going to involve the digits 314159... with the
> decimal position depending on the exponent.
>
> With %A format (I've made 0x and p lower case for clarity; another
> issue), I can get either:
>
>    0xC.90FDAA22168Cp-2
>
> or:
>
>    0x1.921FB5p+1
>
> That's perfectly alright!
>

Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.

It can also be 0.50 or 0.50000

So even decimal has some ambiquity in its textual reprentation.

Yes, you can add rules to force many of representations to be "inferior".

Your problem with the Hex representation is that you don't understand
what its purpose is. IT isn't to allow you to compare two numbers, but
to EXACTLY (and faiy efficiently) represent a floating point number.

The flexability in exact representation is to make it possible to be
fairly efficient on most hardware, and it does NOTHING to harm the
ability to fulfil its mission.

If you want to compare to hex floating point strings to see if they
represent the same number, use a machine with at least as much precision
as the numbers and convert the values floating point and see if they
compare equal.

You fundamental issue in EVERYTHING seems to be that you can only look
at it through myopic eyes of your own (unusual) needs, and not from why
things are the way they are.

On Monday, 7 August 2023 at 12:42:11 UTC+1, Richard Damon wrote:
> On 8/7/23 5:35 AM, Bart wrote:
> > On 07/08/2023 02:12, Keith Thompson wrote:
> > > Bart <b...@freeuk.com> writes:
> > >> On 07/08/2023 01:20, Keith Thompson wrote:
> > >>> Bart <b...@freeuk.com> writes:
> > > [...]
> > >>>> I showed the output above, it was:
> > >>>>
> > >>>> 0X9.18P+7
> > >>>>
> > >>>> The others looked like this:
> > >>>>
> > >>>> 0X1.230000P+10
> > >>>>
> > >>>> I expected you're going to tell me that 0x9.18p+7 conforms according
> > >>>> to the C standard.
> > >>>
> > >>> No, I'm going to let you figure it out for yourself.
> > >>>
> > >>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> > >>> Section 7.21.6.1, paragraph 8. It's a long paragraph; scroll down to
> > >>> the part that describes the a and A modifiers. I've also commented on
> > >>> it in this thread; free free to re-read my article.
> > >>
> > >> OK, so the peculiar looking representation is to do with exactly the
> > >> fact that it mixes up HEX digits with BINARY exponents.
> > >>
> > >> That means that adding +/- 1 to the exponent doesn't just shift the
> > >> 'decimal' point one digit as happens with pure decimal, it moves
> > >> inside the hex digit, so radically changing the appearance of the
> > >> number that follows 0x.
> > >>
> > >> I guess we're all expected to sit and say with a straight face that
> > >> that's alright then; so long as C says that it conforms, that's all
> > >> that matters.
> > >
> > > So you agree that both outputs conform to the requirements of the C
> > > standard, right?
> > >
> > > Of course you couldn't just say that without also whining that you don't
> > > like what those requirements are.
> >
> > Is it not in your nature to be critical at all?
> >
> > Do you not see the problem of a hex format, which is already confusing
> > because it is hex, representing the same value in different ways?
> >
> > In decimal, pi is always going to involve the digits 314159... with the
> > decimal position depending on the exponent.
> >
> > With %A format (I've made 0x and p lower case for clarity; another
> > issue), I can get either:
> >
> > 0xC.90FDAA22168Cp-2
> >
> > or:
> >
> > 0x1.921FB5p+1
> >
> > That's perfectly alright!
> >
> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>
> It can also be 0.50 or 0.50000
>
or 0.49999999...

On 06/08/2023 13:56, Richard Damon wrote:
> On 8/5/23 9:17 AM, Bart wrote:
>> On 05/08/2023 03:50, Tim Rentsch wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 8/4/23 10:25 AM, Bart wrote:
>>>>
>>>>> [...]
>>>>
>>>> Maybe your problem is you dont understand [...]
>>>
>>> Bart's problem isn't that he doesn't understand.  Bart's
>>> problem is that he doesn't _want_ to understand.
>>
>> Bart is the kid who questions the Emperor's new clothes.
>>
>> You have a software system that has accumulated a mountain of now
>> unnecessary cruft. It's fair to ask why that mountain still exists.
>>
>> All I'm hearing is excuses.
>>
>> And after all this discussion about how great 'int32_t' is that we
>> shouldn't need to create aliases, now apparently we're not allowed to
>> use it unless we're an end-user?
>
> And, unless you are the implementation, you are.
>

Part of Bart's problem is that in his world, he is the sole language
designer, compiler implementer, library writer, and application code
programmer. That even applies to his C world, as well as his own
language, where his C compiler supports an unspecified
subset/superset/variation of some unspecified C standard. So he is not
used to the idea of making tools that handle existing code, or backwards
compatibility, or dealing with awkward styles of coding. He doesn't
have the same distinction between user-code and implementation code - if
he wants a function in his program, he can put it in user code or make
it a new keyword in the language with equal ease. And he is used to his
standard library headers and implementations being written in the same
style as user code, because they are written by the same person and have
no clear boundaries.

On 05/08/2023 15:17, Bart wrote:
> On 05/08/2023 03:50, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 8/4/23 10:25 AM, Bart wrote:
>>>
>>>> [...]
>>>
>>> Maybe your problem is you dont understand [...]
>>
>> Bart's problem isn't that he doesn't understand.  Bart's
>> problem is that he doesn't _want_ to understand.
>
> Bart is the kid who questions the Emperor's new clothes.
>

No, that (like so much else) is just in your imagination.

Everyone in this thread is perfectly aware of the short-comings of C.
Everyone knows that plenty of the parts of C standard library headers is
a mess (it's not just Newlib, though that might be one of the messiest).
The rest of us understand why, and understand that it doesn't matter
for people using C.

You are not telling anyone anything new, nor exposing hidden secrets.

On Monday, 7 August 2023 at 13:16:17 UTC+1, David Brown wrote:
> On 05/08/2023 15:17, Bart wrote:
> > On 05/08/2023 03:50, Tim Rentsch wrote:
> >> Richard Damon <Ric...@Damon-Family.org> writes:
> >>
> >>> On 8/4/23 10:25 AM, Bart wrote:
> >>>
> >>>> [...]
> >>>
> >>> Maybe your problem is you dont understand [...]
> >>
> >> Bart's problem isn't that he doesn't understand. Bart's
> >> problem is that he doesn't _want_ to understand.
> >
> > Bart is the kid who questions the Emperor's new clothes.
> >
> No, that (like so much else) is just in your imagination.
>
> Everyone in this thread is perfectly aware of the short-comings of C.
> Everyone knows that plenty of the parts of C standard library headers is
> a mess (it's not just Newlib, though that might be one of the messiest).
> The rest of us understand why, and understand that it doesn't matter
> for people using C.
>
> You are not telling anyone anything new, nor exposing hidden secrets.
>
It kind of matters. For instance my IDE has a "goto function definition" feature
when you right click on a function name. If you right click on a standard library
function, it will take you to the header. If the defintion is readable, it reminds
you how to use the function. If not, it's useless (this is more of a problem with
C++).