On 8/7/23 8:28 PM, Bart wrote:
> On 07/08/2023 22:51, Kaz Kylheku wrote:
> > On 2023-08-07, Bart <bc@freeuk.com> wrote:
> >>>> For example, I want to call the printf() function from the C runtime
> >> via an
> >>>> FFI; what format code do I use: is it %d, %ld or %lld?
> >>>>
> >>>> But those 'l' modifiers are in terms of C types, which are
> >> meaningless in
> >>>> my language;
> >>>
> >>> That is not C's fault; they are intended for C's types, not yours.
> >>
> >> They're bad idea for C as well, especially now with dozens of
> integer types.
> >>
> >> Imagine printing an expression with terms mixing half a dozen types,
> >> siged and unsigned, classic and C99, wide and narrow; how on earth do
> >> you figure out the final type? How do you maintain the format as the
> >> expression changes, or the types involved?
> >>
> >> You will probably suggest casting everything to long long int then
> using
> >> "%ll", but this was my idea from a few days ago to just use 64 bits
> >> everywhere, anyway.
> >
> > Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32
> > expands to the equivalent of "u" but  but for uint32_t.
>
> If only it was that simple. You are printing the expression:
>
>  printf("...", cond ? a+b*c : d+e);
>
> and need a format code to replace '...'.
>
> a, b, c, d, e have mixed types from the collection {long, int, time_t,
> char, uint32_t, uint8_t, T} in some combination that you have to go and
> look up. (T is some opaque typedef.)
>
> So the format should be simple to determine, right? Work out the result
> type of each branch of that ?:, work out the dominant type, and use that
> format code.
>
> But hang on, isn't the compiler much better at that then we are? It can
> also keep track of changes to the expressions and to the types of those
> variables, it even knows what type time_t and T are, and can update the
> format at 100 printf sites across the program.
>
> My view is that C's print-format system is not fit for purpose. The
> formatting is OK, it is needing to specify types that is the problem.

which is EXACTLY the arguement that got us the C++ stream << operator.

If you want to do that in C, you can, just define a generic "print"
function that defines version for each fundamental type, and call that.

You don't seem to understand that C is based on the assumption that the
programmer actually knows what he is doing, not hiding behind a mass of
abstractions.

>
>
> > In any halfway modern language with FFI, you should be able to solve the
> > problem easily. The FFI knows the sizes of all the types like int, long
> > and long long and can  match those to the derived types like int32 and
> > uint64, and select the appropriate conversion specifier letter; e.g. if
> > the type maps to "int", then "d" and so on.
> >
> > The reason we need the "PRI" macros in C is that we don't have
> > a compile-time calculation ability to produce the contents of
> > a string literal, and we usually need a format string as a literal.
>
> It gets tricky when using sprintf say from another language, which is
> then transpiled to actual C.

And why doesn't that other language implement a better print
functionality itself?

>
> Then you might get into trouble using %lld for a type you've defined in
> the C on top of int64_t. (On Linux64, int64_t in turn might be defined
> on top of 'long', which needs a %ld format.)
>
> (Actually there are more problems to do with the 'char*' type of the
> format string, when strings in the source language use a type more akin
> to 'unsigned char*'. Lots of fun and games can be had with that in
> trying to shut up the compiler.)

Again, you seem to be expecting that the C language will fix the
problems that you created yourself in how you (partially) defined your
language.

You are using C as a "portable assembler", but you don't actually seem
to want to understand the assembly language and are complaining because
the machine doesn't implement the fancy instructions you want to use.

On 8/7/23 6:19 PM, Kaz Kylheku wrote:
> On 2023-08-07, Bart <bc@freeuk.com> wrote:
>> On 07/08/2023 13:16, David Brown wrote:
>>> 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.
>>
>> You've heard of the term 'code smell'? Well stuff like that just
>> completely stinks.
>>
>> 50 years' plus and a /systems/ program language is incapable of
>> describing a simple machine type without making a dog's dinner of it?
>>
>> (It doesn't even create the type; it's making it possible for some other
>> code to create the type!)
>>
>>
>>> 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.
>>
>> OK. So you don't think there is, right now, any other shorter solution
>> to that set-up code which uses an #if-#else ladder to define __int32_t?
>
> That was only in a specific library, Newlib.
>
> The GCC header stdint-gcc.h just does this:
>
> #ifdef __INT32_TYPE__
> typedef __INT32_TYPE__ int32_t;
> #endif
>
> The compiler somehow predefines these symbols, and so the header just
> tests for the ones that exists and defines the public typedefs.
>
>> And you don't think that C99 could have been done any differently to
>> make such code shorter, or unnecessary?
>
> The only thing C99 could have done differently would have been to
> arrive decades earlier.
>
> Ideally, Newlib shouldn't be defining a <stdint.h> header at all;
> it should come from the compiler!

That misses the point that Newlib is designed to be "part of the
implementation" in a world where the complier writer doesn't provide a
full implementation, but depends on a libary writer to finish it.

This makes the library-implementers job tough, as they need to figure
out (or hopefully read in the documentation) how the various compilers
provide the fundamental information about the implementation, and build
the headers to support the parts the compiler-implementer doesn't.

>
> If <stdint.h> were some ancient thing that long preceded the Newlib
> project by decades, the library might perhaps have taken it for
> granted that the compiler provides it, and not bother trying to
> make its own.
>
> That can't be blamed on C99; C99 doesn't specify (nor forbid) that an
> implementation is a system that is made from pieces that come from
> different parties, like unrelated compiler people and library people,
> where there cna be overlap about who provides what header and such.
>
>> (I've just spent 20 minutes doing an experiment: adding an optional
>> /built-in/ type 'int32_t' to my C compiler.
>
> You don't seem to understand that this breaks a contract.
>
> C programs are free to define int32_t themselves if they have
> not included a header which defines it. If there is a conflicting
> file-scope definition (or worse, some built-in feature), which doesn't
> get out of the way of the user's definition, then those programs
> break.
>
> No C compiler vendor that has users other than themselves can do this,
> no matter how easy it is.
>
> (Or rather, they can provide it as a nonconforming extension, which is
> disabled in a conforming mode. Nonconforming extensions that can be
> turned off is how you can make a nicer dialect of C, which is
> compatible. GNU C has a bunch of them.)
>
>> Unless told otherwise, 'int32_t` is a built-in alias (in my case for
>
> That just seems silly; if you have typedef working, you can make it a
> typedef. Typedef is exactly a type aliasing mechanism. A typedef can be
> built in: it can constructed on startup and inserted into the scope as
> if a declaration were read.
>
> If int32_t is a typedef, you can lexically shadow it:
>
> { int int32_t = 3; }
>
> If that is not possible with a built-in alias, then it's just a broken
> typedef that doesn't play along with scopes.
>

On 8/7/23 1:10 PM, James Kuyper wrote:
> On 8/7/23 12:20, Kaz Kylheku wrote:
> ...
>> I think the main use case for this is faster serialization and
>> deserialization. Like logging vast amounts of floating-point data to a
>> file, or sending over network-like channels. It's not as fast as
>> using raw binary binary images of the types, but doesn't have the
>> byte order issues, or possibility of non-printable characters
>> like null bytes.
>>
>> I suspect the representation might also be able to exactly record
>> specific NaN representations and subnormals and such?
>
> The strtod() functions allow strings of the form "NAN(n-char-sequence)".
> The meaning of that n-char-sequence is implementation-defined.
>
>
> For printf() with the a specifier, the standard specifies that "A double
> argument representing an infinity or NaN is converted in the style of an
> f or F conversion specifier."
> For the 'f' specifier it says "A double argument representing an
> infinity is converted in one of the styles [-]inf or [-]infinity — which
> style is implementation-defined. A double argument representing a
> NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence)
> — which style, and the meaning of any n-char-sequence, is
> implementation-defined. The F conversion specifier produces INF,
> INFINITY, or NAN instead of inf, infinity, or nan, respectively.301)"
>
> I believe that the intent was to allow floating point numbers created by
> strtod("NAN(n-char-sequence)") to be printed using any floating point
> format, with the output n-char-sequence being the same as that passed to
> the strtod() call. However, for whatever reason, the standard only
> allows that behavior, it does not mandate it - presumably there are
> platforms where it would be prohibitively difficult to implement that
> behavior.
>

IT can't work in that direction, as a given system will only support a
certain set of n-char-sequence values.

On 04/08/2023 19:07, Bart wrote:
> On 03/08/2023 22:42, David Brown wrote:
> > On 03/08/2023 03:07, Bart wrote:
> >> What's the point? You will discard any examples as being just some guy
> >> on the internet.
> >>
> > poster, and, say, a researched and considered blog article.  I'm not
> > looking for very much, but more than you've managed.  However, I am also
> > not expecting you to go to a lot of effort here - you have no
> > justification or evidence for your claims easily available, so let's
> > leave it at that.
>
> What are my claims?
>

You claimed lots of people are using typedefs for the <stdint.h> fixed
size types specifically because they are ugly and long-winded. So far,
all you have shown is that people quite often want fixed-size types (and
we all knew that), and that sometimes people use typedefs for the
<stdint.h> types, either for reasons unknown, or for other given reasons
(and we all knew that too). There has been no evidence or basis for
people doing so for /your/ reasons, other than a brief comment by
someone else who doesn't much like the "int32_t" form. But maybe
evidence will emerge later in this post as I read it.

> I'm saying lots of people do this, create new aliases that are more
> appealing than what C provides. I've seen open source code that does it
> (but I don't keep a record of every single site), I've seen people
> talking about doing it on forurms, and talking about seeing others do
> it, for example:
>
> "I also see "uint8" on a regular basis. I also understand this to be an
> unsigned 8 bit structure. Basically, it is a "byte". Again, why not use
> a "byte"?"
>
> This is in an Arduino forum. I didn't quite understand the remark about
> 'byte', but later in the thread:
>
> "...I believe it is. Funnily enough it is defined (in Arduino.h) as:
> typedef uint8_t byte;"
>
> Sure enough here it is
> (https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/Arduino.h):
>
>
>   typedef uint8_t byte;
>
> You would not approve of course.

It's not necessary, but the term "byte" is very familiar, and some
people prefer that name. However, that does not fall under your claim -
it is giving a new name with different associations, not shortening or
de-uglifying "int32_t".

To my mind, "byte" means "an 8-bit item of memory or data", while
"uint8_t" means "an unsigned 8-bit integer". They are different names,
with different meanings, and I see no problem using both.

I would be happy to see functions like "memcpy" using "byte" as their
types, for example. I'd be less happy seeing "byte" in the context of
arithmetic (though it is still far better than "unsigned char").

> Here is a tutorial:
>
>   https://www.tutorialspoint.com/cprogramming/c_typedef.htm
>
> which shows typedef used to define BYTE an an alias for 'unsigned char'.
>

I don't approve of that one, no. An all-caps name is very bad style.

Using "byte" for "unsigned char" is reasonable, especially pre-C99. The
tutorial appears to be mainly C90, with no mention of standard versions
that I can see, but sometimes with a small bit of C99 syntax thrown in.

But there is far too much wrong with that C tutorial to give a proper
critique here. It's easy to find (and to write) very bad tutorials for
a language - good ones are rare.

> Although not mentioned, it is clear to me that BYTE is perceived as a
> dandier type denotation for an 8-bit unsigned type than 'unsigned char'.
> Why however didn't they choose 'uint8_t' instead; it's a mystery!
>
>
> Here's another tutorial
> (https://piratelearner.com/en/C/course/computer-science/c-programming/typedef-your-data-types/47/),
> where it creates (scroll down) aliases with names like 'uint8' and
> 'int32'. Notice no '_t' prefixes.
>

This is also very muddled. It claims that sizeof(int) is 2 on a "32-bit
processor with a 16-bit compiler", and 8 on a "64-bit processor with a
64-bit compiler". /Very/ muddled.

> That link is 7 years old and actually, if you scroll further, it defines
> 'int32' on top of 'int32_t'. Even where stdint.h is missing as it
> suggests, someone could have chosen to define their own 'int32_t', but
> chose 'int32'. Another mystery!
>

You could ask the author of the post, rather than me. But it looks like
he is trying to pick a set of names that can be used with C99 (which he
refers to as "most of the linux based operating systems as well as high
level microcontrollers") and C90 (which he refers to as "most of the
microcontroller families"), and his intention is a set of fixed-size
types which are independent of the standard names. If that is the case,
"int32", etc., seem reasonable. But again, he's got so much wrong and
confused that it is not at all clear.

I don't want to sound prejudice, but in some countries there seems to be
pressure on developers to publish blogs or articles, even if they are
not particularly familiar with the subject, or able to write very
clearly in English. This is clearly written by a beginner who has
learned some C from a poor quality course. There are, unfortunately,
many institutions around the world that have teachers who are decades
out of touch, and course material that is decades out of date. Then the
students regurgitate the half of it that they have understood, and
google will find it as though it were a useful article. A good clue, if
you need any more, is to look at the comments in the code - the only
ones that are not utterly useless and superfluous, are wrong. The
author is following his teacher's command to always put comments in the
code without the faintest understanding of the point of them.

> Here's a quote from a stack exchange question asking about why it is
> 'int32_t' and not 'int32':
>
> "At the time the C99 Standard was ratified, there already existed
> countless C programs that used int32 as an identifier. "
>
> Note the word 'countless'.

Note the authority of "someone on stack exchange".

I don't doubt that their comment is true, but I don't consider "someone
said it on the internet" as synonymous with "fact".

> You asserted that _t was commonly by people
> who had to make their own fixed-width typedefs. I've seen little
> evidence of that.
>

Fair enough. And I am not going to research it. I know these names
were used, I know _t identifiers were in common use in at least some
kinds of code, I know POSIX standardised that usage, I know they had
been in common use from the early days of C (such as "size_t"), I know
the C99 rationale says the <stdint.h> types were defined the way they
were "to standardise existing usage". It could well be based on
existing C libraries or C compilers more than user code.

But I am not at all contending the fact that "int32", "word", "BYTE",
and countless other names have also been used, and are still used. That
was never in contention.

>
> This one is interesting:
> https://dox.ipxe.org/include_2stdint_8h_source.html
>
> It defines a bunch of aliases for the stdint.h types, such as both 's32'
> and 'int32' for 'int32_t'. It's a little unusual in using 's32' rather
> than 'i32', although when you think about it, 's' for 'signed' makes sense.
>
> (I don't do that because all my 'int' types are signed.)
>
> Why these aliases? You tell me, since you just WILL NOT BELIEVE THAT
> PEOPLE MIGHT PREFER them, so there must be another reason, right?
>

Rather than shouting with capitals, why don't you try reading what I write?

I have at no time denied that people often choose "int32" (or smaller)
formats for their names, when there are no other guiding or overriding
reasons. I expect "int32" is the most popular format, out of many
possibilities - including "i32", "s32", "int4", "int32_t", and
non-numerical names like "integer", "number", "signed_word", or whatever
else.

What I /have/ contested is your claim that many people find the
<stdint.h> names so ugly or long-winded that they use different names
for that reason alone. And still I have not seen anything justifying
that claim - except a couple of brief comments by anonymous users on web
forums. Examples of people using different names are not evidence
unless you can reference the reason behind those names.

On 04/08/2023 19:32, Malcolm McLean wrote:
> On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
>>
>> Basically, everybody is at it, because nobody is in love with what C
>> provides: the choice is between 'unsigned char', and '#include
>> <stdint.h> uint8_t', and both stink.
>>
> There should be a keyword "byte".

I'd have preferred that too. I think there should have been a "byte"
type that had the magic aliasing property, and that char types should
follow the same aliasing rules as other types. "Byte" should not have
any arithmetic operation. But history is against us.

> unsigned chars should not be character
> data, so "char" is a misnomer.

I don't find "signed" or "unsigned" to make sense with characters.
Ideally, IMHO, there would be "byte" (for raw memory access), "char" for
characters, and "uint8_t" and "int8_t" for small numbers (these would be
the only ones supporting arithmetic).

> And uint8_t means that the data has to be
> exactly 8 bits.

Yes, which is usually what people want (except for extreme portable coding).

> Which is only the case if the program is using overflow as
> a free modulus 256 operation.

Nonsense. These types are rarely used for arithmetic (except on 8-bit
devices), and overflow does not matter.

> Which almost always is poor programming.
> So it's hard to see where it has any place at all.
>

It is useful when you want a small unsigned integer. For most people,
that only matters when you want to store a large number of them.

On 08/08/2023 01:59, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/08/2023 22:52, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> 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!
>>>
>>> No, for two reasons (and I don't believe you got that specific output
>>> from a non-buggy implementation).
>>>
>>> First, the "%A" format uses uppercae letters; I don't know how you got
>>> that mix of lowercase x and p and uppercase hex digits.
>> I said 'I've made 0x and p lower case for clarity'.
>
> Sorry, I missed that.
>
> Why didn't you just use "%a" rather "%A" and show us the actual output?
> It would have been:
> 0xc.90fdaa22168cp-2
> 0x1.921fb5p+1
> which seems clear enough.

In the first, there isn't enough contrast between x and c, or c and p; I
wanted the hex digits to be visually distinct from the X and P at either
end.

>
>>> Second, because they represent different values, because you used
>>> different numbers of digits.
>>
>> I'll try to recreate the program, but I can't remember how many digits
>> of pi I used, or whether I got some wrong; the exact value didn't
>> matter, I was showing how different the output can be.
>>
>> But with the program below I get the given outputs:
>>
>> c:\c>type c.c
>> #include <stdio.h>
>> int main(void) {
>> printf("%A\n", 3.14159265358979);
>> }
>>
>> c:\c>bcc c
>> Compiling c.c to c.exe
>> c:\c>c
>> 0X1.921FB5P+1
>>
>> c:\c>gcc --version c.c
>> gcc (tdm64-1) 10.3.0 ...
>>
>> c:\c>gcc c.c
>> c:\c>a
>> 0XC.90FDAA2216888P-2
>
> On my Windows system using Cygwin gcc (with the printf implementation
> provided by newlib) I get:
> 0X1.921FB54442D11P+1
> With TDM-GCC, I get the same output you get:
> 0XC.90FDAA2216888P-2
> Both are valid, confirmed by running a program containing
> printf("%.64f\n%.64f\n", 0X1.921FB54442D11P+1,
0XC.90FDAA2216888P-2);
> which prints:
> 3.1415926535897900073734945181058719754219055175781250000000000000
> 3.1415926535897900073734945181058719754219055175781250000000000000
> (I'm not discussing whether choosing a different leading hex digit is
> good or bad. It's permitted by the standard.)
>
> (I haven't figured out where TDM-GCC gets its printf implementation.
> The executable depends on msvcrt.dll, but I don't think that tells us
> anything -- and I doubt that msvcrt.dll supports "%a" and "%A".)
>
> The output with bcc appears to be incorrect, since it doesn't show the
> full precision required by the C standard. It is not "an exact
> representation of the value". 1.921FB5 in hexadecimal is 25 bits; type
> double should be able to represent about 53 bits of precision.
>
> bcc is your implementation, right?

It's my compiler, but it uses msvcrt.dll to do the print. tcc uses the
same library with the same output. Both seem to use a default of 6
places after the ".", whether hex or decimal.

If I write it in x64 assembly, using my assembler since I know for sure
it links to msvcrt.dll and nothing else (it does not use a linker, it
directly creates the EXE):

main:: # :: makes it global
mov rcx, format
mov rdx, [pi]
movq xmm1, [pi]
call printf* # * means imported name
mov rcx,0
call exit*

isegment
format:
db "%A",10,0

pi:
dq 3.141592653979

I get the same output:

c:\ax>aa test
Assembling test.asm to test.exe

c:\ax>test
0X1.921FB5P+1

Inside the EXE:

Import Directory

Entry: 4000
Lookup RVA: 4028
Time Date Stamp: 0
Fwd Chain: 0
Name RVA: 4074
Name: msvcrt.dll
Import Addr RVA: 4040
Import: 4058 0 printf
Import: 4062 0 exit

If I look inside gcc's EXE file, it imports 59 functions from
kernel32.dll, and 45 from msvcrt.dll, including printf, but this gcc
10.3.0's use of 'printf' has always varied considerably from the one
inside msvcrt.dll. For one, it is much slower.

If I look inside this gcc's stdio.h, it defines printf like this:

__mingw_ovr
__attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
int printf (const char *__format, ...)
{ int __retval;
__builtin_va_list __local_argv; __builtin_va_start( __local_argv,
__format );
__retval = __mingw_vfprintf( stdout, __format, __local_argv );
__builtin_va_end( __local_argv );
return __retval;
}

So it's anyone's guess what it actually uses. My stdio.h has this:

int printf(const char*, ...);

(Yeah, I naughtily leave out 'extern'.)

On 04/08/2023 20:53, Malcolm McLean wrote:
> On Friday, 4 August 2023 at 19:37:06 UTC+1, Bart wrote:
>> On 04/08/2023 18:32, Malcolm McLean wrote:
>>> On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
>>>>
>>>> Basically, everybody is at it, because nobody is in love with what C
>>>> provides: the choice is between 'unsigned char', and '#include
>>>> <stdint.h> uint8_t', and both stink.
>>>>
>>> There should be a keyword "byte". unsigned chars should not be character
>>> data, so "char" is a misnomer. And uint8_t means that the data has to be
>>> exactly 8 bits. Which is only the case if the program is using
>> overflow as
>>> a free modulus 256 operation. Which almost always is poor programming.
>>> So it's hard to see where it has any place at all.
>> Sorry, I can't make sense of that.
>>
>> Are you saying there is a place for 'byte' or not? And as a keyword, or
>> a built-in type?
>>
> There's place for "byte". It could be either a keyword or it could be a typedef
> for "unsigned char". The latter would be eaiser to implement but would mean
> that any source file using it would have a dependency.

Most source files use lots of includes. Having #include <stdbyte.h> in
order to use "byte" would hardly count as a challenge. Making it a
keyword, however, would be out of the question - you would break every
program that currently uses it as an identifier. You could, however,
have _Byte as a keyword. And making it a new language type would be the
only way to get it a as a type which does not support arithmetic,
integer promotion, etc.

>>
>> Clearly, 'uint8_t' is the type for an 8-bit unsigned value, obviously,
>> it will be 8 bits, that's the whole point! Since pretty much all
>> hardware will have 8-bit bytes and be byte-addressable, and it is what
>> UTF8 for example expects.
>>> Which is only the case if the program is using overflow as a free
>> modulus 256 operation.
>> You've lost me.
>>
> If CHAR_BIT is greater than eight, then programs expecting data as
> unsigned chars should still work, unless the programmer has elected
> to use overflow as a free modulus 256 operation. (Of course you can
> pass invalid data to the function if CHAR_BIT is over eight, which you
> often can't if it is exactly eight. However almost every function allows
> you to pass some bad values.)

I can appreciate why Bart feels you lost him - sometimes it is very hard
to follow your imagination. Are you seriously worried about people
assuming "unsigned char" has an implicit modulo 256 and then compiling
that code for targets with CHAR_BIT > 8 ? What kind of code do you
think that might be?

I never write functions that allow you to pass bad values. If you want
to call my functions, you have to understand the specification for the
function and it is your responsibility to pass it correct data. The
responsibility of the function is to do the correct thing with valid
input. That's how you do programming.

> Now it is very unlikely with current technology that a general-purpose
> routine will ever have to tun on a platform where CHAR_BIT is not eight.
> But why gratuitiously break things if it is larger? It doesn't make any
> sort of sense.

The decision to fix on 8-bit bytes was made long ago, and will not
change any more than you would expect normal human-friendly numbers to
change from base 10. While there are DSP devices with CHAR_BIT > 8,
these are specialised chips and their use is getting steadily more
niche. They are irrelevant for the vast majority of programmers, and
will not get more popular - there will be no new architectures with a
byte size other than 8 bits. No languages other than assembly and C
(and very occasionally, subsets of C++) will by used on such devices.

So when taking about C standards, you need to consider that CHAR_BIT is
not fixed at 8. But not for practical purposes unless you /know/ you
are working with such devices.

(Ironically, the most popular 16-bit char DSP processor is almost never
used for any DSP work, but as a microcontroller for some specialist
use-cases.)

>>
>> In C, you would tend to use 'signed or unsigned char' for small
>> integers, and plain 'char' where the values represent text. Partly
>> because the unspecified signedness of plain char causes problems.
>>
>> Of course, sometimes you want to do calculations with character values,
>> or use them for indexing, then using plain char is fraught with danger.
>> But you can't just forget 'plain char', as strings use it, and is in
>> countless APIs.
>>
>> C /should/ have had only 2 'char' types, signed and unsigned, with
>> strings being sequences of the 'unsigned' version.
>>
> The problem is that char is nearly but not quite an opaque type.
> You do need to treat chars as small integers to implement functions
> such as "itoa" effiiciently.

No, you do not. It can be helpful to assume that ('0' + i), where "i"
is between 0 and 9, will give you the digits '0' to '9' - the C language
guarantees that. But that is "int" arithmetic, not "char" arithmetic.

On Tuesday, 8 August 2023 at 11:32:52 UTC+1, David Brown wrote:
> On 04/08/2023 19:32, Malcolm McLean wrote:
> > On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
> >>
> >> Basically, everybody is at it, because nobody is in love with what C
> >> provides: the choice is between 'unsigned char', and '#include
> >> <stdint.h> uint8_t', and both stink.
> >>
> > There should be a keyword "byte".
>
> I'd have preferred that too. I think there should have been a "byte"
> type that had the magic aliasing property, and that char types should
> follow the same aliasing rules as other types. "Byte" should not have
> any arithmetic operation. But history is against us.
>
> > unsigned chars should not be character
> > data, so "char" is a misnomer.
>
> I don't find "signed" or "unsigned" to make sense with characters.
> Ideally, IMHO, there would be "byte" (for raw memory access), "char" for
> characters, and "uint8_t" and "int8_t" for small numbers (these would be
> the only ones supporting arithmetic).
>
> > And uint8_t means that the data has to be
> > exactly 8 bits.
>
> Yes, which is usually what people want (except for extreme portable coding).
>
> > Which is only the case if the program is using overflow as
> > a free modulus 256 operation.
>
> Nonsense. These types are rarely used for arithmetic (except on 8-bit
> devices), and overflow does not matter.
>
If you're holding a colour channel for 24 bit images, for example, you need a
type which can represent values 0-255. So 8 bits minimum. But if you have
9 bits, because for some reason that's the way technology has gone, then
it shouldn't be a problem. You waste the top bit, but you can still represent all
the allowed values. However the code will fail if the programmer uses overflow
intentionally as a free modulus operation. That can be an issue if people want
to calcuate the difference between two image.

On 08/08/2023 03:21, Richard Damon wrote:
> On 8/7/23 8:28 PM, Bart wrote:
>> My view is that C's print-format system is not fit for purpose. The
>> formatting is OK, it is needing to specify types that is the problem.
>
> which is EXACTLY the arguement that got us the C++ stream << operator.
That feature is so bad it makes using printf preferable! Is it really
that hard to just be able to write 'print x' ?

> If you want to do that in C, you can, just define a generic "print"
> function that defines version for each fundamental type, and call that.
>
> You don't seem to understand that C is based on the assumption that the
> programmer actually knows what he is doing, not hiding behind a mass of
> abstractions.

You don't get my point. The programmer might not know for sure the type
of a complex expression, and certainly does not want to keep updating
dozens of printf formats across the codebase as global declarations change.

Right now I don't know how to print a clock() result for example, and to
keep inventing special formats like %zu is crass.

*I* can just write:

println a, b, c

So can a dozen other languages (even from the 1960s!). I can change the
types of a, b, c, and it still works. I can print c, b, a and it still
works.

I can even just do 'print clock()'!

In C YOU CAN'T DO THAT. You need to dig up the types of each expression
and apply the right format. In this VERY simple case, it MIGHT be:

printf("%lld " PRId64 " %s", a, b, c);

But now you have an extra maintenance headache.

(In all cases, printing gets untidy when you need to do necessary
formatting, but only C incorporates types into the formatting.)

>> It gets tricky when using sprintf say from another language, which is
>> then transpiled to actual C.
>
> And why doesn't that other language implement a better print
> functionality itself?

It does, but ultimately it needs to do I/O, and I've been using C's
printf for that since the mid-90s, because it was simpler than using
WinAPI. I've since forgotten how do it with WinAPI.

For that purpose, I only need to use %c and %s. (For floats, I use
sprintf with %e %f %g, do any formatting, then use printf with %s if I
need output.)

So most of the time it is not an issue (other than, if using C
transpilation, there is still the problem of C's char* type not existing
in my language, nor any other).

Sometimes however, during bootstrapping or developing a new compiler, it
might not yet support the 1000 lines of code needed to implement my
Print routines, or there are codegen bugs, or I'm trying to keep test
code absolutely minimal, then I will use printf.

Or I might use it from my dynamic scripting language. I just use %ll
since everything is 64 bits. Or I can test that other matter:

printf("%A", pi) # interpreted code

shows:

0X1.921FB5P+1

> You are using C as a "portable assembler", but you don't actually seem
> to want to understand the assembly language and are complaining because
> the machine doesn't implement the fancy instructions you want to use.

Exactly. C *IS* used extensively as a portable assembler, as an
intermediate or target language, and there you don't want its UBs,
foibles and quirky type system to get in the way, because source
language and final targets are better defined than in C.

This is an important use-case which should not be forgotten.

On 04/08/2023 20:25, Bart wrote:
> On 04/08/2023 18:00, Vir Campestris wrote:
> > On 02/08/2023 16:58, David Brown wrote:
> >> I don't believe I have written many real C programs in which the name
> >> of the final executable matched the name of any of the C files that
> >> went into it.  Having "gcc prog.c" result in "prog" (or "prog.exe" for
> >> Windows) is as useless to me as having it result in "a.out".  Other
> >> people will have different ideas and needs - but that's the real
> >> point. gcc is made for lots of people, and cannot possibly suit
> >> everyone with its defaults.  Just because one person, such as
> >> yourself, imagines that their preferences are somehow near universal,
> >> does not make them so.
> >
> > Way back in time I have. We had a number of utilities which consisted of
> > a single source file that compiled into a single binary. This was for
> > 8086 class systems, so with a megabyte of RAM.
>
> I'm sure you don't need to go that far back in time. I have loads of
> smallish programs lying around that are a single module (eg. lisp.c,
> minibasic.c, nano.c [a jpeg decoder]).

And I am sure many others are the same. I have only talked about /my/
programs.

>
> There are libraries (eg. bignum.c) and dozens of single file benchmarks.
> Most challenges that have been done in this newsgroup will have suited a
> single source file.
>
> David Brown I'm sure has never even compiled 'hello.c'. Or maybe he
> doesn't count single-module programs as 'real'. (Maybe he's one of those
> who likes to put each function into a dedicated file.)
>

You are correct that I don't count "hello.c" as a "real" program.

No, I do not put a function in each file. (That is usually done for
making static libraries, not for programs.) But I do split up my
programs in files of manageable size according to logical divisions. I
think most people do.

> I used to distribute my programs as generated C, always comprising a
> single source file, and requiring only a bare C compiler to build. So it
> would have been nice if the instructions to build and run were something
> like:
>
>     gcc prog.c
>     prog
>

I don't disagree that this would have been nice for you, and for a
number of other people. It would be useless for most people, especially
historically in C (remember, gcc originates in a world where people can
happily write "make prog" to get the same effect - saving a keystroke!).
And for some people using gcc to replace even older compilers,
changing the default from "a.out" would have been inconvenient.

> Besides, with pretty much every other language with a command-line build
> process, if you submit a single source file 'fred.lang', it will produce
> a matching executable 'fred.exe` without needing to be told how.

Pretty much every other language is not C, and does not have the history
of C or the history of C compilers.

And for pretty much every compiled language, you can type "make fred"
and get the executable "fred" from the source C, C++, Fortran, D, or
whatever.

And pretty much every serious programmer uses build tools, regardless of
the language - whether it be make, ant, bake, their own batch files,
IDEs, or whatever suits them. I no of no one else who goes so far out
of their way to make life difficult for themselves just so that they can
complain about how hard it all is.

On Tuesday, 8 August 2023 at 12:05:48 UTC+1, Bart wrote:
> On 08/08/2023 03:21, Richard Damon wrote:
> > On 8/7/23 8:28 PM, Bart wrote:
> >> My view is that C's print-format system is not fit for purpose. The
> >> formatting is OK, it is needing to specify types that is the problem.
> >
> > which is EXACTLY the arguement that got us the C++ stream << operator.
> That feature is so bad it makes using printf preferable! Is it really
> that hard to just be able to write 'print x' ?
> > If you want to do that in C, you can, just define a generic "print"
> > function that defines version for each fundamental type, and call that.
> >
> > You don't seem to understand that C is based on the assumption that the
> > programmer actually knows what he is doing, not hiding behind a mass of
> > abstractions.
> You don't get my point. The programmer might not know for sure the type
> of a complex expression, and certainly does not want to keep updating
> dozens of printf formats across the codebase as global declarations change.
>
> Right now I don't know how to print a clock() result for example, and to
> keep inventing special formats like %zu is crass.
>
> *I* can just write:
>
> println a, b, c
>
> So can a dozen other languages (even from the 1960s!). I can change the
> types of a, b, c, and it still works. I can print c, b, a and it still
> works.
>
> I can even just do 'print clock()'!
>
> In C YOU CAN'T DO THAT. You need to dig up the types of each expression
> and apply the right format. In this VERY simple case, it MIGHT be:
>
> printf("%lld " PRId64 " %s", a, b, c);
>
> But now you have an extra maintenance headache.
>
> (In all cases, printing gets untidy when you need to do necessary
> formatting, but only C incorporates types into the formatting.)
> >> It gets tricky when using sprintf say from another language, which is
> >> then transpiled to actual C.
> >
> > And why doesn't that other language implement a better print
> > functionality itself?
> It does, but ultimately it needs to do I/O, and I've been using C's
> printf for that since the mid-90s, because it was simpler than using
> WinAPI. I've since forgotten how do it with WinAPI.
>
> For that purpose, I only need to use %c and %s. (For floats, I use
> sprintf with %e %f %g, do any formatting, then use printf with %s if I
> need output.)
>
Virtually any integer which represents a value rather than a collection of bits
can be represented exactly by a double.
So
printf("%g\n", (double) x);
should do what you want, regardless of the type of x.
>
> > You are using C as a "portable assembler", but you don't actually seem
> > to want to understand the assembly language and are complaining because
> > the machine doesn't implement the fancy instructions you want to use.
> Exactly. C *IS* used extensively as a portable assembler, as an
> intermediate or target language, and there you don't want its UBs,
> foibles and quirky type system to get in the way, because source
> language and final targets are better defined than in C.
>
> This is an important use-case which should not be forgotten.
>
Yes, C is an important target language for compilers. I'm putting the finishing
touches to an automatic C-generating program myself.

On 08/08/2023 11:32, David Brown wrote:
> On 04/08/2023 19:32, Malcolm McLean wrote:
>> On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
>>>
>>> Basically, everybody is at it, because nobody is in love with what C
>>> provides: the choice is between 'unsigned char', and '#include
>>> <stdint.h> uint8_t', and both stink.
>>>
>> There should be a keyword "byte".
>
> I'd have preferred that too.  I think there should have been a "byte"
> type that had the magic aliasing property, and that char types should
> follow the same aliasing rules as other types.  "Byte" should not have
> any arithmetic operation.  But history is against us.

I think it would cause problems in a systems language.

In Algol68, you have signed INTs, with arithmetic operations but not
logical ones. And BITs which represent machine words, with logical
operations but not aritmetic. You spend half your time converting
between between one and the other.

I also have distinct 'char' and 'byte' types, both unsigned 8 bits, and
at one time 'char' was strictly typed:

* char+int was allowed, but not char+char, or char*char
* Pointers to char and byte were incompatible

It caused no end of problems with pointless casts needing to be inserted
in too many. And decisions to be made: should a file-reading function
returning a pointer to char, or to byte? Files can be text OR binary!

Now 'char' and 'byte' are more or less compatible. The main difference
is that if I print a char value of 65, it shows A not 65. And printing a
pointer to char assumes it is a string. Also, 'X' has type char.

On Tuesday, 8 August 2023 at 12:11:47 UTC+1, David Brown wrote:
>
> And pretty much every serious programmer uses build tools, regardless of
> the language - whether it be make, ant, bake, their own batch files,
> IDEs, or whatever suits them. I no of no one else who goes so far out
> of their way to make life difficult for themselves just so that they can
> complain about how hard it all is.
>
Yes. But they make me nervous. We've got a system which involves Conan,
CMake, the Xcode and Visual Studio IDEs, and Azure. Plus git for versioning.

However if any one of these elements goes wrong, the process falls over.
And it's hard to fix because, for example, I rarely write CMake scripts. Not
often enough to be really familar with the system. And our CMake build scripts
are effectively a program in their own right.

I used CMake for the Baby X resource compiler. It worked on Windows and Mac.
But it broke on Linux when Ben tested it. Because it wasn't actually passing the "-lm"
option to link the math library. That the sort of problem you don't need.

On 08/08/2023 12:11, David Brown wrote:
> On 04/08/2023 20:25, Bart wrote:
>> Besides, with pretty much every other language with a command-line
>> build process, if you submit a single source file 'fred.lang', it will
>> produce a matching executable 'fred.exe` without needing to be told how.
>
> Pretty much every other language is not C, and does not have the history
> of C or the history of C compilers.

That is irrelevant. C compilers like Pelles C, lccwin32, DMC, Tiny C
(Windows), MSVC plus mine of course manage to do it properly, despite
that history.

It is one stupid decision in one compiler that nobody has bothered to
fix. At least give it an option to override, but in a form where you
don't need to provide a file name. Example:

gcc -new prog.c

will use the rule that the name of the executable is taken from the
first or only submitted C file. Would that have been too hard?

No. It is just plain stubbornness, because we WANT to still be doing
-ofile.exe and -lm even into the next millenium.

> And for pretty much every compiled language, you can type "make fred"
> and get the executable "fred" from the source C, C++, Fortran, D, or
> whatever.
>
> And pretty much every serious programmer uses build tools, regardless of
> the language - whether it be make, ant, bake, their own batch files,
> IDEs, or whatever suits them. I no of no one else who goes so far out
> of their way to make life difficult for themselves just so that they can
> complain about how hard it all is.

No so much hard; it just doesn't work. I've seen too many failures of
'make' on Windows; I /have/ given it a chance.

People over-complicate build systems for little reason. And ones that
originate on Linux travel poorly.

Don't forget that build systems are usually intended for developers,
where incremental compilation, or organising files into dozens of nested
files might be important for them.

But all that is utterly irrelevant for anyone just wanting to build a
finished, working program from source.

That is why when I used to provide distributions as source code, there
where just two things needed:

(1) The source code
(2) A compiler

I provided (1) as a single file. If I provided (2), that would be a
single file too. Otherwise, it would be a single command, like 'gcc
source.c'.

On 8/8/23 7:05 AM, Bart wrote:
> On 08/08/2023 03:21, Richard Damon wrote:
> > On 8/7/23 8:28 PM, Bart wrote:
> >> My view is that C's print-format system is not fit for purpose. The
> >> formatting is OK, it is needing to specify types that is the problem.
> >
> > which is EXACTLY the arguement that got us the C++ stream << operator.
> That feature is so bad it makes using printf preferable! Is it really
> that hard to just be able to write 'print x' ?
>
> > If you want to do that in C, you can, just define a generic "print"
> > function that defines version for each fundamental type, and call that.
> >
> > You don't seem to understand that C is based on the assumption that the
> > programmer actually knows what he is doing, not hiding behind a mass of
> > abstractions.
>
> You don't get my point. The programmer might not know for sure the type
> of a complex expression, and certainly does not want to keep updating
> dozens of printf formats across the codebase as global declarations change.

Then they are using the wrong tool.

C is designed to be used when you know, at least in general, what you
are working with.

>
> Right now I don't know how to print a clock() result for example, and to
> keep inventing special formats like %zu is crass.
>
> *I* can just write:
>
>     println a, b, c

So, why don't you?

is the problem that you don't know how to translate that into C?

>
> So can a dozen other languages (even from the 1960s!). I can change the
> types of a, b, c, and it still works. I can print c, b, a and it still
> works.
>
> I can even just do 'print clock()'!
>
> In C YOU CAN'T DO THAT. You need to dig up the types of each expression
> and apply the right format. In this VERY simple case, it MIGHT be:

Because C is a lower lever, and targeted to be more efficiet, than those
other languages.

>
>     printf("%lld " PRId64 " %s", a, b, c);
>
> But now you have an extra maintenance headache.
>
> (In all cases, printing gets untidy when you need to do necessary
> formatting, but only C incorporates types into the formatting.)
>
>
> >> It gets tricky when using sprintf say from another language, which is
> >> then transpiled to actual C.
> >
> > And why doesn't that other language implement a better print
> > functionality itself?
>
> It does, but ultimately it needs to do I/O, and I've been using C's
> printf for that since the mid-90s, because it was simpler than using
> WinAPI. I've since forgotten how do it with WinAPI.

So, your problem is that you aren't willing to do the work yourself.

>
> For that purpose, I only need to use %c and %s. (For floats, I use
> sprintf with %e %f %g, do any formatting, then use printf with %s if I
> need output.)
>
> So most of the time it is not an issue (other than, if using C
> transpilation, there is still the problem of C's char* type not existing
> in my language, nor any other).

So again, the problem is you are using the wrong tool or your language
is incomplete.

>
> Sometimes however, during bootstrapping or developing a new compiler, it
> might not yet support the 1000 lines of code needed to implement my
> Print routines, or there are codegen bugs, or I'm trying to keep test
> code absolutely minimal, then I will use printf.

>
> Or I might use it from my dynamic scripting language. I just use %ll
> since everything is 64 bits. Or I can test that other matter:
>
>    printf("%A", pi)       # interpreted code
>
> shows:
>
>    0X1.921FB5P+1
>
> > You are using C as a "portable assembler", but you don't actually seem
> > to want to understand the assembly language and are complaining because
> > the machine doesn't implement the fancy instructions you want to use.
>
> Exactly. C *IS* used extensively as a portable assembler, as an
> intermediate or target language, and there you don't want its UBs,
> foibles and quirky type system to get in the way, because source
> language and final targets are better defined than in C.
>
> This is an important use-case which should not be forgotten.

But to use C as a portable assembler, you need to use it as an
assembler, and that means understanding the nature of the "assembly
language".

All your problems seem to resolve to not wanting to put in the work to
understand the langauge and follow the rules of the assembly language.

You don't get to complain that a given machine doesn't implement your
favorate instruction directly in the assembly language.

And "portable" in that name has its limits. Because machine language
itself isn't actually "portable", and C's goal was to focus on being
able to both write efficient code when you knew the ability of the
machine, and fairly portable code when you didn't worry about being
maximally efficient, means you need to understand the rules of the language.

You CAN'T just "use" types you don't understand.

Also, with things like the printf family, sometimes the "portable" way
is somewhat ugly, and involves casting the final type to something you
know holds the value. You COULD just cast all integral values to "long
long" and use long long formats and not worry about the types. (or even
intmax_t)

After all, "printf" isn't a fast function by itself.

IF you are concerned about efficient outputing of valuse, you build a
family of generic "print" functions that use the right version for the
type given, and let the complier figure it out. Just means you can't put
everything in one statement. (but this is intermediary code, so doesn't
really need to be totally readable).

On 8/8/23 6:34 AM, Bart wrote:
> On 08/08/2023 01:59, Keith Thompson wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 07/08/2023 22:52, Keith Thompson wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>> [...]
> >>>> 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!
> >>>
> >>> No, for two reasons (and I don't believe you got that specific output
> >>> from a non-buggy implementation).
> >>>
> >>> First, the "%A" format uses uppercae letters; I don't know how you got
> >>> that mix of lowercase x and p and uppercase hex digits.
> >> I said 'I've made 0x and p lower case for clarity'.
> >
> > Sorry, I missed that.
> >
> > Why didn't you just use "%a" rather "%A" and show us the actual output?
> > It would have been:
> >      0xc.90fdaa22168cp-2
> >      0x1.921fb5p+1
> > which seems clear enough.
>
> In the first, there isn't enough contrast between x and c, or c and p; I
> wanted the hex digits to be visually distinct from the X and P at either
> end.
>
> >
> >>> Second, because they represent different values, because you used
> >>> different numbers of digits.
> >>
> >> I'll try to recreate the program, but I can't remember how many digits
> >> of pi I used, or whether I got some wrong; the exact value didn't
> >> matter, I was showing how different the output can be.
> >>
> >> But with the program below I get the given outputs:
> >>
> >>     c:\c>type c.c
> >>     #include <stdio.h>
> >>     int main(void) {
> >>         printf("%A\n", 3.14159265358979);
> >>     }
> >>
> >>     c:\c>bcc c
> >>     Compiling c.c to c.exe
> >>     c:\c>c
> >>     0X1.921FB5P+1
> >>
> >>     c:\c>gcc --version c.c
> >>     gcc (tdm64-1) 10.3.0 ...
> >>
> >>     c:\c>gcc c.c
> >>     c:\c>a
> >>     0XC.90FDAA2216888P-2
> >
> > On my Windows system using Cygwin gcc (with the printf implementation
> > provided by newlib) I get:
> >      0X1.921FB54442D11P+1
> > With TDM-GCC, I get the same output you get:
> >      0XC.90FDAA2216888P-2
> > Both are valid, confirmed by running a program containing
> >      printf("%.64f\n%.64f\n", 0X1.921FB54442D11P+1,
> 0XC.90FDAA2216888P-2);
> > which prints:
> >      3.1415926535897900073734945181058719754219055175781250000000000000
> >      3.1415926535897900073734945181058719754219055175781250000000000000
> > (I'm not discussing whether choosing a different leading hex digit is
> > good or bad.  It's permitted by the standard.)
> >
> > (I haven't figured out where TDM-GCC gets its printf implementation.
> > The executable depends on msvcrt.dll, but I don't think that tells us
> > anything -- and I doubt that msvcrt.dll supports "%a" and "%A".)
> >
> > The output with bcc appears to be incorrect, since it doesn't show the
> > full precision required by the C standard.  It is not "an exact
> > representation of the value".  1.921FB5 in hexadecimal is 25 bits; type
> > double should be able to represent about 53 bits of precision.
> >
> > bcc is your implementation, right?
>
> It's my compiler, but it uses msvcrt.dll to do the print. tcc uses the
> same library with the same output. Both seem to use a default of 6
> places after the ".", whether hex or decimal.
>
> If I write it in x64 assembly, using my assembler since I know for sure
> it links to msvcrt.dll and nothing else (it does not use a linker, it
> directly creates the EXE):
>
>     main::                      # :: makes it global
>         mov rcx, format
>         mov rdx, [pi]
>         movq xmm1, [pi]
>         call printf*            # * means imported name
>         mov rcx,0
>         call exit*
>
>         isegment
>     format:
>         db "%A",10,0
>
>     pi:
>         dq 3.141592653979
>
> I get the same output:
>
>     c:\ax>aa test
>     Assembling test.asm to test.exe
>
>     c:\ax>test
>     0X1.921FB5P+1
>
> Inside the EXE:
>
> Import Directory
>
> Entry:  4000
>     Lookup RVA:       4028
>     Time Date Stamp:  0
>     Fwd Chain:        0
>     Name RVA:         4074
>     Name:             msvcrt.dll
>     Import Addr RVA:  4040
>         Import:  4058    0 printf
>         Import:  4062    0 exit
>
>
> If I look inside gcc's EXE file, it imports 59 functions from
> kernel32.dll, and 45 from msvcrt.dll, including printf, but this gcc
> 10.3.0's use of 'printf' has always varied considerably from the one
> inside msvcrt.dll. For one, it is much slower.
>
> If I look inside this gcc's stdio.h, it defines printf like this:
>
> __mingw_ovr
> __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
> int printf (const char *__format, ...)
> {
>   int __retval;
>   __builtin_va_list __local_argv; __builtin_va_start( __local_argv,
> __format );
>   __retval = __mingw_vfprintf( stdout, __format, __local_argv );
>   __builtin_va_end( __local_argv );
>   return __retval;
> }

Which is clear if you understand the language that printf is calling
__mingw_vfprintf to do the work.

Yes, some of it is needing to understand gcc's extensions (for things
like __attribute__, which is just adding information so the compiler can
know that the function takes a "printf format string" for issuing
diagnostics, and understanding the basics of va_list operation (and that
being an implementation header, they need to use internal versions of
things defined in the <stdarg.h> header)

>
> So it's anyone's guess what it actually uses. My stdio.h has this:
>
>   int printf(const char*, ...);
>
> (Yeah, I naughtily leave out 'extern'.)
>
>

You do understand that extern is only needed for data types, not
functions. It does make the prototypes clearly prototypes.

If "your" <stdio.h> includes that line, that means that YOU are the
implementation writer and needed to have written the function yourself
to meet the specifications.

You need to decide if you are an "implementer", and then need to follow
the rules of an implementer, and meet those requirements, or a "user"
and keep your hands off the implementation.

You can't complain about the implementation, if the implementer is you.
(or you have done something only the implementer is allowed to do,
giving you the role of a co-implementer)

On 8/8/23 6:32 AM, David Brown wrote:
> On 04/08/2023 19:32, Malcolm McLean wrote:
>> On Friday, 4 August 2023 at 18:07:18 UTC+1, Bart wrote:
>>>
>>> Basically, everybody is at it, because nobody is in love with what C
>>> provides: the choice is between 'unsigned char', and '#include
>>> <stdint.h> uint8_t', and both stink.
>>>
>> There should be a keyword "byte".
>
> I'd have preferred that too.  I think there should have been a "byte"
> type that had the magic aliasing property, and that char types should
> follow the same aliasing rules as other types.  "Byte" should not have
> any arithmetic operation.  But history is against us.
>
>> unsigned chars should not be character
>> data, so "char" is a misnomer.
>
> I don't find "signed" or "unsigned" to make sense with characters.
> Ideally, IMHO, there would be "byte" (for raw memory access), "char" for
> characters, and "uint8_t" and "int8_t" for small numbers (these would be
> the only ones supporting arithmetic).
>
>> And uint8_t means that the data has to be
>> exactly 8 bits.
>
> Yes, which is usually what people want (except for extreme portable
> coding).
>
>> Which is only the case if the program is using overflow as
>> a free modulus 256 operation.
>
> Nonsense.  These types are rarely used for arithmetic (except on 8-bit
> devices), and overflow does not matter.
>
>> Which almost always is poor programming.
>> So it's hard to see where it has any place at all.
>>
>
> It is useful when you want a small unsigned integer.  For most people,
> that only matters when you want to store a large number of them.

Yes, if we had a time machine and could go back and fix things, I would
think having:

char be just characters
byte be just raw byte,
tiny be the type for very small intergers

making "char" do all these jobs has lead to a number of issues.
In the above, only byte would have the allow to alias anything property
(which would make char* more efficient).

On 08/08/2023 13:22, Malcolm McLean wrote:
> On Tuesday, 8 August 2023 at 12:11:47 UTC+1, David Brown wrote:
>>
>> And pretty much every serious programmer uses build tools, regardless of
>> the language - whether it be make, ant, bake, their own batch files,
>> IDEs, or whatever suits them. I no of no one else who goes so far out
>> of their way to make life difficult for themselves just so that they can
>> complain about how hard it all is.
>>
> Yes. But they make me nervous. We've got a system which involves Conan,
> CMake, the Xcode and Visual Studio IDEs, and Azure. Plus git for versioning.
>
> However if any one of these elements goes wrong, the process falls over.
> And it's hard to fix because, for example, I rarely write CMake scripts. Not
> often enough to be really familar with the system. And our CMake build scripts
> are effectively a program in their own right.
>
> I used CMake for the Baby X resource compiler. It worked on Windows and Mac.
> But it broke on Linux when Ben tested it. Because it wasn't actually passing the "-lm"
> option to link the math library. That the sort of problem you don't need.
>

You do need to know how to use your tools. And yes, sometimes build
scripts are complicated - but that is for complicated builds, and it
will always be vastly easier with a build script (CMake, make, bash
file, whatever) than a huge set of manual compiler commands.

Bart <bc@freeuk.com> writes:

> All I'm hearing is excuses.

I don't think you're hearing anything. Probably the most
prominent mode seen in your postings is not listening to
what the other person is saying, and then changing the
subject.

On Tuesday, 8 August 2023 at 13:45:53 UTC+1, David Brown wrote:
> On 08/08/2023 13:22, Malcolm McLean wrote:
> > On Tuesday, 8 August 2023 at 12:11:47 UTC+1, David Brown wrote:
> >>
> >> And pretty much every serious programmer uses build tools, regardless of
> >> the language - whether it be make, ant, bake, their own batch files,
> >> IDEs, or whatever suits them. I no of no one else who goes so far out
> >> of their way to make life difficult for themselves just so that they can
> >> complain about how hard it all is.
> >>
> > Yes. But they make me nervous. We've got a system which involves Conan,
> > CMake, the Xcode and Visual Studio IDEs, and Azure. Plus git for versioning.
> >
> > However if any one of these elements goes wrong, the process falls over.
> > And it's hard to fix because, for example, I rarely write CMake scripts. Not
> > often enough to be really familar with the system. And our CMake build scripts
> > are effectively a program in their own right.
> >
> > I used CMake for the Baby X resource compiler. It worked on Windows and Mac.
> > But it broke on Linux when Ben tested it. Because it wasn't actually passing the "-lm"
> > option to link the math library. That the sort of problem you don't need.
> >
> You do need to know how to use your tools. And yes, sometimes build
> scripts are complicated - but that is for complicated builds, and it
> will always be vastly easier with a build script (CMake, make, bash
> file, whatever) than a huge set of manual compiler commands.
>
I write C++ almost every working day. But writing the CMake scripts wasn't my
job. I only go into them when something goes wrong and they need to be
debugged. Which to be fair isn't that often, but it has happened. (Most of the
problems are because the CMake scripts are a git submodule, and submodules
are easy to get out of synchronisation with the main repository. So when the
CMake system breaks doing a git submodule update --init will fix it. But it's
hardly ideal.)

Then I recently wrote one for the Baby X resource compiler. The previous system was
to include a Microsoft Visual Studio project file with the distribution. Of course that
wasn't idea. But whilst dropping the source into Visual Studio isn't exactly difficult,
users are very lazy and want something they can build with a few mouse clicks.
I couldn't write CMake script off the top of my head. I had to go to examples and
the documentation. And I got it wrong for Linux.
It will likely be a while before I start another project on the same scale, by which time
I'll have forgotten what I did.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bart <bc@freeuk.com> writes:
>
>> The problem with the hex-binary form of C is that the representation
>> of the significant figures varies according to exponent.
>
> No necessarily. An implementation can choose to be consistent. In
> fact, it would take some effort not to be consistent in this regard.
> Different implementation may choose different representations of the
> same number, but for a single implementation I would expect the
> digits to be the same regardless of the exponent.

I understand what you're saying here, and agree with it.

However, there is a subtle point that deserves mentioning. If a
'double' value is printed using %a, and the same value is
converted to a 'long double' and printed using %La, in most cases
the digits (and exponents) of the outputs will be different.
This behavior can be confusing when it is first encountered (at
least, it was confusing for me, until I thought about what's
going on).

Bart <bc@freeuk.com> writes:
>On 08/08/2023 03:21, Richard Damon wrote:
> > On 8/7/23 8:28 PM, Bart wrote:
> >> My view is that C's print-format system is not fit for purpose. The
> >> formatting is OK, it is needing to specify types that is the problem.
> >
> > which is EXACTLY the arguement that got us the C++ stream << operator.
>That feature is so bad it makes using printf preferable! Is it really
>that hard to just be able to write 'print x' ?
>
> > If you want to do that in C, you can, just define a generic "print"
> > function that defines version for each fundamental type, and call that.
> >
> > You don't seem to understand that C is based on the assumption that the
> > programmer actually knows what he is doing, not hiding behind a mass of
> > abstractions.
>
>You don't get my point.

You haven't made a point.

>The programmer might not know for sure the type
>of a complex expression, and certainly does not want to keep updating
>dozens of printf formats across the codebase as global declarations change.

Funny how tens of thousands of C programmers have been able to write
useful code over the past half century.

David Brown <david.brown@hesbynett.no> writes:
>On 04/08/2023 20:25, Bart wrote:
>> On 04/08/2023 18:00, Vir Campestris wrote:

>> I used to distribute my programs as generated C, always comprising a
>> single source file, and requiring only a bare C compiler to build. So it
>> would have been nice if the instructions to build and run were something
>> like:
>>
>>     gcc prog.c
>>     prog
>>
>
>I don't disagree that this would have been nice for you, and for a
>number of other people. It would be useless for most people, especially
>historically in C (remember, gcc originates in a world where people can
>happily write "make prog" to get the same effect - saving a keystroke!).
> And for some people using gcc to replace even older compilers,
>changing the default from "a.out" would have been inconvenient.

Bart would likely be happy with the HP-3000 MPE concept of 'pass' files.

The compiler output by default would be written to a pass file called
"$NEWPASS". The linker would read, by default, a file called $OLDPASS
(which was the most recently written $NEWPASS) and would create its
output (the resulting executable) as "$NEWPASS" if not otherwise instructed.

However, in C and Unix, a.out is the term of art.

>
>
>> Besides, with pretty much every other language with a command-line build
>> process, if you submit a single source file 'fred.lang', it will produce
>> a matching executable 'fred.exe` without needing to be told how.

I don't believe this statement is accurate, historically. Consider,
for example, the JCL mess required to compile a fortran application.

Bart <bc@freeuk.com> writes:
>On 08/08/2023 12:11, David Brown wrote:

>It is one stupid decision in one compiler that nobody has bothered to
>fix. At least give it an option to override, but in a form where you
>don't need to provide a file name. Example:
>
> gcc -new prog.c

This would violate the POSIX option guidelines.

gcc -o new prog.c

is far superior in every way.

On 08/08/2023 13:22, Richard Damon wrote:
> On 8/8/23 7:05 AM, Bart wrote:
>> On 08/08/2023 03:21, Richard Damon wrote:
>> > On 8/7/23 8:28 PM, Bart wrote:
>> >> My view is that C's print-format system is not fit for purpose. The
>> >> formatting is OK, it is needing to specify types that is the
problem.
>> >
>> > which is EXACTLY the arguement that got us the C++ stream <<
operator.
>> That feature is so bad it makes using printf preferable! Is it really
>> that hard to just be able to write 'print x' ?
>>
>> > If you want to do that in C, you can, just define a generic "print"
>> > function that defines version for each fundamental type, and call
>> that.
>> >
>> > You don't seem to understand that C is based on the assumption that
>> the
>> > programmer actually knows what he is doing, not hiding behind a
>> mass of
>> > abstractions.
>>
>> You don't get my point. The programmer might not know for sure the
>> type of a complex expression, and certainly does not want to keep
>> updating dozens of printf formats across the codebase as global
>> declarations change.
>
> Then they are using the wrong tool.

What tool did you have in mind? Do you mean that an IDE will tell you
the types of the expressions, or write the format codes for you?

That strikes me as the same argument that you can use CDECL to get round
abstruse C type specs. If the tool can do it, why doesn't the compiler?
Or the language.

> C is designed to be used when you know, at least in general, what you
> are working with.
>
>>
>> Right now I don't know how to print a clock() result for example, and
>> to keep inventing special formats like %zu is crass.
>>
>> *I* can just write:
>>
>> println a, b, c
>
> So, why don't you?

I do. It's lovely. The question is, why are a million users of C denied
that?

> is the problem that you don't know how to translate that into C?
>
>>
>> So can a dozen other languages (even from the 1960s!). I can change
>> the types of a, b, c, and it still works. I can print c, b, a and it
>> still works.
>>
>> I can even just do 'print clock()'!
>>
>> In C YOU CAN'T DO THAT. You need to dig up the types of each
>> expression and apply the right format. In this VERY simple case, it
>> MIGHT be:
>
> Because C is a lower level, and targeted to be more efficiet, than those
> other languages.

Sorry, but that is rubbish. My 'M' language is also low level, but
somehow manages to have a proper print. And it's not dead slow either:

A loop which prints the numbers up to 10 million (redirected to a file
to remove display overheads), takes 1.8 seconds in my language, and 3.2
seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.

(My library is faster, despite the int->text code being unoptimised,
because of buffering. But then maybe gcc's printf is also buffered
internally. Which one is cheating more? I know mine won in this case!)

>>
>> printf("%lld " PRId64 " %s", a, b, c);
>>
>> But now you have an extra maintenance headache.
>>
>> (In all cases, printing gets untidy when you need to do necessary
>> formatting, but only C incorporates types into the formatting.)
>>
>>
>> >> It gets tricky when using sprintf say from another language,
which is
>> >> then transpiled to actual C.
>> >
>> > And why doesn't that other language implement a better print
>> > functionality itself?
>>
>> It does, but ultimately it needs to do I/O, and I've been using C's
>> printf for that since the mid-90s, because it was simpler than using
>> WinAPI. I've since forgotten how do it with WinAPI.
>
> So, your problem is that you aren't willing to do the work yourself.

What problem is this? I've been implementing 'proper' PRINT in languages
since as far back as 1981.

At some point, nearly 20 years later, I switched from OS to C functions
for low-level I/O, for consoles or files. For Printing to printers,
images, windows and strings, I still handled that.

> So again, the problem is you are using the wrong tool or your language
> is incomplete.

The problem is that you don't have a clue what the problem is.

There is no tool, and no feature in my language (other than turning it
into C), that will fix the problem that C's 'char*' is so unique.

Usually you can ignore that if using C's library purely via a binary
interface, but if generating C code, you will see issues. The solutions
are ugly and ungainly.

Try it and see!

> But to use C as a portable assembler, you need to use it as an
> assembler, and that means understanding the nature of the "assembly
> language".

An assembly language which has a million more rules, special cases and
UBs than any real assembler!

In x64 assembly, I can write a floating point value to a 64-bit memory
location, and read it back as an integer, with no issues:

movq [fred], xmm0
mov rax, [fred]

C makes that undefined - maybe.

> IF you are concerned about efficient outputing of valuse, you build a
> family of generic "print" functions that use the right version for the
> type given, and let the complier figure it out. Just means you can't put
> everything in one statement. (but this is intermediary code, so doesn't
> really need to be totally readable).

This is exactly what I do behind the scenes of my language. And another
reason why I sometimes use 'printf', since it produces long sequences of
function calls which obscure minimal test code.

The advantage of printf also is that it is outside my language, so its
implementation code doesn't intrude.