On Wednesday, July 28, 2021 at 10:20:43 PM UTC-4, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> > On 29/07/2021 00:07, Keith Thompson wrote:
> >> Bart <b...@freeuk.com> writes:
> >>> On 28/07/2021 18:21, Scott Lurndal wrote:
> >>>> Bart <b...@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.
>
> 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.
> > In the end I might end up with a list of such types for my platform,
> > and what concrete types they actually are.
> >
> > But, why doesn't such a list already exist anyway? It's not as though
> > my platform is a rare, obscure one out of hundreds; it's Windows on
> > x64. The other two I might be interested in are Linux on x64 and on
> > arm64.
> Such a list might exist somewhere. If it doesn't, or if it's hard to
> find, it's probably because not many people are interested in it.
>
> And I've just shown you how you can generate such a list yourself, by
> writing a C program that generates it.
>
> [snip]
>
> (I didn't look at the Fortran stuff.)

This is kind of what build systems are for, even though it doesn't suit
Bart's tastes. To find the size of an opaque type, you'd leverage something
similar to ac_check_sizeof from autoconf that basically generates a C
program, runs the program, inspects the stdout, stderr or return code, then
sets a define in a config.h style file based on the result.

Bart could even do his own mini home-grown version of that if he had
the motivation. You just need some kind of scripting language that can
interact with the shell.

On 29/07/2021 14:09, John Dill wrote:
> On Wednesday, July 28, 2021 at 10:20:43 PM UTC-4, Keith Thompson wrote:
>> Bart <b...@freeuk.com> writes:
>>> On 29/07/2021 00:07, Keith Thompson wrote:
>>>> Bart <b...@freeuk.com> writes:
>>>>> On 28/07/2021 18:21, Scott Lurndal wrote:
>>>>>> Bart <b...@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.
>>
>> 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.
>>> In the end I might end up with a list of such types for my platform,
>>> and what concrete types they actually are.
>>>
>>> But, why doesn't such a list already exist anyway? It's not as though
>>> my platform is a rare, obscure one out of hundreds; it's Windows on
>>> x64. The other two I might be interested in are Linux on x64 and on
>>> arm64.
>> Such a list might exist somewhere. If it doesn't, or if it's hard to
>> find, it's probably because not many people are interested in it.
>>
>> And I've just shown you how you can generate such a list yourself, by
>> writing a C program that generates it.
>>
>> [snip]
>>
>> (I didn't look at the Fortran stuff.)
>
> This is kind of what build systems are for, even though it doesn't suit
> Bart's tastes. To find the size of an opaque type, you'd leverage something
> similar to ac_check_sizeof from autoconf that basically generates a C
> program, runs the program, inspects the stdout, stderr or return code, then
> sets a define in a config.h style file based on the result.
>
> Bart could even do his own mini home-grown version of that if he had
> the motivation. You just need some kind of scripting language that can
> interact with the shell.
>

People seem to be missing the point. You shouldn't NEED to write
scripts, install a C compiler, write test programs just to find out what
a type is! They shouldn't work as hard as they do to hide these types.

For goodness sake, an offset type is either going to be i32 or i64!

Look at my link to Windows data types, where all the info needed is on
that one web-page.

Bart <bc@freeuk.com> writes:
>On 29/07/2021 14:09, John Dill wrote:

>>
>> Bart could even do his own mini home-grown version of that if he had
>> the motivation. You just need some kind of scripting language that can
>> interact with the shell.
>>
>
>People seem to be missing the point. You shouldn't NEED to write
>scripts, install a C compiler, write test programs just to find out what
>a type is! They shouldn't work as hard as they do to hide these types.

No, you're missing the point. 99.9999% of people writing code
in the C language don't need to know what the underlying type is. Noting
that it (off_t for example) is a signed integer is all they need
to know.

>
>For goodness sake, an offset type is either going to be i32 or i64!

No, it's not. C runs on many platforms other than Windows on x86.

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?

[...]

--
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 29/07/2021 14:51, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/07/2021 14:09, John Dill wrote:
>
>>>
>>> Bart could even do his own mini home-grown version of that if he had
>>> the motivation. You just need some kind of scripting language that can
>>> interact with the shell.
>>>
>>
>> People seem to be missing the point. You shouldn't NEED to write
>> scripts, install a C compiler, write test programs just to find out what
>> a type is! They shouldn't work as hard as they do to hide these types.
>
> No, you're missing the point. 99.9999% of people writing code
> in the C language don't need to know what the underlying type is. Noting
> that it (off_t for example) is a signed integer is all they need
> to know.
>
>>
>> For goodness sake, an offset type is either going to be i32 or i64!
>
> No, it's not. C runs on many platforms other than Windows on x86.
>

You have a small point, but mainly you're just making excuses for some
terrible header code that should long have been cleaned up.

The _mingw_off_t.h file I posted that makes such a meal of defining
off_t, is specifically for Windows on x86.

I would also suggest that those languages that would like to use C
libraries, the ones that predominantly use integer types based around
8/16/32/64 bits, will not be running on the same 13-bit processors that
C likes to support.

They are also unlikely to run under a system where a file offset of 16
bits is sufficient (that would be too small even for a 1980s floppy
disk). The most useful type these days would be i64.

I actually haven't used fstat(), if that's what's it's called, for
perhaps 20 years. There are two many myriad combinations of it with the
numerous variations of struct stat, off_t and the rest.

There are 8 combinations listed here (6 functions plus file length
variations, halfway down the page):

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fstat-fstat32-fstat64-fstati64-fstat32i64-fstat64i32?view=msvc-160

Another page lists TWELVE versions of struct stat (6 using char* plus 6
with wchar_t*).

This is for basically two platforms (Win32 and Win64), but they will run
under the same file system that will have files bigger than 2GB, so
you'd expect the same file functions and associated types for both.

I would call that messy, and that's without even delving into the headers.

On 29/07/2021 16:12, Keith Thompson 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?

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).

It shows the correct value with lccwin, DMC, clang and CL (MS' compiler).

Since I predominantly use the first 3 compilers, I don't find zu useful.

Actually until I did this test, I couldn't remember which supported it
and which didn't. I like code that works on anything, so prefer to use a
format supported on any compiler.

Maybe there is a way of persuading gcc to use better libraries, but I've
no idea how, and anyway like to run it like this:

gcc prog.c

If this a program that will only be used with bcc, then there I can use
"%?", which is replaced with the correct format, I believe "%llu" here,
and get the right answer as well. That would have been a more useful
extension than another bizarre and very specific format.

Bart <bc@freeuk.com> writes:
>On 29/07/2021 16:12, Keith Thompson 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?
>
>It's Windows 7. gcc is version 9.2.0.
>
>This program:
>
> #include <stdio.h>
> int main(void) {printf("%zu\n",sizeof(void*));}

It has _always_ worked properly with GCC. You're clearly
either doing something incorrect if your assertion is accurate.

$ cc -o /tmp/b /tmp/b.c
$ /tmp/b
8 $ cat /tmp/b.c
#include <stdio.h>
int main(void) {printf("%zu\n",sizeof(void*));}
$ cc --version
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Bart <bc@freeuk.com> writes:
> On 29/07/2021 16:12, Keith Thompson 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?
>
> 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).
>
> It shows the correct value with lccwin, DMC, clang and CL (MS' compiler).
>
> Since I predominantly use the first 3 compilers, I don't find zu useful.
>
> Actually until I did this test, I couldn't remember which supported it
> and which didn't. I like code that works on anything, so prefer to use
> a format supported on any compiler.
>
> Maybe there is a way of persuading gcc to use better libraries, but
> I've no idea how, and anyway like to run it like this:
>
> gcc prog.c
>
> If this a program that will only be used with bcc, then there I can
> use "%?", which is replaced with the correct format, I believe "%llu"
> here, and get the right answer as well. That would have been a more
> useful extension than another bizarre and very specific format.

The problem is with the old C library. The version of gcc is
irrelevant.

Windows 7 is obsolete. If you're stuck using it for some reason, that's
a valid reason to avoid "%zu". "it doesn't work on Windows" is not.

--
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 29/07/2021 16:12, Keith Thompson 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?
>>
>>It's Windows 7. gcc is version 9.2.0.
>>
>>This program:
>>
>> #include <stdio.h>
>> int main(void) {printf("%zu\n",sizeof(void*));}
>
> It has _always_ worked properly with GCC. You're clearly
> either doing something incorrect if your assertion is accurate.

[...]

gcc doesn't implement printf. The C library does. Bart is using an
obsolete version of Microsoft's C library.

--
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 29/07/2021 18:28, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> 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 problem is with the old C library. The version of gcc is
> irrelevant.
>
> Windows 7 is obsolete. If you're stuck using it for some reason, that's
> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.

Looks like Windows 10 is obsolete too:

c:\c>ver
Microsoft Windows [Version 10.0.14393]

c:\c>type c.c
#include <stdio.h>

int main(void) {
printf("%zu\n", sizeof(void*));
}

c:\c>gcc c.c

c:\c>a
zu

Bart <bc@freeuk.com> writes:
> On 29/07/2021 18:28, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> 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 problem is with the old C library. The version of gcc is
>> irrelevant.
>> Windows 7 is obsolete. If you're stuck using it for some reason,
>> that's
>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>
> Looks like Windows 10 is obsolete too:
>
> c:\c>ver
> Microsoft Windows [Version 10.0.14393]
>
> c:\c>type c.c
> #include <stdio.h>
>
> int main(void) {
> printf("%zu\n", sizeof(void*));
> }
>
> c:\c>gcc c.c
>
> c:\c>a
> zu

No, it looks like you're using an obsolete C library implementation on
Windows 10. I'm able to compile and run your program on Windows 10,
and it prints 8 or 4 depending on which implementation I use.

You could probably get some help with that if you asked (and provided
some information).

--
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 29/07/2021 19:16, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/07/2021 18:28, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> 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 problem is with the old C library. The version of gcc is
>>> irrelevant.
>>> Windows 7 is obsolete. If you're stuck using it for some reason,
>>> that's
>>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>>
>> Looks like Windows 10 is obsolete too:
>>
>> c:\c>ver
>> Microsoft Windows [Version 10.0.14393]
>>
>> c:\c>type c.c
>> #include <stdio.h>
>>
>> int main(void) {
>> printf("%zu\n", sizeof(void*));
>> }
>>
>> c:\c>gcc c.c
>>
>> c:\c>a
>> zu
>
> No, it looks like you're using an obsolete C library implementation on
> Windows 10.

You said 'Windows 7 is obsolete'.

Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
Even if I could, installing a different library wouldn't be much help,
since then I'd have programs that worked fine on my Windows, but on no
one else's unless they jumped through the same hoops.

Just for the sake of %zu which can be trivially replaced with %d and a
(int) cast (or %lld and (long long) if expecting some big objects), it
is not worth the headache of extra dependencies.

> I'm able to compile and run your program on Windows 10,
> and it prints 8 or 4 depending on which implementation I use.
>
> You could probably get some help with that if you asked (and provided
> some information).

Does Tiny C work too?

Bart <bc@freeuk.com> writes:
> On 29/07/2021 19:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 18:28, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> 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 problem is with the old C library. The version of gcc is
>>>> irrelevant.
>>>> Windows 7 is obsolete. If you're stuck using it for some reason,
>>>> that's
>>>> a valid reason to avoid "%zu". "it doesn't work on Windows" is not.
>>>
>>> Looks like Windows 10 is obsolete too:
>>>
>>> c:\c>ver
>>> Microsoft Windows [Version 10.0.14393]
>>>
>>> c:\c>type c.c
>>> #include <stdio.h>
>>>
>>> int main(void) {
>>> printf("%zu\n", sizeof(void*));
>>> }
>>>
>>> c:\c>gcc c.c
>>>
>>> c:\c>a
>>> zu
>> No, it looks like you're using an obsolete C library implementation
>> on
>> Windows 10.
>
> You said 'Windows 7 is obsolete'.

I did, and it is.

> Anyway, how can the C library be obsolete if it comes /with/ Windows
> 10? Even if I could, installing a different library wouldn't be much
> help, since then I'd have programs that worked fine on my Windows, but
> on no one else's unless they jumped through the same hoops.

I don't know enough about it to answer that. I use Visual Studio for
work and Cygwin for personal use. I don't have a gcc-based
implementation outside Cygwin. Microsoft's online documentation says
"%zu" works.

I know that Microsoft was very slow to support C99 (which is where %zu
was introduced), but they've made considerable progress more recently.

> Just for the sake of %zu which can be trivially replaced with %d and a
> (int) cast (or %lld and (long long) if expecting some big objects), it
> is not worth the headache of extra dependencies.

On the systems and implementions I currently use, there are no extra
dependencies; "%zu" just works, and I don't seem to have an
implementation where it doesn't. For my own purposes, I have no reason
to avoid "%zu". Obviously your situation is different, and there are
several workarounds you can use.

I don't know what C library implementation you're using or how it was
installed, other than your statement that it came with Windows 10.
If you're not bothered by its lack of support for "%zu", I don't see
anything more to discuss.

>> I'm able to compile and run your program on Windows 10,
>> and it prints 8 or 4 depending on which implementation I use.
>> You could probably get some help with that if you asked (and
>> provided
>> some information).
>
> Does Tiny C work too?

I don't have Tiny C on either Windows 10 system I have access to, but I
presume it would use the same library that gcc uses, so I'd expect it to
work. (tcc, like gcc, is a compiler, not a complete implementation.
You have a habit of glossing over that.)

--
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/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.

And I've been dealing with code where typedefs *aren't* co-located
with the type definition.

> Your remark makes sense for a typedef name for a pointer to such
> a structure. That's often intended to be an abstract handle.
>

Yeah, and what I'm saying is don't half-ass the abstraction - either
make it fully abstract or don't bother. Don't hide the information
I need to properly use the type behind a typedef. I would rather you
leave the type "naked", even if it's more eye-stabby or a pain in
the ass to type.

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.

--
Ben.

On 2021-07-29, Bart <bc@freeuk.com> wrote:
> I'll tell you anyway: [%zu] doesn't work on Windows.

That has no meaning. "Windows" is not a C implementation.

%zu works on Windows if you find a C implementation for Windows with
a run-time library whose printf supports it.

I see that Microsoft is documenting "z". Find the MSDN documentation
page called "Format specification syntax: printf and wprintf functions"
and search within it for "Size Prefixes for printf and wprintf
Format-Type Specifiers".

https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-160

Also supported in Cygwin and probably other run-times like MinGW-W64.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

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.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2021-07-29, Bart <bc@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.

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.

A few misguided free software developers came up with the idea that that
doing this is a good way to port GNU programs to Windows, because the
GPL has a "system library exception".

So that is to say, a GPL-ed program being linked to Microsoft's
redistributable Visual C run-time would be a GPL violation because that
run-time is not a system library, but just another proprietary
third-party library with a GPL-incompatible license.

Some have additionally defended this idiotic choice because it produces
single .EXE programs that are small. That's like saying, "look at the
weight and space we can save if we don't put heat sinks on these
power transistors; who cares if we are outside of the documented
safe operating area!"

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 30/07/2021 15:55, Kaz Kylheku wrote:
> On 2021-07-29, Bart <bc@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".

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?

I don't know. However, if I peek inside an executable for hello.c
created with tcc, it apparently imports msvcrt.dll, same as mine does.

gcc does the same. But if I try Clang, there is no import library (or no
relevant one). So whatever it uses might be statically linked in.

Same with MSVC (CL), but that is unsurprising, since Clang, despite
being a massive 1600MB installation with LLVM, apparently relies on MS
tools to do the linking, so may use the same library.

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.

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!

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.

Irrespective of all of that, my point remains - either fully abstract,
or don't bother.

On 7/29/2021 8:41 PM, Bart wrote:
> On 29/07/2021 19:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/07/2021 18:28, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> 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 problem is with the old C library.  The version of gcc is
>>>> irrelevant.
>>>> Windows 7 is obsolete.  If you're stuck using it for some reason,
>>>> that's
>>>> a valid reason to avoid "%zu".  "it doesn't work on Windows" is not.
>>>
>>> Looks like Windows 10 is obsolete too:
>>>
>>>    c:\c>ver
>>>    Microsoft Windows [Version 10.0.14393]
>>>
>>>    c:\c>type c.c
>>>      #include <stdio.h>
>>>
>>>      int main(void) {
>>>          printf("%zu\n", sizeof(void*));
>>>      }
>>>
>>>    c:\c>gcc c.c
>>>
>>>    c:\c>a
>>>    zu
>>
>> No, it looks like you're using an obsolete C library implementation on
>> Windows 10.
>
> You said 'Windows 7 is obsolete'.
>
> Anyway, how can the C library be obsolete if it comes /with/ Windows 10?
> Even if I could, installing a different library wouldn't be much help,
> since then I'd have programs that worked fine on my Windows, but on no
> one else's unless they jumped through the same hoops.

This is a Windows problem, not gcc. As far as I can tell printf comes
with the famous msvcrt.dll, which comes with Windows, BUT also comes
with msvcrXXX.dll as an official redistributable of Visual Studio, that
Microsoft allows to distribute with applications developed with that.
Microsoft gives guidelines for installers about how to deploy these
components, but the result, obviously, is that different Windows boxes
have different C runtimes depending on which packages have been installed.

As a curiosity, you may try this:

#include <Windows.h>
#include <stdio.h>

typedef int (*__cdecl PrintfT)(const char * _Format, ...);

int main(void)
{ if (HMODULE msvcrtLib = LoadLibrary("msvcrt.dll"))
{
PrintfT msvcrtPrintf = (PrintfT)GetProcAddress(msvcrtLib, "printf");

msvcrtPrintf("msvcrtPrintf %zu\n", sizeof(void*));

FreeLibrary(msvcrtLib);
}

printf("printf %zu\n", sizeof(void*));
}

As usual, Microsoft C implementation has always been "peculiar".
Moreover, if you use gcc under Windows (I don't) you are actually using
cygwin's port of gcc *and* some libc implementation, which is /not/
supported by the gcc team.

>
> Just for the sake of %zu which can be trivially replaced with %d and a
> (int) cast (or %lld and (long long) if expecting some big objects), it
> is not worth the headache of extra dependencies.

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.

>
>> I'm able to compile and run your program on Windows 10,
>> and it prints 8 or 4 depending on which implementation I use.
>>
>> You could probably get some help with that if you asked (and provided
>> some information).
>
> Does Tiny C work too?
>
>

John Bode <jfbode1029@gmail.com> writes:

> On 7/27/21 10:47 AM, Kaz Kylheku wrote:
>> 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.

Digressing, I know, but that's flatly untrue. Both programs have
had basic functionality for that, using external databases, for
thirty or forty years.

--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/

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.

(I don't have time to look at various other applications.)

So my attitude is, so what?

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.

Oh, I thought vi could do this "out of the box". But I'm not a vi
person so I may have got the wrong end of the stick.

> ... 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.

That's fine. It the "neither of which [vi or emacs] have that kind of
intelligence" I was commenting on.

--
Ben.