BGB <cr88192@gmail.com> writes:
>On 12/30/2023 12:51 AM, Blue-Maned_Hawk wrote:
>> Bart wrote:
>>
>>> Why not have a dedicated header file that is the specific to a
>>> particular version of a C compiler for a given platform? That it can be
>>> streamlined for that purpose.
>>
>> In fact, this is similar to exactly what Plan 9 did: for include files
>> that had arch-dependent content, it'd have a separate version of them for
>> each arch, with an arch's versions of headers like these all stored in
>> their own directory.
>>
>
>Yeah, we don't actually need big monolithic C libraries, nor big
>monolithic C compilers, ...

What monolithic C libraries are you referring to? My application
links with a several dozen libraries, some at startup, some dynamically
at run-time. Nothing monolithic there. POSIX only requires that
-lc include the necessarily functionality for the POSIX API, it
doesn't require that the implementation use a single library/shared
object at run-time.

Both GCC and CLANG do just as you describe here:

>Though, it seems like a different kind of strategy could be possible:
>Split compilers into frontends and backends (which may exist as
>semi-independent projects).
>
>Frontend deals with source languages, compiles down to a common IR (with
>the IR taking the place of object files);
>Backend compiles this to the actual machine code, and does any linking,
>before emitting the actual binary.

See LLVM.

Bart <bc@freeuk.cm> writes:
>On 31/12/2023 15:25, David Brown wrote:

>> I realise that you (and possibly others) might find it useful for a tool
>> to replace typedef identifiers with their definitions, but it could only
>> be done for some cases, and is not as simple as macro substitution.
>
>Take this program, which uses two nested typedefs and one macro:
>
> typedef short T;
> typedef T U;
> #define V U
>
> typedef struct R {
> V a, b, c;
> } S;
>
>Passed through 'gcc -E', it manages to expand the V in the struct with
>U. (-fdirectives-only doesn't even do that).
>
>So what are the types of 'a, b, c'? Across 1000s of line of code, they
>may need tracking down. At least, for someone not using your super-duper
>tools.

Perhaps you need to use better names than V, a, b, and c.

On 2023-12-31, Bart <bc@freeuk.cm> wrote:
> Take this program, which uses two nested typedefs and one macro:
>
> typedef short T;
> typedef T U;
> #define V U
>
> typedef struct R {
> V a, b, c;
> } S;
>
> Passed through 'gcc -E', it manages to expand the V in the struct with
> U. (-fdirectives-only doesn't even do that).
>
> So what are the types of 'a, b, c'? Across 1000s of line of code, they
> may need tracking down. At least, for someone not using your super-duper
> tools.

Super duper tools like, oh, Exuberant Ctags from 2011, packaged in Ubuntu:

$ ctags --version
Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
Addresses: <dhiebert@users.sourceforge.net>, http://ctags.sourceforge.net
Optional compiled features: +wildcards, +regex

We run that and then super-duper editor Vim will use the tags
file to jump to the definition of V, and of U.

On 31/12/2023 17:26, Kaz Kylheku wrote:
> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
>> and file handles. With DLL, a pointer malloc-ed in the host cannot be
>> freed within the DLL and vice versa.)
>
> What??? All DLLs are in the same address space. malloc and free are
> sister functions that typically live in the same DLL, and don't
> care what calls them.
>
> Maybe you're referring to one DLL's free not being able to handle
> pointers produced by another DLL's malloc.

I'm referring to the possibilty that, if host and DLL both import say
msvcrt.dll, that each may have its own instance of msvcrt.dll, with its
own static data. That would also be the case with two DLLs.

But I can't reproduce the kind of error that would cause.

So I was either mistaken, or it's been fixed in the last decade, or
maybe my original test failed for other reasons, eg. because of
statically linked libraries not shared ones, or mixed compilers (and do
libraries) were used.

On 31/12/2023 18:44, Kaz Kylheku wrote:
> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
>> Take this program, which uses two nested typedefs and one macro:
>>
>> typedef short T;
>> typedef T U;
>> #define V U
>>
>> typedef struct R {
>> V a, b, c;
>> } S;
>>
>> Passed through 'gcc -E', it manages to expand the V in the struct with
>> U. (-fdirectives-only doesn't even do that).
>>
>> So what are the types of 'a, b, c'? Across 1000s of line of code, they
>> may need tracking down. At least, for someone not using your super-duper
>> tools.
>
> Super duper tools like, oh, Exuberant Ctags from 2011, packaged in Ubuntu:
>
> $ ctags --version
> Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
> Addresses: <dhiebert@users.sourceforge.net>, http://ctags.sourceforge.net
> Optional compiled features: +wildcards, +regex
>
> We run that and then super-duper editor Vim will use the tags
> file to jump to the definition of V, and of U.

Actually ctags appears to be also part of Windows.

I've played with it and the results are interesting.

I've recently created something vaguely similar for my language, invoked
via the compiler (mm -getst prog) which scans all modules and produces a
list of references (currently only top-level names) to help find them
from my IDE.

I don't know how useful ctags might be in helping extract bindings from
a complex set of API headers, but I've got that covered.

On 12/31/23 2:23 PM, Bart wrote:
> On 31/12/2023 17:26, Kaz Kylheku wrote:
>> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
>>> and file handles. With DLL, a pointer malloc-ed in the host cannot be
>>> freed within the DLL and vice versa.)
>>
>> What??? All DLLs are in the same address space. malloc and free are
>> sister functions that typically live in the same DLL, and don't
>> care what calls them.
>>
>> Maybe you're referring to one DLL's free not being able to handle
>> pointers produced by another DLL's malloc.
>
> I'm referring to the possibilty that, if host and DLL both import say
> msvcrt.dll, that each may have its own instance of msvcrt.dll, with its
> own static data. That would also be the case with two DLLs.
>
> But I can't reproduce the kind of error that would cause.
>
> So I was either mistaken, or it's been fixed in the last decade, or
> maybe my original test failed for other reasons, eg. because of
> statically linked libraries not shared ones, or mixed compilers (and do
> libraries) were used.
>
>

Sounds like either something used a static library or forced the system
to link in two different copies of msvcrt.dll (perhaps by incorrectly
including their own in an off-path directory)

This wasn't that uncommon of a problem until people got burned enough by
not following "the rules" that they started to do it right.

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2023-12-31, Bart <bc@freeuk.cm> wrote:
>> Take this program, which uses two nested typedefs and one macro:
>>
>> typedef short T;
>> typedef T U;
>> #define V U
>>
>> typedef struct R {
>> V a, b, c;
>> } S;
>>
>> Passed through 'gcc -E', it manages to expand the V in the struct with
>> U. (-fdirectives-only doesn't even do that).
>>
>> So what are the types of 'a, b, c'? Across 1000s of line of code, they
>> may need tracking down. At least, for someone not using your super-duper
>> tools.
>
>Super duper tools like, oh, Exuberant Ctags from 2011, packaged in Ubuntu:
>
>$ ctags --version
>Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
> Addresses: <dhiebert@users.sourceforge.net>, http://ctags.sourceforge.net
> Optional compiled features: +wildcards, +regex
>
>We run that and then super-duper editor Vim will use the tags
>file to jump to the definition of V, and of U.

Or the super-duper tool called cscope.

$ find . -name '*.[chCHsS]*' -print |grep -v .svn |sort -u | cscope -q -b -k -f csc -i -

Which the super-duper VIM editor will leverage for both
tags support and cscope query support.

$ vim
:cs add csc
:cs f 1 main

On Sun, 31 Dec 2023 02:06:37 +0000, Bart wrote:

> I have plenty of ideas, but people are generally not interested.

Lessig’s Law: “the one who writes the code, makes the rules”.

Nobody cares about “ideas”. “Ideas” are a dime a dozen. What matters is
execution. Put your “idea” into working code, and that will prove your
point.

On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:

> I realise that you (and possibly others) might find it useful for a tool
> to replace typedef identifiers with their definitions, but it could only
> be done for some cases, and is not as simple as macro substitution.

String-based macros are nothing but trouble. Typedefs are scoped, string
macros are not.

If you want to see the right way to do macros, look at LISP, where they
are token-based, and much more robust as as result. I think they even
manage to apply scoping rules to macro definitions as well.

On 12/31/2023 9:26 AM, Bart wrote:
> On 31/12/2023 05:46, BGB wrote:
>> On 12/30/2023 8:18 PM, Bart wrote:
>>> On 31/12/2023 01:34, Lawrence D'Oliveiro wrote:
>>>> On Sat, 30 Dec 2023 19:14:55 -0600, BGB wrote:
>>>>
>>>>> Note that (unlike ELF on Linux), it is not currently possible to
>>>>> directly share global variables across DLL boundaries.
>>>>
>>>> Windows is broken in so many ways ... when you achieve something, it’s
>>>> like getting a bear to dance: it’s not that it dances badly, but
>>>> that it
>>>> dances at all.
>>> I think that that limitation was specific to BGB's handling of DLLs;
>>> it was not made clear.
>>>
>>
>> Yes.
>>
>> In my case (for my custom target) I am using a modified version of
>> PE/COFF (with some tweaks, *), but it has the issue that there is not
>> currently (any) mechanism for sharing variables across DLL boundaries
>> apart from getter/setter functions or similar.
>
> I find PE/COFF format a nightmare. I did eventually get my tools to
> generate first OBJ then EXE files. But when it came to DLL, there was
> something wrong in the files I generated that I couldn't fix.
>
> So for a couple of years, I created my own shared library format,
> utterly different from PE+, and about 10 times simpler.
>
> The shared library files were called ML, and I extended it to standalone
> executables called MX files.
>
> However ML libraries could only be used from my languages, and MX files
> needed a small conventional EXE loader to get started.
>
> Eventually I fixed the problems with DLL. (Partly it was that my
> generated code wasn't fully position-independent and only ran in
> low-memory below 2GB, but there was also a bug in the base-reloc tables.)
>
> Now, sadly, I will probably drop my ML/MX files, even though my MLs have
> advantages over DLLs. (Eg. they have the same environment as the host
> apps, so that they can share things like pointers to allocated memory
> and file handles. With DLL, a pointer malloc-ed in the host cannot be
> freed within the DLL and vice versa.)
>

OK.

I had considered a fully custom format at one point, original idea would
have been something vaguely resembling a AR or TAR file, say:
Program Header;
Segment Header;
LZ compressed segment;
Segment Header;
LZ compressed segment;
...

Where say, each segment may have one or more sections, specify a loader
address, and may include additional commands for what to do with it
(such as interpreting it as base relocs rather than being part of the
final image).

Technically, this would have also been along vaguely similar lines to
the Mach-O format.

But ended up opting with a modified PE/COFF as it already had most of
what I wanted (and I was already reasonably familiar with the format).
My case differed slightly in that I didn't need to care about whether
Windows or existing tools could understand the binaries, and so "PEL4"
is sort of its own format in a way as well.

Technically, it still fit what I wanted to do better than what ELF would
have been, though I had ended up tweaking some stuff to allow it to
support loading multiple binaries into the same address space:
All binaries include reloc tables;
The read-only and read/write sections are split up into two different
segments (using the Global Pointer data-directory entry to effectively
define the read/write section, with the Global Pointer pointed to the
start of this segment on program start-up).

I had looked into a few possible compression schemes, and LZ4 gave the
best properties for binaries.

I have a different (byte-oriented) compression scheme that tends to give
better compression for general purpose data compression, but LZ4 seemed
to give better results with executable code in this case.

>
>>> Each DLL exports certain symbols such as the addresses of functions
>>> and variables. So no reason you can't access a variable exported from
>>> any DLL, unless perhaps multiple instances of the same DLL have to
>>> share the same static data, but that sounds very unlikely, as little
>>> would work.
>>>
>>
>> Much past roughly Win9x or so, it has been possible to use
>> "__declspec(dllimport)" on global variables in Windows (in an earlier
>> era, it was not possible to use the __declspec's, but instead
>> necessary to manage DLL import/exports by writing out lists in ".DEF"
>> files).
>>
>> It isn't entirely transparent, but yes, on actual Windows, it is very
>> much possible to share global variables across DLL boundaries.
>>
>>
>> Just, this feature is not (yet) supported by my compiler. Personally,
>> I don't see this as a huge loss (even if it did work; I personally see
>> it as "poor coding practice").
>
> This is a language issue. Or, in C, it is compiler related.
>
> I've never been quite sure how you tell a C compiler to export a certain
> symbol when creating a DLL. Sometimes it just works; I think it just
> exports everything that is not static (it may depend on a compiler
> option too).
>
> And some compilers may need this __declspec business, but I've never
> bothered with it.
>

Yeah. GCC seems to be "export everything".

MSVC needs either __declspec or ".DEF" files.

I am not sure when exactly __declspec started being used for this,
seemingly sometime between "Visual C++ 4.0" and "Visual Studio 2003".
This isn't really documented online to really narrow it down much further.

In my case, I went with using a similar approach to MSVC, namely
explicit export.

Where the normal "extern" storage class is shared between translation
units, but does not cross DLL boundaries.

> Mine just exports all not-static names. So this program:
>
>    int abc;
>    static int def;
>
>    void F(void) {}
>    static void G(void) {}
>
> if compiled as: 'mcc -dll prog', produces a file prog.dll which, if I
> dump it, shows this export table:
>
>  Export Directory
>
>     0 00000000        0 Fun F
>     1 00000000        0 Var abc
>
> (There's something in it that distinguishes functions from variables,
> but I can't remember the details.)
>
> In any case, in C it can be hit and miss. In my own language, it is more
> controlled: I used an 'export' prefix to export symbols from a program.
>
> (It also conventiently creates interface files to be able to use the DLL
> library from a program. The equivalent of prog.h for my example
> containing the API needed to use it. Rolling that out to C is not
> practical however as my 'export' applies also to things like types and
> enums.)
>

In my case, there are two major ways of invoking the compiler, say:
bgbcc /Fefoo.dll foo.c
Or:
bgbcc -o foo.dll foo.c

Where the compiler uses the file extension, and if it is DLL, it assumes
you want a DLL:
EXE: EXE file, "PBO ABI", fully relocatable.
DLL: DLL file, "PBO ABI", fully relocatable.
SYS: Bare-metal EXE, ABI more like traditional Win32 EXEs.
BIN: ROM image, no EXE headers, no relocs, ...
RIL: RIL Bytecode
OBJ: RIL Bytecode
O: Also RIL Bytecode
S: ASM output.

If no output file is given, it looks at whether it is trying to mimic
GCC style command-line behavior:
No: Assume "foo.exe" as default output.
Yes: Assume "a.exe" as default output.

Where, say, for the GCC-like mode:
-o <name> Output file.
-c Compile only
-E Preprocess only
-S ASM only.
-I<path> Add include path
-L<path> Add library path
-S<path> Add source path (excludes '-S' by itself)
-l<name> Add library
-D<name>[=<value>] #define something
-W<opt> Warning option
-m<tgt> Specify target machine
-f<opt> Specify target option/flag
-O<opt> Specify optimizer option.
-Z<opt> Specify debug option.
-g<opt> Also specify debug option.
...

For libraries, it checks the library path, where for "-l<name>" it will
look for:
lib<name>.<arch>.ril
lib<name>.ril
Assuming static linking in this case (the handling for DLLs is a little
different).

Note that, sort of like with MSVC, any debug data is dumped into
external files, and is not held within the EXE itself. Thus far, it is
fairly limited, mostly as a big ASCII text file with with a vaguely
similar structure to "nm" output.

On 12/31/2023 1:44 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:
>
>> I realise that you (and possibly others) might find it useful for a tool
>> to replace typedef identifiers with their definitions, but it could only
>> be done for some cases, and is not as simple as macro substitution.
>
> String-based macros are nothing but trouble. Typedefs are scoped, string
> macros are not.
>
> If you want to see the right way to do macros, look at LISP, where they
> are token-based, and much more robust as as result. I think they even
> manage to apply scoping rules to macro definitions as well.

Fwiw, check this out:

https://github.com/rofl0r/chaos-pp

:^)

On 31/12/2023 19:37, Bart wrote:
> On 31/12/2023 18:44, Kaz Kylheku wrote:
>> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
>>> Take this program, which uses two nested typedefs and one macro:
>>>
>>>      typedef short T;
>>>      typedef T U;
>>>      #define V U
>>>
>>>      typedef struct R {
>>>          V a, b, c;
>>>      } S;
>>>
>>> Passed through 'gcc -E', it manages to expand the V in the struct with
>>> U. (-fdirectives-only doesn't even do that).
>>>
>>> So what are the types of 'a, b, c'? Across 1000s of line of code, they
>>> may need tracking down. At least, for someone not using your super-duper
>>> tools.
>>
>> Super duper tools like, oh, Exuberant Ctags from 2011, packaged in
>> Ubuntu:
>>
>> $ ctags --version
>> Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
>>    Addresses: <dhiebert@users.sourceforge.net>,
>> http://ctags.sourceforge.net
>>    Optional compiled features: +wildcards, +regex
>>
>> We run that and then super-duper editor Vim will use the tags
>> file to jump to the definition of V, and of U.
>
> Actually ctags appears to be also part of Windows.

That's not the case, it just happened to be bundled with Windows.

It's a 1.25MB file so fairly 'super', compared with my stuff. The option
I said I'd added to my compiler was about 70 lines of extra code, but it
looks to be a bit more sophisticated as the compiler has done the hard
work, and it just dumps parts of the symbol table.

>> We run that and then super-duper editor Vim will use the tags
>> file to jump to the definition of V, and of U.

How does Vim know where in the file to look? The TAGS files I've managed
to produce doesn't have that info, and I can't see anything in the help
to add it.

How do you get it to look inside header files, or do those have to be
submitted manually?

Spiros Bousbouras <spibou@gmail.com> writes:

[... on #define _BSD_SOURCE, etc ...]

> By the way , this kind of question is more appropriate for
> comp.unix.programmer .

For what it's worth, I found the discussion valuable. I
look at comp.unix.programmer only sporadically, so I'm
glad it was posted here.

On 12/31/2023 12:37 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 12/30/2023 12:51 AM, Blue-Maned_Hawk wrote:
>>> Bart wrote:
>>>
>>>> Why not have a dedicated header file that is the specific to a
>>>> particular version of a C compiler for a given platform? That it can be
>>>> streamlined for that purpose.
>>>
>>> In fact, this is similar to exactly what Plan 9 did: for include files
>>> that had arch-dependent content, it'd have a separate version of them for
>>> each arch, with an arch's versions of headers like these all stored in
>>> their own directory.
>>>
>>
>> Yeah, we don't actually need big monolithic C libraries, nor big
>> monolithic C compilers, ...
>
> What monolithic C libraries are you referring to? My application
> links with a several dozen libraries, some at startup, some dynamically
> at run-time. Nothing monolithic there. POSIX only requires that
> -lc include the necessarily functionality for the POSIX API, it
> doesn't require that the implementation use a single library/shared
> object at run-time.
>

Not in terms of "one C library has all the code" but rather, "everything
is expected to use the same C library" (such as GLIBC on Linux).

Granted, there are (sort of) Newlib and Musl as alternative libc's.

>
> Both GCC and CLANG do just as you describe here:
>
>> Though, it seems like a different kind of strategy could be possible:
>> Split compilers into frontends and backends (which may exist as
>> semi-independent projects).
>>
>> Frontend deals with source languages, compiles down to a common IR (with
>> the IR taking the place of object files);
>> Backend compiles this to the actual machine code, and does any linking,
>> before emitting the actual binary.
>
> See LLVM.
>

LLVM bitcode would be kind of a pain though to deal with in anything
that is not LLVM (exposes too many aspects of LLVM in its design, and
not really documented in a way that makes sense outside the context of
LLVM).

My own preference here would be for something more like .NET CIL, but
adapted to make more sense for a language like C (granted, compiling C
to .NET CIL is still less bad than some of the other options, such as
JVM/Flash/WASM/... which generally involved needing to go through a lot
of awkward contortions).

Main drawback of LLVM is mostly that it is a pain to recompile from
source, and writing a new backend for LLVM would presumably require
rebuilding it frequently, which is not an attractive option if it takes
30 minutes or so for each rebuild.

As for GCC, it seems not so much to split the compiler into a frontend
and backend; so much as to split and scatter each target across all of
binutils (so, would need to poke at LD, GAS, BFD, ... at each step
adding awareness of the specific aspects of the target relevant to the
component in question).

So, adding a target like mine would likely require touching pretty much
every part of the toolchain, which is already well into MLOC territory.

Well, and in this case, GCC is more like a confederation of tools and
libraries.

Rather than there being any obvious "backend module":
Well, say, if one imagines the compiler backend as sort of like a video
codec module, where one gives it inputs and configures the desired
operation and output using FOURCC's and similar ("Here is the 3AC and
metadata for a program; give me the output as a DLL"...).

GCC just doesn't work this way:
Like, it more goes as layers:
C -> preprocessor output;
PP-out -> AST -> GIMPLE;
GIMPLE -> ASM;
ASM -> OBJ;
Pass OBJ's to LD;
...
With, generally, each part of the process existing as multiple binaries
and using temporary files to move data around.

Granted, when I started my project, I didn't expect that my compiler
would end up being 250 kLOC, and there are a few things I did that were
obvious design missteps in retrospect.

In particular, I would prefer cleaner separation between internal
subsystems and stages. I had intended to address some issues in an
attempt at a new ground-up compiler design, but this effort stalled.

....

On Sun, 31 Dec 2023 02:18:25 +0000, Bart wrote:

> This somes my experience of software originating in Linux. This is why
> Windows had to acquire CYGWIN then MSYS then WSL. You can't build the
> simplest program without involving half of Linux.

On Linux, we have package managers that only pull in the needed
dependencies. Windows just seems actively hostile to that kind of
infrastructure management. If you meant “you can’t build the simplest
program *on Windows* without involving half of Linux” ... well, that’s
just a reflection on the deficiencies of Windows. On Linux, you already
have the *whole* of Linux to start with.

Bart <bc@freeuk.cm> writes:
> On 31/12/2023 19:37, Bart wrote:
[...]
>> Actually ctags appears to be also part of Windows.
>
> That's not the case, it just happened to be bundled with Windows.

I'd be very surprised if ctags were "bundled with Windows".

On my Windows system, I have a ctags command that's part of OpenWatcom,
which I apparently installed several years ago.

The most common version on Linux-like systems is "exuberant-ctags".
The OpenWatcom version appears to be a different implementation.

There are also versions available via Cygwin and WSL. Perhaps you
wouldn't be interested in those.

I don't know what version you have.

[...]

> How does Vim know where in the file to look? The TAGS files I've
> managed to produce doesn't have that info, and I can't see anything in
> the help to add it.
>
> How do you get it to look inside header files, or do those have to be
> submitted manually?

For the "exuberant" version, you invoke it with the names of the
files you want to index, and the "tags" file includes line numbers.
The OpenWatcom version appears to generate search patterns rather
than line numbers, which makes the tags file more stable as files
are edited. I don't know what version you have.

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

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> This is a CPP question that arose last month. It's not about an
> actual issue with the software, just out of curiosity and to be sure
> it works reliable (it seemingly does).
>
> In a C99 program on Linux (Ubuntu) I intended to use usleep() and
> then also strnlen().
>
> When I added usleep() and its include file I got an error and was
> asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I
> wanted side effects of that tag kept as small as possible I
> prepended it just before the respective #include and put it at the
> end of my #include list
>
> ...other #includes...
> #define _BSD_SOURCE
> #include <unistd.h>
>
> But as got obvious *that* way there had been side-effects and I
> had to put the tag at the beginning of all include files (which
> astonished me)
>
> #define _BSD_SOURCE
> #include <unistd.h>
> ...other #includes here...
>
> For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'.
> So now I have both CPP tag definitions before the includes

I second the recommendations of Lowell Gilbert and others not to
define _BSD_SOURCE or _GNU_SOURCE (especially not _GNU_SOURCE)
but instead seek alternatives, which are readily available for
the two functionalities being sought in this case.

> #define _GNU_SOURCE /* necessary for strnlen() in string.h */
> #define _BSD_SOURCE /* necessary for usleep() in unistd.h */
> ...all #includes here...

For strnlen(), put an inline definition in a header file:

#ifndef HAVE_strnlen_dot_h_header
#define HAVE_strnlen_dot_h_header

#include <stddef.h>

static inline size_t
strnlen( const char *s, size_t n ){
extern void *memchr( const void *, int, size_t );
const char *p = memchr( s, 0, n );
return p ? (size_t){ p-s } : n;
}

#include <string.h>

#endif

Disclaimer: this code has been compiled but not tested.

(If you want you could call this header file "string.h" and do
a #include "string.h". I'm not advocating doing that, just
pointing it out as an alternative. I expect some people like the
idea, and others dislike it, and I don't want to get involved in
a style war.)

For usleep(), define an alternate function usnooze(), to be used
in place of usleep(). In header file usnooze.h:

extern int usnooze( unsigned long long );

In source file usnooze.c:

#ifndef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 199309L
#endif

#include "usnooze.h"

#include <errno.h>
#include <time.h>

int
usnooze( unsigned long long snooze_time_in_microseconds ){
typedef unsigned long long ULL;
typedef struct timespec TS;

ULL seconds = snooze_time_in_microseconds / 1000000;
ULL nanoseconds = snooze_time_in_microseconds % 1000000 * 1000;
TS need = { .tv_sec = seconds, .tv_nsec = nanoseconds };
TS more;
int rc;
unsigned most = 1000;

while( errno = 0, rc = nanosleep( & need, & more ), rc != 0 ){
if( errno != EINTR || most-- == 0 ) return -1;
need = more;
}

return 0;
}

The point of putting the definition of usnooze() in a separate file
is so the needed #define _POSIX_C_SOURCE doesn't contaminate any
more program source than it has to.

On Sun, 31 Dec 2023 13:51:28 -0800, Chris M. Thomasson wrote:

> On 12/31/2023 1:44 PM, Lawrence D'Oliveiro wrote:
>>
>> If you want to see the right way to do macros, look at LISP, where they
>> are token-based, and much more robust as as result. I think they even
>> manage to apply scoping rules to macro definitions as well.
>
> Fwiw, check this out:
>
> [dead project with spam link omitted]

Looks long defunct, which is just as well.

I really did give string-based macros a try. I thought it was just down to
deficiencies in the C/C++ preprocessor. So I did some work with GNU M4,
which is about as powerful a string macro processor as you could want. And
instead of being better, it was just as troublesome and fragile.

The watchword now is “homoiconicity”. This means that the program has an
AST representation in terms of objects in the language itself. LISP has
this very naturally. And all your macro-type manipulations are done on
this intermediate representation, not on the original program source.

I found a way to do it Python, too, which I used for this project
<https://gitlab.com/ldo/seaskirt> to generate both synchronous and
asynchronous versions of the same API classes from common code.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> This is a CPP question that arose last month. It's not about an
>> actual issue with the software, just out of curiosity and to be sure
>> it works reliable (it seemingly does).
>>
>> In a C99 program on Linux (Ubuntu) I intended to use usleep() and
>> then also strnlen().
>>
>> When I added usleep() and its include file I got an error and was
>> asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I
>> wanted side effects of that tag kept as small as possible I
>> prepended it just before the respective #include and put it at the
>> end of my #include list
>>
>> ...other #includes...
>> #define _BSD_SOURCE
>> #include <unistd.h>
>>
>> But as got obvious *that* way there had been side-effects and I
>> had to put the tag at the beginning of all include files (which
>> astonished me)
>>
>> #define _BSD_SOURCE
>> #include <unistd.h>
>> ...other #includes here...
>>
>> For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'.
>> So now I have both CPP tag definitions before the includes
>
> I second the recommendations of Lowell Gilbert and others not to
> define _BSD_SOURCE or _GNU_SOURCE (especially not _GNU_SOURCE)
> but instead seek alternatives, which are readily available for
> the two functionalities being sought in this case.
>
>> #define _GNU_SOURCE /* necessary for strnlen() in string.h */
>> #define _BSD_SOURCE /* necessary for usleep() in unistd.h */
>> ...all #includes here...
>
> For strnlen(), put an inline definition in a header file:
>
> #ifndef HAVE_strnlen_dot_h_header
> #define HAVE_strnlen_dot_h_header
>
> #include <stddef.h>
>
> static inline size_t
> strnlen( const char *s, size_t n ){
> extern void *memchr( const void *, int, size_t );
> const char *p = memchr( s, 0, n );
> return p ? (size_t){ p-s } : n;
> }
>
> #include <string.h>
>
> #endif
>
> Disclaimer: this code has been compiled but not tested.

strnlen() is specified by POSIX. It might make sense to re-implement it
if your code needs to work on a non-POSIX system (that doesn't also
provide it). Why would you want to do so otherwise?

memchr() is declared in <string.h>. Why would you duplicate its
declaration rather than just using `#include <string.h>`?

[...]

> For usleep(), define an alternate function usnooze(), to be used
> in place of usleep(). In header file usnooze.h:
[snip]

If your code doesn't need to be portable to systems that don't provide
usleep(), you can just use usleep(). If it does, its probably better to
modify the code so it uses nanosleep().

[...]

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

On 31/12/2023 23:46, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 02:18:25 +0000, Bart wrote:
>
>> This somes my experience of software originating in Linux. This is why
>> Windows had to acquire CYGWIN then MSYS then WSL. You can't build the
>> simplest program without involving half of Linux.
>
> On Linux, we have package managers that only pull in the needed
> dependencies. Windows just seems actively hostile to that kind of
> infrastructure management. If you meant “you can’t build the simplest
> program *on Windows* without involving half of Linux” ... well, that’s
> just a reflection on the deficiencies of Windows. On Linux, you already
> have the *whole* of Linux to start with.

And developers feel it necessary to USE everything that it provides!

I've never managed to build the GMP library on Windows for example (it
only comes as source code), because it requires that 30,000-line bash
script which in turn needs sed and m4 and all the rest.

Why? It's a numeric library. Why should it be dependent on OS?

Or maybe Linux developers NEED all that hand-holding and have no idea
how to build using a bare compiler. Remember that end-users building
such projects are only doing a one-time build to get a working binary.

I have sometimes made my own non-C projects available on Linux. I did
that by transpiling to a single C source file. All you then need to
build it is a C compiler. It would be almost as easy as building
hello.c, except I suspect some don't even know that, since they are used
to 'make'.

> On Linux, we have package managers that only pull in the needed
> dependencies. Windows just seems actively hostile to that kind of

Yeah, I've seen them in action. Sometimes they work, sometimes not. On a
Raspberry Pi, one 'apt-get install' went on for 90 minutes, then it
crashed. Fortunately by then I'd forgotten what it was that I'd been
trying to do.

It seems peculiar to me that you take what I see as a drawback -
excessive, gratuitous dependencies which also make the build process
more complex and slower - and somehow turn that into an advantage.

So any platform that doesn't include all that pointless crap must be at
fault, rather than the developer who is inflicting those needless
dependencies.

On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote:

> On 31/12/2023 23:46, Lawrence D'Oliveiro wrote:
>>
>> If you meant “you can’t build the simplest
>> program *on Windows* without involving half of Linux” ... well, that’s
>> just a reflection on the deficiencies of Windows. On Linux, you already
>> have the *whole* of Linux to start with.
>
> And developers feel it necessary to USE everything that it provides!

It’s called “code reuse”. A well-designed package-management system just
makes it so much easier to do.

> I've never managed to build the GMP library on Windows for example (it
> only comes as source code), because it requires that 30,000-line bash
> script which in turn needs sed and m4 and all the rest.
>
> Why? It's a numeric library. Why should it be dependent on OS?

Those are just standard file-manipulation tools that any decent OS should
provide.

> Or maybe Linux developers NEED all that hand-holding and have no idea
> how to build using a bare compiler.

If only you could do that on Windows ... but no. Look at all the C runtime
stuff needed just to build a simple “Hello World” program ... because
Windows automatically assumes that every program must have a GUI.

> Remember that end-users building
> such projects are only doing a one-time build to get a working binary.

They find it easier to do “apt-get install”, or a GUI wrapper around same,
like Synaptic.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> This is a CPP question that arose last month. It's not about an
>>> actual issue with the software, just out of curiosity and to be sure
>>> it works reliable (it seemingly does).
>>>
>>> In a C99 program on Linux (Ubuntu) I intended to use usleep() and
>>> then also strnlen().
>>>
>>> When I added usleep() and its include file I got an error and was
>>> asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I
>>> wanted side effects of that tag kept as small as possible I
>>> prepended it just before the respective #include and put it at the
>>> end of my #include list
>>>
>>> ...other #includes...
>>> #define _BSD_SOURCE
>>> #include <unistd.h>
>>>
>>> But as got obvious *that* way there had been side-effects and I
>>> had to put the tag at the beginning of all include files (which
>>> astonished me)
>>>
>>> #define _BSD_SOURCE
>>> #include <unistd.h>
>>> ...other #includes here...
>>>
>>> For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'.
>>> So now I have both CPP tag definitions before the includes
>>
>> I second the recommendations of Lowell Gilbert and others not to
>> define _BSD_SOURCE or _GNU_SOURCE (especially not _GNU_SOURCE)
>> but instead seek alternatives, which are readily available for
>> the two functionalities being sought in this case.
>>
>>> #define _GNU_SOURCE /* necessary for strnlen() in string.h */
>>> #define _BSD_SOURCE /* necessary for usleep() in unistd.h */
>>> ...all #includes here...
>>
>> For strnlen(), put an inline definition in a header file:
>>
>> #ifndef HAVE_strnlen_dot_h_header
>> #define HAVE_strnlen_dot_h_header
>>
>> #include <stddef.h>
>>
>> static inline size_t
>> strnlen( const char *s, size_t n ){
>> extern void *memchr( const void *, int, size_t );
>> const char *p = memchr( s, 0, n );
>> return p ? (size_t){ p-s } : n;
>> }
>>
>> #include <string.h>
>>
>> #endif
>>
>> Disclaimer: this code has been compiled but not tested.
>
> strnlen() is specified by POSIX. It might make sense to
> re-implement it if your code needs to work on a non-POSIX system
> (that doesn't also provide it). Why would you want to do so
> otherwise?

I'm trying to provide a helpful answer to the person I was
responding to, not espouse a philosophical viewpoint. Why do you
feel the need to start a style debate?

> memchr() is declared in <string.h>. Why would you duplicate its
> declaration rather than just using `#include <string.h>`?

I had a specific reason for writing the code the way I did.
It wasn't important to explain that so I didn't.

>> For usleep(), define an alternate function usnooze(), to be used
>> in place of usleep(). In header file usnooze.h:
>
> [snip]
>
> If your code doesn't need to be portable to systems that don't
> provide usleep(), you can just use usleep(). If it does, its
> probably better to modify the code so it uses nanosleep().

Not everyone agrees with that opinion. Again, I'm just trying to
provide an answer helpful to OP, not advance an agenda. Like I
said in the part of my posting that you left out, I don't want to
get involved in a style war. If OP wants to modify his code to
use nanosleep(), I'm fine with that. If want wants to keep using
usleep() or switch to using usnooze(), I'm fine with that too. I
think it's more important in this case to provide options than to
try to change someone's point of view.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>
>> BTW, is 'inline' meanwhile C standard? (I know that from C++ but
>> haven't done much C for long now.)
>
> C added inline in C99 (the 1999 edition of the ISO C standard, the same
> one that removed implicit int).
>
> I think C and C++ have subtly different semantics for inline.

I'm not a C++ expert, but as best I can tell C and C++ have
markedly different semantics for what 'inline' does.

On 2023-12-31, Bart <bc@freeuk.cm> wrote:
> On 31/12/2023 19:37, Bart wrote:
>> Actually ctags appears to be also part of Windows.
>
> That's not the case, it just happened to be bundled with Windows.

What??? By what system vendor?

You probably installed something that pulled in ctags.

Ctags is of no use to the average Windows user, and I can practically
guarantee you Microsoft has zero interest in it.

Microsoft has replaced this sort of thing with the Language Server
Protocol system, which is integrated into Visual Studio Code and all
sots of language compilers and run times. (Speaking of which, even VSS
doesn't come with Windows, to my knowledge.)

> How does Vim know where in the file to look? The TAGS files I've
> managed > to produce doesn't have that info, and I can't see anything
> in the help to add it.

Entries look like this:

addrinfo stdlib/socket.tl /^(defstruct addrinfo nil$/;" s

symbol[Tab]path[Tab]search command

The ;" is the start of a comment. The comment field contains extension
fields. The letter s is being used to indicate that the identifier is
the name of a structure (a Lisp one, in this case).

If the search command is a regex search, that is advantageous; the
tags file remains usable even when file contents are changing.
It's possible to use hard coded line numbers.

In Vim you can type :help tags-file-format to get documentation about
this.

> How do you get it to look inside header files, or do those have to be
> submitted manually?

ctags -R will process a tree recursively, including any C header files.
However, things that are only declared and not defined in header files,
like function declarations, are not indexed.

Emacs uses a different tag format, by the way, which I referred to
as etags, I think.

In the TXR Lisp ctags generator I used some tricks. Look at this
entry; it relates to the above addrinfo. canonname is a slot in
this structure:

canonname stdlib/socket.tl /^(defstruct addrinfo nil$/;/canonname/;" m struct:addrinfo

The search command contains two searches! First it searches for the
defstruct line. Then from that point it searches forward for canonname.

This is very important. That file contains two structures which have
a canonname slot; a sockaddr structure also has one:

canonname stdlib/socket.tl /^(defstruct sockaddr nil$/;/canonname/;" m struct:sockaddr

Vim will give you both choices and let you pick:

:tj canonname
canonname canonname_s
# pri kind tag file
1 F canonname socket.c
?
canonname_s = intern(lit("canonname"), user_package);
2 F m canonname stdlib/socket.tl
struct:sockaddr
(defstruct sockaddr nil$/;/canonname
3 F m canonname stdlib/socket.tl
struct:addrinfo
(defstruct addrinfo nil$/;/canonname

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>
>>>> This is a CPP question that arose last month. It's not about an
>>>> actual issue with the software, just out of curiosity and to be sure
>>>> it works reliable (it seemingly does).
>>>>
>>>> In a C99 program on Linux (Ubuntu) I intended to use usleep() and
>>>> then also strnlen().
>>>>
>>>> When I added usleep() and its include file I got an error and was
>>>> asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I
>>>> wanted side effects of that tag kept as small as possible I
>>>> prepended it just before the respective #include and put it at the
>>>> end of my #include list
>>>>
>>>> ...other #includes...
>>>> #define _BSD_SOURCE
>>>> #include <unistd.h>
>>>>
>>>> But as got obvious *that* way there had been side-effects and I
>>>> had to put the tag at the beginning of all include files (which
>>>> astonished me)
>>>>
>>>> #define _BSD_SOURCE
>>>> #include <unistd.h>
>>>> ...other #includes here...
>>>>
>>>> For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'.
>>>> So now I have both CPP tag definitions before the includes
>>>
>>> I second the recommendations of Lowell Gilbert and others not to
>>> define _BSD_SOURCE or _GNU_SOURCE (especially not _GNU_SOURCE)
>>> but instead seek alternatives, which are readily available for
>>> the two functionalities being sought in this case.
>>>
>>>> #define _GNU_SOURCE /* necessary for strnlen() in string.h */
>>>> #define _BSD_SOURCE /* necessary for usleep() in unistd.h */
>>>> ...all #includes here...
>>>
>>> For strnlen(), put an inline definition in a header file:
>>>
>>> #ifndef HAVE_strnlen_dot_h_header
>>> #define HAVE_strnlen_dot_h_header
>>>
>>> #include <stddef.h>
>>>
>>> static inline size_t
>>> strnlen( const char *s, size_t n ){
>>> extern void *memchr( const void *, int, size_t );
>>> const char *p = memchr( s, 0, n );
>>> return p ? (size_t){ p-s } : n;
>>> }
>>>
>>> #include <string.h>
>>>
>>> #endif
>>>
>>> Disclaimer: this code has been compiled but not tested.
>>
>> strnlen() is specified by POSIX. It might make sense to
>> re-implement it if your code needs to work on a non-POSIX system
>> (that doesn't also provide it). Why would you want to do so
>> otherwise?
>
> I'm trying to provide a helpful answer to the person I was
> responding to, not espouse a philosophical viewpoint. Why do you
> feel the need to start a style debate?

I don't. I simply asked you a question. You've refused to answer
it, and I won't waste my time asking again.

>> memchr() is declared in <string.h>. Why would you duplicate its
>> declaration rather than just using `#include <string.h>`?
>
> I had a specific reason for writing the code the way I did.
> It wasn't important to explain that so I didn't.

Unsurprisingly, you refuse to do so even when asked directly.

>>> For usleep(), define an alternate function usnooze(), to be used
>>> in place of usleep(). In header file usnooze.h:
>>
>> [snip]
>>
>> If your code doesn't need to be portable to systems that don't
>> provide usleep(), you can just use usleep(). If it does, its
>> probably better to modify the code so it uses nanosleep().
>
> Not everyone agrees with that opinion. Again, I'm just trying to
> provide an answer helpful to OP, not advance an agenda. Like I
> said in the part of my posting that you left out, I don't want to
> get involved in a style war. If OP wants to modify his code to
> use nanosleep(), I'm fine with that. If want wants to keep using
> usleep() or switch to using usnooze(), I'm fine with that too. I
> think it's more important in this case to provide options than to
> try to change someone's point of view.

As usual, you vaguely denigrate my opinion without sharing your own.
It's boring.

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