John Bode <jfbode1029@gmail.com> writes:
>On 7/30/21 9:19 AM, Ben Bacarisse wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>>
>>> On 7/27/21 10:47 AM, Kaz Kylheku wrote:
>>>> On 2021-07-26, John Bode <jfbode1029@gmail.com> wrote:
>>>>> If you're going to hide a struct or union type behind a typedef name,
>>>>> don't make me hunt down the typedef to know how to access the members -
>>>>> provide an API to do that for me.
>>>>
>>>> I don't find that reasonable; it's pretty common to make typedef names
>>>> for structures just to have a shorthand for declaring them, without
>>>> intending to create a fully opaque type with abstracted operations.
>>>
>>> Being common doesn't make it right.
>>>
>>>> typedef struct version {
>>>> int major;
>>>> int minor;
>>>> } version_t;
>>>> The typedef is co-located with the struct declaration; your ediutor
>>>> should be able to jump to the definition of version_t which is
>>>> the above line.
>>>
>>> I work on remote Linux instances through terminal sessions - my
>>> choices of editor are either vi or emacs, neither of which have
>>> that kind of intelligence.
>>
>> I use etags+emacs. Works fine. There might even be a more modern and
>> automatic way to do this, but I tend to stick with what I've used
>> before.
>>
>
>Ah. I'm a vi dinosaur. I've tried to learn emacs, but I just don't
>have the ability to keep all the key combinations straight. If there's
>a way to do it in vi - well, I probably won't use it enough for it
>to stick in working memory and will eventually forget about it
>completely. I've used or created so many nifty macros over the years
>that got used once or twice, then were abandoned.

Vi has supported ctags for decades. vim supports cscope integration.

On Friday, July 30, 2021 at 11:13:55 AM UTC-4, Bart wrote:
> On 30/07/2021 15:55, Kaz Kylheku wrote:
> > On 2021-07-29, Bart <b...@freeuk.com> wrote:
> >> It's Windows 7. gcc is version 9.2.0.
> >
> >> This program:
> >>
> >> #include <stdio.h>
> >> int main(void) {printf("%zu\n",sizeof(void*));}
> >>
> >> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
> >
> > The above has no meaning. "gcc" is not the name of any software that
> > provides a printf function.
> >
> OK. But gcc and tcc are products that you expect to make the necessary
> arrangements for ensuring they your program can call a C standard
> function called "printf".

No, I don't, because I read the documentation. I expect gcc to use
whichever library it's connected to, whether or not that library constitutes
a conforming implementation of the C standard library. In order to get a
fully conforming implementation of C, you need to connect it to a library
that is a fully conforming and gcc-compatible implementation of the C
standard library. Such a library is provided by the Ubuntu distribution of
Linux that I'm using on my desktop, and automatically connected to my
copy of gcc, but that is apparently not the case of the Windows system
you're using. Since Keith has no problem with this on his Windows 10
machine, it's not merely Windows 10 that's the issue - it's how your
particular copy of Windows was installed that's the problem.

> Which they do, because it generally works. But whatever it is they end
> up linking into your program, doesn't support "zu".
>
> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
> Which library do gcc and tcc use?

That depends upon how they're installed. As you have repeatedly
demonstrated in the past, you have no clear understanding of how
you've installed such things.
> But this is all getting away from the point you're trying to make, which
> is that gcc has no hand at all it in providing a 'printf' function for
> my C programs.
>
> You're wrong.

It makes no promise to provide any such function.

If you buy hot dog buns from a bakery, do you complain about the fact
that they don't have any hot dogs in them? If someone sells hot dog
buns without hot dogs, and someone else sells hot dogs without buns,
it's your responsibility, if you want to take advantage of those choices,
to put them together yourself. If you don't want that responsibility, get
your hot dog with a bun from someone who actually sells such things.
Many sources provide fully conforming C compilers bundled together
with compatible fully conforming standard libraries. You just aren't
using one of them.

> int main(void) {
> printf((long long)"Hello, World!\n");
> }
>
> gcc complains that my printf conflicts with the built-in printf; so it
> knows perfectly well what it is. It will even tell me if I get the
> format codes wrong!

It's not the "built-in" printf(), it's the printf() that's provided by
whichever library gcc is currently configured to use - which is not
provided by gcc, and which gcc makes no promises about.
Yes, it does provide compile-time checking of printf/scanf family
format specifiers. That checking occurs before linking, and is based
upon the assumption that the library your connecting to is a fully
conforming implementation of the C standard library. As a result,
the format specifier checking can actually produce incorrect results,
if the printf() function provided by that library accepts different
format specifiers than what's required of the C standard library
printf() function.

On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
> On Friday, July 30, 2021 at 11:13:55 AM UTC-4, Bart wrote:
>> On 30/07/2021 15:55, Kaz Kylheku wrote:
>>> On 2021-07-29, Bart <b...@freeuk.com> wrote:
>>>> It's Windows 7. gcc is version 9.2.0.
>>>
>>>> This program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>
>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>
>>> The above has no meaning. "gcc" is not the name of any software that
>>> provides a printf function.
>>>
>> OK. But gcc and tcc are products that you expect to make the necessary
>> arrangements for ensuring they your program can call a C standard
>> function called "printf".
>
> No, I don't, because I read the documentation.

Are you serious? Just gcc.info is 1000 pages of options.

Someone who has been using:

tcc prog.c

effectively, and now wants to try gcc, expects to type the equivalent:

gcc prog.c

except for options like -O3 to get faster code.

> I expect gcc to use
> whichever library it's connected to, whether or not that library constitutes
> a conforming implementation of the C standard library. In order to get a
> fully conforming implementation of C, you need to connect it to a library
> that is a fully conforming and gcc-compatible implementation of the C
> standard library. Such a library is provided by the Ubuntu distribution of
> Linux that I'm using on my desktop, and automatically connected to my
> copy of gcc, but that is apparently not the case of the Windows system
> you're using. Since Keith has no problem with this on his Windows 10
> machine, it's not merely Windows 10 that's the issue - it's how your
> particular copy of Windows was installed that's the problem.

I don't even know what gcc bundle Keith might have. Also he doesn't have
tcc so he cannot say what that does or doesn't do.

However, if I delve into my gcc installation, there are 1277 lib*.a
files, of which 14 have "crt" in their names (shared between 32- and
64-bit versions).

If I try the -lucrt or -lucrtbase option with gcc, then "zu" works. With
-lmsvcrt then "zu" doesn't work.

So now I know how to get gcc on Windows to use "zu". Except that may not
be helpful, if it depends on the installer of gcc including the mingw64
runtime libraries, if these lib*.a files are dependent on that being an
installed component.

Plus it probably still won't work on tcc, as it can't find -lucrt, and
it can't directly link libucrt.a.

Plus it still won't work my bcc and I can't see a way of turning
libucrt.a into a DLL that can export its C functions.

So, in all, it's much safer not use "zu". Remember that all we're doing
is printing a number, which is either u32 or u64.

>> Which they do, because it generally works. But whatever it is they end
>> up linking into your program, doesn't support "zu".
>>
>> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
>> Which library do gcc and tcc use?
>
> That depends upon how they're installed. As you have repeatedly
> demonstrated in the past, you have no clear understanding of how
> you've installed such things.

Utter nonsense. I just use the supplied installers. On the gcc/tdm
install program, you select the components needed, and most start off
already ticked.

On simpler compilers, there may be no options at all. (Mine is just a
bare .exe file, ready-to-go.)

>> But this is all getting away from the point you're trying to make, which
>> is that gcc has no hand at all it in providing a 'printf' function for
>> my C programs.
>>
>> You're wrong.
>
> It makes no promise to provide any such function.

My compiler will produce an executable where printf is an imported
function. To succeed, it will need, at compile-time, the name of a DLL
where the symbol can be located (but msvcrt.dll is searched automatically).

Even with the EXE generated, because of dynamic linking, it will further
need the DLL available at runtime.

In practice, printf will always be available because msvcrt.dll is a
part of Windows, which cannot easily be deleted.

>
> If you buy hot dog buns from a bakery, do you complain about the fact
> that they don't have any hot dogs in them? If someone sells hot dog
> buns without hot dogs, and someone else sells hot dogs without buns,
> it's your responsibility, if you want to take advantage of those choices,
> to put them together yourself. If you don't want that responsibility, get
> your hot dog with a bun from someone who actually sells such things.
> Many sources provide fully conforming C compilers bundled together
> with compatible fully conforming standard libraries. You just aren't
> using one of them.

I've been writing compilers for 40 years. Especially within the last 10,
where I have also strived to make them smaller, simpler, faster, more
self-contained and more effortless to install and use than the
mainstream ones.

So you can't really get on your pulpit and tell people they don't
understand their Compiler (namely 'gcc'), as there is more than one, and
anything amiss is therefore their fault as they haven't read through
10,000 pages of docs.

They can all be different. gcc apparently comes with this practice of
separating out all the various components, which you and Keith and now
KK like to beat people over the head with whenever sometimes makes some
assumption about what a compiler is. YOU can't make assumptions either.

Some are a lot more friendly than your gcc and more informal.

Bart <bc@freeuk.com> writes:
>On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:

>> No, I don't, because I read the documentation.
>
>Are you serious? Just gcc.info is 1000 pages of options.

RTFM. And, much as I dislike the GNU info utility UI, the
data is well organized and fairly complete.

>I don't even know what gcc bundle Keith might have. Also he doesn't have
>tcc so he cannot say what that does or doesn't do.

I believe he mentioned using cygwin gcc, which comes with glibc.

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 03:20, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> Sure, I can do that (after fixing the code with the right includes and
>>>>> avoiding %zu). But that's the trial and error approach.
>>>> %zu is the correct format specifier. I'm not even going to ask why
>>>> you'd want to avoid it.
>>>
>>> I'll tell you anyway: it doesn't work on Windows.
>>
>> Yes, it does. I don't know why it wouldn't work for you. Are you using
>> some obsolete version of Windows or of its C implementation?
>
> There is no "its C implementation" in regard to Windows. C programs for
> Windows carry their own C run-times.
>
> (Some misguided developers think that an undocumented component called
> MSVCRT.DLL in the system folder provides parts of the Library clause of
> a C implementation for use by Windows applications; they are simply wrong.)

Apparently MSVCRT.DLL is an old C runtime library that's still shipped
with Windows for backward compatibility. It (probably) was the
recommended C library implementation for use by Windows applications as
of about 20 years ago.

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 30/07/2021 17:31, Bart wrote:
> On 30/07/2021 16:06, Kaz Kylheku wrote:
>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>> Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
>>
>> Windows 10 does not come with a C library.
>>
>> Windows 10 comes with an undocumented internal component called
>> MSVCRT.DLL (or something similar) which is in the system folder.
>>
>> This is used by some utilities that come with Windows.
>>
>> If you create executable programs which link or load this and call into
>> it, you're misusing Windows in an undocumented way, like sticking a fork
>> in a toaster whose user manual describes only bread being stuck into
>> the toaster.
>
> Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny
> C. So would any application built with those compilers.
>
> Including tcc.exe itself.
>
> And gcc.exe itself.
>

That matches precisely with what Kaz wrote. Using MSVCRT.DLL as your
"system C library" is a lazy, undocumented way to make your C programs
work, and being able to boast (pointlessly) about generating small
executables. The DLL is slow, outdated, and not intended for such uses
- it is designed for runtime versions of functions used in combination
with MS's own development tools, not anyone else's tools. It has
outdated versions of some functions (it never claimed to support C99,
but is primarily for C++). It is not licensed for distribution or use
except with executables generated by MSVC - and it is not and has never
been a standard part of Windows. You can usually expect a copy of some
version of the DLL to be on most Windows systems, since it is commonly
distributed with many programs for Windows, though you can only guess at
which version of the DLL you might have.

Anyone can take the source code for gcc and build a package containing a
gcc.exe compiler, with a setup to link to MSVCRT.DLL or a decent C
library. That does not make it in any way a compiler from the GNU gcc
developers - it's just some person or group using the freedom of the
GPL'ed code to make a package that they think some people will find
useful. If you find it useful, great. But please don't call it "gcc on
Windows" as though it had even the remotest legitimacy as an "official"
gcc port for Windows.

> (I don't have time to look at various other applications.)
>
> So my attitude is, so what?
>

If that's your attitude, that's fine - it's up to you.

Many other C programmers - most, perhaps - have joined this century and
are using C99 at least. If you are happy with a setup, toolchain and OS
for which you can't use C99, that's fine. Don't expect anyone else to
have much consideration for your limited arrangements, however.

Bart <bc@freeuk.com> writes:
[...]
> But this is all getting away from the point you're trying to make,
> which is that gcc has no hand at all it in providing a 'printf'
> function for my C programs.
>
> You're wrong.

No, he's right.

> Further, if I try and compile this program:
>
> extern int printf(long long,...);
>
> int main(void) {
> printf((long long)"Hello, World!\n");
> }
>
> gcc complains that my printf conflicts with the built-in printf; so it
> knows perfectly well what it is. It will even tell me if I get the
> format codes wrong!

gcc's warning message for that is:

warning: conflicting types for built-in function ‘printf’; expected
‘int(const char *, ...)’ [-Wbuiltin-declaration-mismatch]

The use of the term "built-in" is slightly misleading. The printf
function is not built into the compiler. (Conceivably a compiler could
provide a built-in printf implementation, but as far as I know none do).

gcc is able to warn about the declaration because it knows about the
standard's requirements for printf, so it knows that a declaration with
a long long first parameter will conflicts with the runtime library's
implementation *in any correct implementation*.

printf is built into the implementation, not into the compiler.

gcc can compile printf("hello\n") to the equivalent of puts("hello")
because it knows how the standard requires printf and puts to behave.

(Of course gcc itself doesn't "know" anything. Its authors know these
things, and incorporate that knowledge into gcc's behavior.)

If you have somehow concluded that gcc, the compiler, provides code that
implements the printf function, you have reached an incorrect
conclusion -- and maintained that conclusion in the presence of repeated
attempts to explain it to you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
[...]
> OK. But gcc and tcc are products that you expect to make the necessary
> arrangements for ensuring they your program can call a C standard
> function called "printf".

No, they are not. They are components that can be combined with other
components to create a C implementation. Getting that right is the
responsibility of whoever puts together the implementation.

You've written compilers, so you should know all this stuff.

If someone puts together an implementation that uses gcc as its compiler
and the obsolete MSVCRT.DLL as its runtime library, the result is a
non-conforming implementation.

My experience with Windows C implementations is fairly narrow, but I get
the impression that most Windows C programmers don't need to worry about
"%zu" because they use implementations that support it. If it's a
widespread problem (which is possible), I haven't heard about it other
than from you.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Manfred <noname@add.invalid> writes:
[...]
> Yes, if you use gcc under Windows you are actually importing a chain
> of dependencies that you don't want to bother with - That's the reason
> I only use gcc on Linux.
[...]

Cygwin is one way to use gcc under Windows, but it's not the only one.
There are other implementations on Windows that include gcc but are not
connected to Cygwin. See for example mingw-w64 (which seems to have
some relationship to Cygwin, but I'm not clear on the details).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
>
>>> No, I don't, because I read the documentation.
>>
>>Are you serious? Just gcc.info is 1000 pages of options.
>
> RTFM. And, much as I dislike the GNU info utility UI, the
> data is well organized and fairly complete.
>
>
>>I don't even know what gcc bundle Keith might have. Also he doesn't have
>>tcc so he cannot say what that does or doesn't do.
>
> I believe he mentioned using cygwin gcc, which comes with glibc.

Cygwin gcc uses newlib, not glibc.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 7/29/2021 12:05 PM, Bart wrote:
> On 29/07/2021 03:20, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 00:07, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>
>>>>> I want to call a C function via an FFI from a language that I've
>>>>> devised. The public API says one parameter type is off_t.
>>>>>
>>>>> Which type matches that in my language? I have to choose from i8-i64
>>>>> and u8-u64.
>>>>>
>>>>> The kind of answer I want is (a) 'It uses i64' etc; or (b) 'It uses
>>>>> i32 or u64 depending on platform'.
>>>> POSIX says that off_t is a signed integer type.
>>>> Is there some reason that compiling and running this program on the
>>>> target system doesn't solve your problem?
>>>> #include <stdio.h>
>>>> #include <limits.h>
>>>> int main(void) {
>>>>       printf("off_t is %c%zu\n",
>>>>              (off_t)-1 < (off_t)0 ? 'i' : 'u',
>>>>              CHAR_BIT * sizeof (off_t));
>>>> }
>>>
>>> Sure, I can do that (after fixing the code with the right includes and
>>> avoiding %zu). But that's the trial and error approach.
>>
>> %zu is the correct format specifier.  I'm not even going to ask why
>> you'd want to avoid it.
>
> I'll tell you anyway: it doesn't work on Windows.
>
>> Yes, I probably should have used `#include <sys/types.h>`.
>>
>> No, it's not trial and error.  Write the program once, compile and run
>> it on each platform of interest.  Expand the program as needed to show
>> the characteristcs of all the types you're interested in.  Tweak the
>> output any way you like to suit your purposes.  Make it generate source
>> code in your personal language if you like.
>
> This is stuff I've had to do years ago. More recently, I could
> semi-translate C APIs (although normally I'd exclude system headers), by
> using a special option on my C compiler, which will generate a
> particular rendering, as often APIs bristle with compile-specific code.
>
> It doesn't attempt most of the macros that are normally used, which in
> general contain expressions in C syntax which is not trivially convertible.
>
> Generating FFI bindings of C APIs is a big job. Most people who have to
> do similar things are not going to be writing their own C parsers or
> whatever; they might have to use more heavyweight solutions, or simply
> do a huge amount of work.
>

C APIs (meaning APIs written in C) are excellent for cross-language
implementations, in fact the Windows API /is/ a C api because that's the
best choice to make it usable by the plethora of languages that
Microsoft markets.

If what you actually mean is having a different language interface with
the C standard library, then I see your point.
Comparing e.g. the C standard library and the Windows API, the former is
next to impossible to use from another language compared to the latter,
due to the difficulties you have explained.

The reason for that is, I think, about the demand for such interoperability.

Microsoft has always had a strong commercial drive to sell multiple
programming languages for their system, so they wrote their API in such
a way that it would be relatively easy to interface with from other
languages. As said, the Windows API /is/ written in C because this
language allows for the necessary specialization of an API, but it has
nothing to do with the C standard library - note that the Windows API is
Kernel32.dll and friends, /not/ msvcrt.dll.
An important aspect of this scenario is that Windows has mostly targeted
only Intel based PCs, that's it; and even nowadays I believe they only
support architectures that can provide a compatible subsystem with that
architecture.

The story about the C standard library is completely different, it is
not an OS api, but instead it can be seen as an abstraction /for the C
language/ of OS services that is required to support many different
architectures.

Back to your point, I think that a language that cares about efficiency
would probably access OS facilities directly, for example: on Windows,
kernel32.dll etc., not msvcrt.dll. On *nix I wouldn't know, but I wonder
if a Fortran implementation actually uses libc.so.

If a language would want to use the C standard library to access OS
services I think it should include a C proxy, a module /written in C/
that exposes the required facilities to the language environment: for
example, in your case about "struct stat" a module that provides the
required conversions between its types to the types of your language.

> The off_t and other types are examples of where how C is typically
> written makes it harder than necessary. Instead of using a plain type,
> or even using one layer of typedefs, it uses several.
>
> (For gcc/tdm, off_t is defined inside _mingw_off_t.h (it has its own
> header!). This defines also _off_t and off32_t as 'long'; _off64_t and
> off64_t; and off_t itself as either off64_t or off32_t
>
> One clock_t type used 6 layers of typedefs and macros; what the hell
> happended there? This is why I'm saying this stuff should be overhauled.
> Obviously no one wants to mess with it, so they add their own
> abstractions. Then someone else does the same... Eventually someone
> whats to printf such a value!)
>
> -----------------------------------------------
> _mingw_off_t.h
> -----------------------------------------------
> #ifndef _OFF_T_DEFINED
> #define _OFF_T_DEFINED
> #ifndef _OFF_T_
> #define _OFF_T_
>   typedef long _off_t;
> #if !defined(NO_OLDNAMES) || defined(_POSIX)
>   typedef long off32_t;
> #endif
> #endif
>
> #ifndef _OFF64_T_DEFINED
> #define _OFF64_T_DEFINED
>   __MINGW_EXTENSION typedef long long _off64_t;
> #if !defined(NO_OLDNAMES) || defined(_POSIX)
>   __MINGW_EXTENSION typedef long long off64_t;
> #endif
> #endif /*_OFF64_T_DEFINED */
>
> #ifndef _FILE_OFFSET_BITS_SET_OFFT
> #define _FILE_OFFSET_BITS_SET_OFFT
> #if !defined(NO_OLDNAMES) || defined(_POSIX)
> #if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
> typedef off64_t off_t;
> #else
> typedef off32_t off_t;
> #endif /* #if !defined(NO_OLDNAMES) || defined(_POSIX) */
> #endif /* (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64)) */
> #endif /* _FILE_OFFSET_BITS_SET_OFFT */
>
> #endif /* _OFF_T_DEFINED */
> -----------------------------------------------
>
> All to define a type which is i32 or i64; wonderful isn't it?
>
> Let's face it, if you had to write some functions or data types that
> expressed a file offset, you'd just use int64_t and be done with it.

On 7/30/2021 8:16 PM, Keith Thompson wrote:
> Manfred <noname@add.invalid> writes:
> [...]
>> Yes, if you use gcc under Windows you are actually importing a chain
>> of dependencies that you don't want to bother with - That's the reason
>> I only use gcc on Linux.
> [...]
>
> Cygwin is one way to use gcc under Windows, but it's not the only one.
> There are other implementations on Windows that include gcc but are not
> connected to Cygwin. See for example mingw-w64 (which seems to have
> some relationship to Cygwin, but I'm not clear on the details).
>

Still I believe that none of them is officially supported by the gcc team.

On 30/07/2021 18:49, David Brown wrote:
> On 30/07/2021 17:31, Bart wrote:
>> On 30/07/2021 16:06, Kaz Kylheku wrote:
>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>> Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
>>>
>>> Windows 10 does not come with a C library.
>>>
>>> Windows 10 comes with an undocumented internal component called
>>> MSVCRT.DLL (or something similar) which is in the system folder.
>>>
>>> This is used by some utilities that come with Windows.
>>>
>>> If you create executable programs which link or load this and call into
>>> it, you're misusing Windows in an undocumented way, like sticking a fork
>>> in a toaster whose user manual describes only bread being stuck into
>>> the toaster.
>>
>> Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny
>> C. So would any application built with those compilers.
>>
>> Including tcc.exe itself.
>>
>> And gcc.exe itself.
>>
>
> That matches precisely with what Kaz wrote. Using MSVCRT.DLL as your
> "system C library" is a lazy, undocumented way to make your C programs
> work, and being able to boast (pointlessly) about generating small
> executables.

Hmm, the hello.exe executable generated by gcc (after you specify
-ohello.exe!) is about 330KB.

And this still imports msvcrt.dll. So small executables aren't the
reason gcc does it. (tcc produces a 2KB executable.)

You also don't seem to understand the point of DLLs: they are SHARED
libraries. They are supposed to save space; it is not just disk space,
but process space. What's the point of 100 active programs all running
their own private copies of the C runtime?

Plus, system DLLs (as I consider msvcrt.dll) are usually not practical
to statically link, because only DLLS are available (eg. kernel32.dll).

How big would a program be if it incorporated half the Windows API as
statically linked code?

The GTK libraries on Windows numbered 28 different DLLs (I don't know
how many MB in total). So what is special about using another DLL called
msvcrt.dll?

You just want to pour more scorn on the efforts of amateur compiler writers.

> Anyone can take the source code for gcc

No. It is a product that consists of about 100,000 files, of which about
half are source files. It is HUGE. It would be a miracle just to get it
to build using the automatic means provided, let alone understand the
ins and outs of it enough to figure out how it deals with system libraries.

When gcc compiles hello.c, it eventually invokes a linker with FIFTY
different options.

That is a totally different world from what I do. My product doesn't
even HAVE a linker! (Because it doesn't need it; an obsolete concept in
my view.)

>> So my attitude is, so what?
>>
>
> If that's your attitude, that's fine - it's up to you.

Because even your beloved gcc does it. And every program that a mingw
gcc builds on Windows, will depend on it too, even when linked with
-lucrt. So why on earth should I worry about whether /I/ use it?

>
> Many other C programmers - most, perhaps - have joined this century and
> are using C99 at least. If you are happy with a setup, toolchain and OS
> for which you can't use C99, that's fine. Don't expect anyone else to
> have much consideration for your limited arrangements, however.

All this fuss about "%zu" which is incredibly naff anyway. If using my
bcc compiler, I can just write:

printf("%?", sizeof(T));

which would work with ANY C library.

If using my private language, it's even simpler:

print T.bytes

So, I should put myself out for a 'format specifier' of the kind that
should have been done away with last century. How about /you/ lot
joining the 21st century!

On 30/07/2021 19:12, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> OK. But gcc and tcc are products that you expect to make the necessary
>> arrangements for ensuring they your program can call a C standard
>> function called "printf".
>
> No, they are not. They are components that can be combined with other
> components to create a C implementation. Getting that right is the
> responsibility of whoever puts together the implementation.
>
> You've written compilers, so you should know all this stuff.
>
> If someone puts together an implementation that uses gcc as its compiler
> and the obsolete MSVCRT.DLL as its runtime library, the result is a
> non-conforming implementation.

Well, /I/ didn't tell gcc which runtime to choose. Or is that now my
responsibility?

I now know that mine will default to Windows' msvcrt.dll unless I
specifically tell it to use libucrt.a. Why the default isn't the other
way around is not something I'm surprised at any more; there are much
worse defaults, and more dangerous.

> My experience with Windows C implementations is fairly narrow, but I get
> the impression that most Windows C programmers don't need to worry about
> "%zu" because they use implementations that support it. If it's a
> widespread problem (which is possible), I haven't heard about it other
> than from you.

Download tcc, which is now a well-respected C99 implementation, and
blazingly fast, and let me know if it supports "zu" out-of-the-box, and
if not, whether there is a way to make it do so.

If you're on Windows, try this:

* Download the program:

https://github.com/sal55/langs/blob/master/qq.exe (about 640KB)

* Download program:

https://github.com/sal55/langs/blob/master/readexe.qa (about 40KB)

This can be used to look inside any EXE file, for example:

qq readexe.qa prog.exe

(Or use any utility that can dump the info.)

I'd be interested in whether any Windows executable produced by your gcc
also imports msvcrt.dll, which looks like this using my dump program:

Import Directory
.....
Entry: 5c1000
Lookup RVA: 5c1050
Time Date Stamp: 0
Fwd Chain: 0
Name RVA: 5c19cc
Name: msvcrt.dll
Import Addr RVA: 5c12d0
Import:5c1550 0 free
Import:5c1558 0 memcpy
.....

On 30/07/2021 19:17, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Bart <bc@freeuk.com> writes:
>>> On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
>>
>>>> No, I don't, because I read the documentation.
>>>
>>> Are you serious? Just gcc.info is 1000 pages of options.
>>
>> RTFM. And, much as I dislike the GNU info utility UI, the
>> data is well organized and fairly complete.
>>
>>
>>> I don't even know what gcc bundle Keith might have. Also he doesn't have
>>> tcc so he cannot say what that does or doesn't do.
>>
>> I believe he mentioned using cygwin gcc, which comes with glibc.
>
> Cygwin gcc uses newlib, not glibc.
>

If you're using gcc via Cygwin, then all bets are off.

It's not using gcc as a native Windows application, actually I don't
even know if you still end up with EXE files rather than ELF, and I
don't know what libraries will be used.

Cygwin is an attempt to bring elements of Linux to Windows (along with
MSYS2 and WSL). I would not count it as directly running a C compiler on
Windows, and you can't really compare behaviour.

Like saying that your gcc (ie. running under Cygwin) works; mine
doesn't, therefore I must be doing something wrong.

Bart <bc@freeuk.com> writes:
>On 30/07/2021 19:12, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> OK. But gcc and tcc are products that you expect to make the necessary
>>> arrangements for ensuring they your program can call a C standard
>>> function called "printf".
>>
>> No, they are not. They are components that can be combined with other
>> components to create a C implementation. Getting that right is the
>> responsibility of whoever puts together the implementation.
>>
>> You've written compilers, so you should know all this stuff.
>>
>> If someone puts together an implementation that uses gcc as its compiler
>> and the obsolete MSVCRT.DLL as its runtime library, the result is a
>> non-conforming implementation.
>
>Well, /I/ didn't tell gcc which runtime to choose. Or is that now my
>responsibility?

As David pointed out, your 'gcc' isn't 'the gcc'. It is some anonymous
person building the open source gcc compiler on windows.

Bart <bc@freeuk.com> writes:
>On 30/07/2021 19:17, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Bart <bc@freeuk.com> writes:

>If you're using gcc via Cygwin, then all bets are off.
>
>It's not using gcc as a native Windows application, actually I don't
>even know if you still end up with EXE files rather than ELF, and I
>don't know what libraries will be used.
>
>Cygwin is an attempt to bring elements of Linux to Windows (along with
>MSYS2 and WSL). I would not count it as directly running a C compiler on
>Windows, and you can't really compare behaviour.
>

So use WSL instead of cygwin. You can download it from the
windows store, in multiple flavors. Fully supported by
Microsoft.

On 30/07/2021 21:10, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 30/07/2021 19:17, Keith Thompson wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Bart <bc@freeuk.com> writes:
>
>> If you're using gcc via Cygwin, then all bets are off.
>>
>> It's not using gcc as a native Windows application, actually I don't
>> even know if you still end up with EXE files rather than ELF, and I
>> don't know what libraries will be used.
>>
>> Cygwin is an attempt to bring elements of Linux to Windows (along with
>> MSYS2 and WSL). I would not count it as directly running a C compiler on
>> Windows, and you can't really compare behaviour.
>>
>
> So use WSL instead of cygwin. You can download it from the
> windows store, in multiple flavors. Fully supported by
> Microsoft.

This is actually pretty crazy, suggesting buying a new PC with Windows
10, switching OS pretty much, to solve an utterly insignificant non-problem.

Keith posted some code with "zu", that I never use myself, and would
never use anyway, that I happened to mention didn't work on my plain
Windows.

Switching machines and OSes is a rather drastric and expensive workaround!

Thanks, but I've programmed outside of Unix systems quite happily for 45
years; it's mainly you guys that can't cope without all your little Unix
tool.

On 7/30/2021 11:22 AM, Manfred wrote:
> On 7/29/2021 12:05 PM, Bart wrote:
>> On 29/07/2021 03:20, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 29/07/2021 00:07, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
[...]
> Microsoft has always had a strong commercial drive to sell multiple
> programming languages for their system, so they wrote their API in such
> a way that it would be relatively easy to interface with from other
> languages. As said, the Windows API /is/ written in C because this
> language allows for the necessary specialization of an API, but it has
> nothing to do with the C standard library - note that the Windows API is
> Kernel32.dll and friends, /not/ msvcrt.dll.
> An important aspect of this scenario is that Windows has mostly targeted
> only Intel based PCs, that's it; and even nowadays I believe they only
> support architectures that can provide a compatible subsystem with that
[...]

Windows on a Dec Alpha was fun!

On 30/07/2021 21:08, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 30/07/2021 19:12, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> OK. But gcc and tcc are products that you expect to make the necessary
>>>> arrangements for ensuring they your program can call a C standard
>>>> function called "printf".
>>>
>>> No, they are not. They are components that can be combined with other
>>> components to create a C implementation. Getting that right is the
>>> responsibility of whoever puts together the implementation.
>>>
>>> You've written compilers, so you should know all this stuff.
>>>
>>> If someone puts together an implementation that uses gcc as its compiler
>>> and the obsolete MSVCRT.DLL as its runtime library, the result is a
>>> non-conforming implementation.
>>
>> Well, /I/ didn't tell gcc which runtime to choose. Or is that now my
>> responsibility?
>
> As David pointed out, your 'gcc' isn't 'the gcc'. It is some anonymous
> person building the open source gcc compiler on windows.

I have half a mind to change the name of my own product to 'gcc'.

Then when I talk about how it works, I'd be 100% correct. And when you
guys tell me what I say doesn't apply to 'the' gcc, whatever that is,
then you'd now be 100% right too!

For the record, my current 'gcc' that I use on plain Windows is this
product:

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

On 30/07/2021 21:03, Bart wrote:
> On 30/07/2021 18:49, David Brown wrote:
>> On 30/07/2021 17:31, Bart wrote:
>>> On 30/07/2021 16:06, Kaz Kylheku wrote:
>>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>>> Anyway, how can the C library be obsolete if it comes /with/
>>>>> Windows 10?
>>>>
>>>> Windows 10 does not come with a C library.
>>>>
>>>> Windows 10 comes with an undocumented internal component called
>>>> MSVCRT.DLL (or something similar) which is in the system folder.
>>>>
>>>> This is used by some utilities that come with Windows.
>>>>
>>>> If you create executable programs which link or load this and call into
>>>> it, you're misusing Windows in an undocumented way, like sticking a
>>>> fork
>>>> in a toaster whose user manual describes only bread being stuck into
>>>> the toaster.
>>>
>>> Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny
>>> C. So would any application built with those compilers.
>>>
>>> Including tcc.exe itself.
>>>
>>> And gcc.exe itself.
>>>
>>
>> That matches precisely with what Kaz wrote.  Using MSVCRT.DLL as your
>> "system C library" is a lazy, undocumented way to make your C programs
>> work, and being able to boast (pointlessly) about generating small
>> executables.
>
> Hmm, the hello.exe executable generated by gcc (after you specify
> -ohello.exe!) is about 330KB.
>
> And this still imports msvcrt.dll. So small executables aren't the
> reason gcc does it. (tcc produces a 2KB executable.)
>
> You also don't seem to understand the point of DLLs: they are SHARED
> libraries. They are supposed to save space; it is not just disk space,
> but process space. What's the point of 100 active programs all running
> their own private copies of the C runtime?
>

I /do/ understand the point of DLL's. The possibility of sharing space
is just one aspect - and it is totally underused on Windows, since
pretty much every program installs its own copies of the DLL's it needs
(with the exception of the /real/ system DLL's) due to a lack of any
centralised repository and a total chaos of DLL versioning on Windows.
(On Linux, and other *nix, DLL equivalents work well as shared
libraries.) There are other reasons for having DLL's, such as breaking
big programs into more manageable pieces, or re-using code for different
programs.

Most of the standard C library functions are fairly trivial in size -
many are wrappers around system calls (which are, of course, in system
libraries, not the C library). For many, the overhead of calling
external DLL functions greatly outweighs the size or the time taken by
the function itself - you want functions like strcat, memcpy, etc., to
be inlined in many cases, or at least implemented by a static library
rather than a DLL. Statically linking your C library is going to be of
insignificant size cost for most programs, but will often be of speed
benefit.

> Plus, system DLLs (as I consider msvcrt.dll) are usually not practical
> to statically link, because only DLLS are available (eg. kernel32.dll).
>

Regardless of how you consider things, "msvcrt.dll" is not a system DLL.
And any decent C standard library will be available for static linking.
(/Real/ system libraries, such as kernel32.dll, are a different matter.)

> How big would a program be if it incorporated half the Windows API as
> statically linked code?
>

For someone who claims to have developed their own languages, compilers,
linkers and other tools for decades, you are remarkably ignorant of how
toolchains work. Or you are trolling, as some people have suggested.
Perhaps you have just written in haste, without thinking - everyone
makes mistakes and occasionally writes something stupid.

> The GTK libraries on Windows numbered 28 different DLLs (I don't know
> how many MB in total). So what is special about using another DLL called
> msvcrt.dll?
>
> You just want to pour more scorn on the efforts of amateur compiler
> writers.
>

Given that there are other free C runtime libraries, I don't see any
good reason for using it when you simply want C coding, without a
specific need for compatibility with (older) MS tools. It is quite
possible that MSVCRT.DLL was the best choice in the past - it is not
now. I can't say I have looked into this in too much detail, since it
is not an issue that is at all relevant to me or my work. But I could
point out that at least two people here have shown the use of gcc with C
libraries that are quite happy with C99 printf. One - Keith - said he
had no trouble when using Cygwin. Someone else - I forget who - said
they could just use the "-lucrt" switch to get a working library. It
does not seem to be too difficult.

>> Anyone can take the source code for gcc
>
> No. It is a product that consists of about 100,000 files, of which about
> half are source files. It is HUGE. It would be a miracle just to get it
> to build using the automatic means provided, let alone understand the
> ins and outs of it enough to figure out how it deals with system libraries.
>

I've compiled it a good many times over the years (first with version
2.95 for the m68k target and a Windows NT 4 host, IIRC), for
cross-compiling.

But let me rephrase. Anyone competent and interested in compiling gcc,
can take the source code and compile it and package it in whatever way
they like. It does require a willingness to read the information
available, follow suggestions and instructions from others, and
generally do your best to get a working result. Those whose main aim is
to whine and cry, complain about the size, and generally try to find
excuses to say how terrible it all is, will probably find it hard to get
a working toolchain.

> When gcc compiles hello.c, it eventually invokes a linker with FIFTY
> different options.
>

So what?

I generally involve the /compiler/ with fifty different options - but
that is because I want these options and features while others might
not. I use build tools, and can write these options in a makefile. And
I /really/ don't care how many options are passed behind the scenes for
different parts of the toolchain - it is behind the scenes!

> That is a totally different world from what I do. My product doesn't
> even HAVE a linker! (Because it doesn't need it; an obsolete concept in
> my view.)
>

Yes, but your tools are useless for anyone but you. gcc (and binutils
for the linker, assuming that's the linker you are using) are designed
to be used by vast numbers of people for vast numbers of different
purposes in vast numbers of different circumstances.

Do you also complain about the size of supermarkets, or the number of
restaurants in your town, just because you are happy with a cheese
sandwich for dinner every night?

>
>>> So my attitude is, so what?
>>>
>>
>> If that's your attitude, that's fine - it's up to you.
>
> Because even your beloved gcc does it. And every program that a mingw
> gcc builds on Windows, will depend on it too, even when linked with
> -lucrt. So why on earth should I worry about whether /I/ use it?
>
>
>>
>> Many other C programmers - most, perhaps - have joined this century and
>> are using C99 at least.  If you are happy with a setup, toolchain and OS
>> for which you can't use C99, that's fine.  Don't expect anyone else to
>> have much consideration for your limited arrangements, however.
>
> All this fuss about "%zu" which is incredibly naff anyway. If using my
> bcc compiler, I can just write:
>
>    printf("%?", sizeof(T));
>
> which would work with ANY C library.
>
> If using my private language, it's even simpler:
>
>    print T.bytes
>
> So, I should put myself out for a 'format specifier' of the kind that
> should have been done away with last century. How about /you/ lot
> joining the 21st century!
>

Look, no one gives a ***** about your private little toy language. No
one cares. It is useless for anything real. Even if it was the
greatest invention since sliced bread, no one would use it because it is
the product of one angry little man whose prime motivation is a bizarre
and obsessive hatred of C (and C++) and tools for those languages. This
is comp.lang.c, where we use and discuss C. If any of us here want to
use a different language just to make it slightly simpler to print a
number, we all know of many /real/ languages to use. (And many of us
/do/ use other languages which are better than C for particular tasks.)

On 7/30/2021 10:47 AM, Keith Thompson wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>> On 2021-07-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 29/07/2021 03:20, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>>>> Sure, I can do that (after fixing the code with the right includes and
>>>>>> avoiding %zu). But that's the trial and error approach.
>>>>> %zu is the correct format specifier. I'm not even going to ask why
>>>>> you'd want to avoid it.
>>>>
>>>> I'll tell you anyway: it doesn't work on Windows.
>>>
>>> Yes, it does. I don't know why it wouldn't work for you. Are you using
>>> some obsolete version of Windows or of its C implementation?
>>
>> There is no "its C implementation" in regard to Windows. C programs for
>> Windows carry their own C run-times.
>>
>> (Some misguided developers think that an undocumented component called
>> MSVCRT.DLL in the system folder provides parts of the Library clause of
>> a C implementation for use by Windows applications; they are simply wrong.)
>
> Apparently MSVCRT.DLL is an old C runtime library that's still shipped
> with Windows for backward compatibility. It (probably) was the
> recommended C library implementation for use by Windows applications as
> of about 20 years ago.
>
> https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL
>

Iirc, they have a lot of legacy code from Dinkumwarein in there:

https://www.dinkumware.com/

Manfred <noname@add.invalid> writes:
> On 7/30/2021 8:16 PM, Keith Thompson wrote:
>> Manfred <noname@add.invalid> writes:
>> [...]
>>> Yes, if you use gcc under Windows you are actually importing a chain
>>> of dependencies that you don't want to bother with - That's the reason
>>> I only use gcc on Linux.
>> [...]
>> Cygwin is one way to use gcc under Windows, but it's not the only
>> one.
>> There are other implementations on Windows that include gcc but are not
>> connected to Cygwin. See for example mingw-w64 (which seems to have
>> some relationship to Cygwin, but I'm not clear on the details).
>
> Still I believe that none of them is officially supported by the gcc team.

Right, gcc and glibc are separate projects, both under the GNU umbrella.
I'm unsure of the relationship between newlib and GNU (a quick look at
its README and MAINTAINERS files was a bit confusing), but that doesn't
really matter for most purposes.

Of course the whole point of gcc is for it to be usable as a compiler.
If some change in gcc caused it not to work with glibc, that would be a
bug that would presumably be addressed with a high priority, and vice
versa. (A similar bug that affects gcc working together with a
Microsoft-specific runtime library might be given a lower priority.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 30/07/2021 20:01, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> But this is all getting away from the point you're trying to make,
>> which is that gcc has no hand at all it in providing a 'printf'
>> function for my C programs.
>>
>> You're wrong.
>
> No, he's right.
>
>> Further, if I try and compile this program:
>>
>> extern int printf(long long,...);
>>
>> int main(void) {
>> printf((long long)"Hello, World!\n");
>> }
>>
>> gcc complains that my printf conflicts with the built-in printf; so it
>> knows perfectly well what it is. It will even tell me if I get the
>> format codes wrong!
>
> gcc's warning message for that is:
>
> warning: conflicting types for built-in function ‘printf’; expected
> ‘int(const char *, ...)’ [-Wbuiltin-declaration-mismatch]
>
> The use of the term "built-in" is slightly misleading. The printf
> function is not built into the compiler. (Conceivably a compiler could
> provide a built-in printf implementation, but as far as I know none do).

It does say "builtin /declaration/ mismatch" - the "printf" function is
not a builtin in gcc, but the declaration is. (As you mentioned, it can
have that since the C standard specifies the declaration.)

Like many standard C functions, gcc will sometimes optimise printf
inline. But while functions like "strcat" or "memcpy" might be inlined
entirely, the inlining and optimisation of "printf" is much more
limited. gcc will turn

printf("Hello, World!\n");
into
puts("Hello, World!");

On 7/30/2021 1:10 PM, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 30/07/2021 19:17, Keith Thompson wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Bart <bc@freeuk.com> writes:
>
>> If you're using gcc via Cygwin, then all bets are off.
>>
>> It's not using gcc as a native Windows application, actually I don't
>> even know if you still end up with EXE files rather than ELF, and I
>> don't know what libraries will be used.
>>
>> Cygwin is an attempt to bring elements of Linux to Windows (along with
>> MSYS2 and WSL). I would not count it as directly running a C compiler on
>> Windows, and you can't really compare behaviour.
>>
>
> So use WSL instead of cygwin. You can download it from the
> windows store, in multiple flavors. Fully supported by
> Microsoft.
>

Indeed!