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

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

The compile showed no error messages and the code works fine (it seems).

Now I'm not feeling very comfortable with that; I seem to declare two
different "philosophies" that way, GNU and BSD. And both tags affect
all include files. - Is that okay?

Last time I looked into the system header files, three decades ago, I
got repelled by all the #ifdef's, cascaded and nested, a spaghetti code
of dependencies; I'm astonished it works. - And the responsibility to
keep all the CPP tags consistent with _all_ the header files lies at
the side of the system headers' developers? The programmer doesn't need
to care?

Janis

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

> In a C99 program on Linux (Ubuntu) I intended to use usleep() and then
> also strnlen().

usleep() isn't in C99. It comes from POSIX, where it was declared
obsolete in 2001. [This information is available in "man usleep".]

I don't want to get into checking which version of glibc you're using,
and such details, so in this case I'll just recommend that you follow
POSIX and use nanosleep() instead. You'll need to multiply by a thousand
and reference different include files, but I strongly suspect you can
figure that all out on your own.

With only fabulously rare exceptions (which mostly involve the
programmer knowing more about the implementation of libc than the libc
implementors did), user code should not be defining (or undefining)
_GNU_SOURCE or _BSD_SOURCE. You seem to have had thoughts in that
direction, and you were absolutely right.

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

On 2023-12-26, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> 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)

Feature selection macros must be in effect before any system header
is included, and are usually put on the compiler command line:

cc ... -D_BSD_SOURCE -D_XOPEN_SOURCE=700 ...

The concept of feature selection macros is documented in POSIX.

https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html

I will give you an excellent reason not to put them in source code:
their behavior is system-specific. No single combination of these things
works everywhere. It's best to wrestle that out in the configure
scripts and Makefiles, keeping the code clean.

The header files in BSD Unixes make the wrong interpretation of how
feature selection macros are supposed to work. This affects everything
that is based on BSD or has copy and pasted C libraries from BSD:
Android's Bionic, Cygwin's Newlib, Apple's Darwin environment.

The BSD interpretation of feature selection macros is this:

1. All available identifiers are turned on by default.

2. Feature selection macros *restrict* (subtract) from that set.

3. So do macros coming from the compiler's dialect selection.

Under BSD, if you use, say gcc -ansi -D_POSIX_SOURCE, it will
stupidly produce the intersection of pure ANSI and POSIX.
What you wanted was to use the ANSI C dialect of the language, with
POSIX functions. The BSD interpretation is that ANSI means you don't
want <stdio.h> to give you the declaration of fileno or fdopen,
and so the -D_POSIX_SOURCE won't reveal POSIX things in ANSI/ISO C
headers.

Similarly, if you picked _POSIX_SOURCE and _BSD_SOURCE, you would
stupidly get the intersection of those two, not the union.

In other systems, like GNU/Linuxes, Solaris (I think), you get
the union: -ansi -D_POSIX_SOURCE -D_BSD_SOURCE would work as you
expect: your code is the ANSI dialect, and you want header files
to reveal POSIXisms as well as BSD-isms.

In the Apple environment, forget about it; fine-grained feature
selection is broken: you use -D_DARWIN_C_SOURCE and be done with it.
It's like the old -D_HPUX_SOURCE to get anything compiled on HP-UX.

> #define _GNU_SOURCE /* necessary for strnlen() in string.h */

I think once you define _GNU_SOURCE, Glibc's feature selection will
give you everything. BSD functions in the GNU C library are also
considered GNU extensions over POSIX. It's like the GNU equivalent of
_DARWIN_C_SOURCE or _HPUX_SOURCE; you're asking to reveal everything
from the GNU vendor.

On Glibc, the header /usr/include/features.h is the switch where
the feature selection public macros get converted into combinations of
internal private macros which are then used throughout the headers
to turn things on and off. The features.h header contains a
block comment which lists the public feature selection macros, and
another one that describes the internal ones you're not supposed
to use directly.

You can see that for _GNU_SOURCE, the comment says:

_GNU_SOURCE All of the above, plus GNU extensions.

All of the above refers to all the POSIX, X/Open, BSD stuff
listed above that.

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

On Tue, 26 Dec 2023 22:50:40 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> On 2023-12-26, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> > 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)
>
> Feature selection macros must be in effect before any system header
> is included, and are usually put on the compiler command line:
>
> cc ... -D_BSD_SOURCE -D_XOPEN_SOURCE=700 ...
>
> The concept of feature selection macros is documented in POSIX.
>
> https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html

On Linux there exists also man page feature_test_macros which says : "In
order to be effective, a feature test macro must be defined before including
any header files."

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

On 26.12.2023 16:59, Janis Papanagnou wrote:
> [...]
> 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'. [...]

Thanks for all the replies.

Kaz wrote:
>> Feature selection macros must be in effect before any system header
>> is included, and are usually put on the compiler command line:

Right. This time I came from the functions' man pages and read that
such tags are necessary for them, so I didn't think about the original
purpose of these tags. I forgot that decades ago we used for platform
specific declarations. Thanks for refreshing my neurons.

>> I think once you define _GNU_SOURCE, Glibc's feature selection will
>> give you everything.

Indeed. I removed the one obsolete tag.

Lowell wrote:
>> usleep() isn't in C99. It comes from POSIX, where it was declared
>> obsolete in 2001.

Yes, I read about that. Though here I'm just programming non-portably
for my local (and static, non-changing) environment, so it's not an
issue in practice. Generally I try to program close to standards (but
standards obviously also change, as we see).

>> I'll just recommend that you follow POSIX and use nanosleep()
>> instead.

When I had read about the various 'sleep' options I decided to use one
which supports sub-second resolution and with a most simple interface.
That's why my choice was the simple 'usleep(usec);' even if obsolete
by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
litter my code with variables unnecessary in my context, and also the
advertised "advantages" of this function do not apply in my case.[*]

And thanks for your confirmation that my "thoughts" about "not looking
right to use _GNU_SOURCE and _BSD_SOURCE" was not unjustified.

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

I was indeed pondering about that. But I'm not programming Unix, and
here I came from an application programming question so my choice was
this newsgroup, and I think (and hope) it has not been a bad choice.

I certainly found the experts to get the clarifications, suggestions,
and insights that were helpful.

Janis

[*] To illustrate: I recall a similar decision in Java context. There
was a simple and easy to use rexexp library (from Apache, IIRC). And
there was also a most flexible blown up library that made its usage a
lot more bulky (using and instantiating many classes and dependencies).
I used the simple, user-friendly one. Later the bulky library became
the Java standard.

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

> Lowell wrote:
>>> I'll just recommend that you follow POSIX and use nanosleep()
>>> instead.
>
> When I had read about the various 'sleep' options I decided to use one
> which supports sub-second resolution and with a most simple interface.
> That's why my choice was the simple 'usleep(usec);' even if obsolete
> by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
> litter my code with variables unnecessary in my context, and also the
> advertised "advantages" of this function do not apply in my case.[*]

To be honest,I didn't actually understand where your problem came from
in the first place -- I just chose not to bring up more than one point
at a time. While usleep() is obsolete, it works fine, without any
feature test macro games, on (as far as I know) all POSIX-ish
systems. Certainly on recent Ubuntu, the following program compiles and
runs perfectly well without even any warnings with even the most extreme
levels of warning enabled:

#include <stdio.h>
#include <unistd.h>

int main(void)
{ printf("starting\n");
usleep(2500000);
printf("finishing\n");
}

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

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
[...]
> To be honest,I didn't actually understand where your problem came from
> in the first place -- I just chose not to bring up more than one point
> at a time. While usleep() is obsolete, it works fine, without any
> feature test macro games, on (as far as I know) all POSIX-ish
> systems. Certainly on recent Ubuntu, the following program compiles and
> runs perfectly well without even any warnings with even the most extreme
> levels of warning enabled:
>
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void)
> {
> printf("starting\n");
> usleep(2500000);
> printf("finishing\n");
> }

I think the warnings you enabled weren't extreme enough:

$ gcc -std=c11 -c c.c
c.c: In function ‘main’:
c.c:7:4: warning: implicit declaration of function ‘usleep’; did you mean ‘sleep’? [-Wimplicit-function-declaration]
7 | usleep(2500000);
| ^~~~~~
| sleep
$

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

On 2023-12-28, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 26.12.2023 16:59, Janis Papanagnou wrote:
>> [...]
>> 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'. [...]
>
> Thanks for all the replies.
>
>
> Kaz wrote:
>>> Feature selection macros must be in effect before any system header
>>> is included, and are usually put on the compiler command line:
>
> Right. This time I came from the functions' man pages and read that
> such tags are necessary for them, so I didn't think about the original
> purpose of these tags. I forgot that decades ago we used for platform
> specific declarations. Thanks for refreshing my neurons.

I'm a real stickler for not wanting to reveal everything in the headers,
if possible.

So here is the irony. On BSD libraries, you can get BSD symbols with
a dialect option like -ansi or -std=C99 fi you use the secret, internal,
double-leading-underscored feature selector __BSD_VISIBLE. As in:

gcc ... -std=c99 -D__BSD_VISIBLE

The -std=c99 generates certain #defines with BSD takes as a clue to
hide everything not related to C99 from every standard ISO C header.

We then pry that open with __BSD_VISIBLE. If we used -D_BSD_SOURCE,
that wouldn't work.

In the TXR configure script, I have an elaborate test.
(Not shown is the conftest function which compiles conftest.c,
with the assistance of a rule in the Makefile, and reports success):

printf "Detecting what symbol reveals BSD functions ... "

cat > conftest.c <<!
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char **argv)
{ int (*pdaemon)(int, int) = &daemon;
} !

if conftest ; then
printf "none needed\n"
else
for flag in _DEFAULT_SOURCE _BSD_SOURCE __BSD_VISIBLE _GNU_SOURCE _X_OOPS; do
if [ $flag = _X_OOPS ] ; then
printf "failed\n"
break
fi

if conftest EXTRA_FLAGS=-D$flag ; then
printf "%s\n" $flag
lang_flags="$lang_flags -D$flag"
gen_config_make
break
fi
done
fi

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

On 2023-12-28, Lowell Gilbert <lgusenet@be-well.ilk.org> wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> Lowell wrote:
>>>> I'll just recommend that you follow POSIX and use nanosleep()
>>>> instead.
>>
>> When I had read about the various 'sleep' options I decided to use one
>> which supports sub-second resolution and with a most simple interface.
>> That's why my choice was the simple 'usleep(usec);' even if obsolete
>> by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
>> litter my code with variables unnecessary in my context, and also the
>> advertised "advantages" of this function do not apply in my case.[*]
>
> To be honest,I didn't actually understand where your problem came from
> in the first place -- I just chose not to bring up more than one point
> at a time. While usleep() is obsolete, it works fine, without any
> feature test macro games, on (as far as I know) all POSIX-ish
> systems. Certainly on recent Ubuntu, the following program compiles and
> runs perfectly well without even any warnings with even the most extreme
> levels of warning enabled:
>
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void)
> {
> printf("starting\n");
> usleep(2500000);
> printf("finishing\n");
> }

But if you don't specify any options, you're not even specifying the C
dialect. You will get whatever dialect your gcc installation defaults
to. That is always a GNU dialect, firstly, which you might not want.
Secondly, it's a moving target; it' used to be gnu89, then gnu99
then gnu11. Now GCC defaults to gnu17.

Once you specify the dialect, things get strict.

$ gcc usleep.c

Nothing

$ gcc -std=c99 usleep.c
usleep.c: In function ‘main’:
usleep.c:7:4: warning: implicit declaration of function ‘usleep’; did
you mean ‘sleep’? [-Wimplicit-function-declaration]
usleep(2500000);
^~~~~~
sleep

Oops! Once we use any feature selection macro (or compiler option that
generates #defines that serve as feature selection macros) the set of
what is visible is reduced to some minimal set, and from then, the
feature macros turn on the selected symbols.

Thus <unistd.h> reveals only some fairly old POSIX functions.
Maybe not even up to 2003? The details depend on the behavior of the C
library, like Glibc's <features.h>.

The GNU-documented preferred way to coax usleep out of <unistd.h>
under this condition is this:

$ gcc -std=c99 -D_DEFAULT_SOURCE usleep.c

The _DEFAULT_SOURCE feature selection symbol brings out some traditional
functions (or something like that) without bringing in all the full
blown extensions of _GNU_SOURCE.

The BSD people misunderstood this whole thing. Without feature
selections, they reveal everything. But the semantics of a feature
selection is "hide everything except this". They neglected to implement
the correct logic: "if at least one feature selection is present, hide
everything except for some minimal base, and then for every feature
selection, make those respective symbols visible."

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

On 2023-12-28, Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> Once you specify the dialect, things get strict.
>
> $ gcc usleep.c
>
> Nothing
>
> $ gcc -std=c99 usleep.c
> usleep.c: In function ‘main’:
> usleep.c:7:4: warning: implicit declaration of function ‘usleep’; did
> you mean ‘sleep’? [-Wimplicit-function-declaration]
> usleep(2500000);
> ^~~~~~
> sleep

For completeness:

No warning with -Wall without a dialect selection: declaration of usleep
is not hidden in <unistd.h>:

$ gcc -Wall usleep.c

No warning with C89. But that's because GCC doesn't warn about implicit
declarations when in C89 mode:

$ gcc -std=c89 usleep.c

Put in -Wall and we see that usleep is hidden in <unistd.h>

$ gcc -std=c89 -Wall usleep.c
usleep.c: In function ‘main’:
usleep.c:7:4: warning: implicit declaration of function ‘usleep’

On 2023-12-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> [...]
>> To be honest,I didn't actually understand where your problem came from
>> in the first place -- I just chose not to bring up more than one point
>> at a time. While usleep() is obsolete, it works fine, without any
>> feature test macro games, on (as far as I know) all POSIX-ish
>> systems. Certainly on recent Ubuntu, the following program compiles and
>> runs perfectly well without even any warnings with even the most extreme
>> levels of warning enabled:
>>
>> #include <stdio.h>
>> #include <unistd.h>
>>
>> int main(void)
>> {
>> printf("starting\n");
>> usleep(2500000);
>> printf("finishing\n");
>> }
>
> I think the warnings you enabled weren't extreme enough:
>
> $ gcc -std=c11 -c c.c
> c.c: In function ‘main’:
> c.c:7:4: warning: implicit declaration of function ‘usleep’; did you mean ‘sleep’? [-Wimplicit-function-declaration]
> 7 | usleep(2500000);
> | ^~~~~~
> | sleep
> $

What's actually happening is that -std=c11 causes <unistd.h> to hide
the usleep declaration. (Even tough <unistd.h> isn't in ISO C).

If you just use:

gcc -Wimplicit-function-declaration -c c.c

it will not warn. Since no feature selection has been made, all symbols
in headers are maximally visible.

Unless you're using an old GCC whose default dialect is gnu89,
the -Wimplicit-functiond-declaration option is already present in
the default dialect (like gnu99, gnu11 or gnu17).

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> On 2023-12-28, Lowell Gilbert <lgusenet@be-well.ilk.org> wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> Lowell wrote:
>>>>> I'll just recommend that you follow POSIX and use nanosleep()
>>>>> instead.
>>>
>>> When I had read about the various 'sleep' options I decided to use one
>>> which supports sub-second resolution and with a most simple interface.
>>> That's why my choice was the simple 'usleep(usec);' even if obsolete
>>> by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
>>> litter my code with variables unnecessary in my context, and also the
>>> advertised "advantages" of this function do not apply in my case.[*]
>>
>> To be honest,I didn't actually understand where your problem came from
>> in the first place -- I just chose not to bring up more than one point
>> at a time. While usleep() is obsolete, it works fine, without any
>> feature test macro games, on (as far as I know) all POSIX-ish
>> systems. Certainly on recent Ubuntu, the following program compiles and
>> runs perfectly well without even any warnings with even the most extreme
>> levels of warning enabled:
>>
>> #include <stdio.h>
>> #include <unistd.h>
>>
>> int main(void)
>> {
>> printf("starting\n");
>> usleep(2500000);
>> printf("finishing\n");
>> }
>
> But if you don't specify any options, you're not even specifying the C
> dialect. You will get whatever dialect your gcc installation defaults
> to. That is always a GNU dialect, firstly, which you might not want.
> Secondly, it's a moving target; it' used to be gnu89, then gnu99
> then gnu11. Now GCC defaults to gnu17.
>
> Once you specify the dialect, things get strict.

Yes, that's true. I was making an educated guess that the original poster
wasn't actually asking for strict C99, despite referring to a "C99 program." I
think the statement that "I'm just programming non-portably for my local (and
static, non-changing) environment" is strong evidence for this. The discussion
had clearly gone beyond standard C before that, usleep() has never been part
of the actual language.

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2023-12-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
>> [...]
>>> To be honest,I didn't actually understand where your problem came from
>>> in the first place -- I just chose not to bring up more than one point
>>> at a time. While usleep() is obsolete, it works fine, without any
>>> feature test macro games, on (as far as I know) all POSIX-ish
>>> systems. Certainly on recent Ubuntu, the following program compiles and
>>> runs perfectly well without even any warnings with even the most extreme
>>> levels of warning enabled:
>>>
>>> #include <stdio.h>
>>> #include <unistd.h>
>>>
>>> int main(void)
>>> {
>>> printf("starting\n");
>>> usleep(2500000);
>>> printf("finishing\n");
>>> }
>>
>> I think the warnings you enabled weren't extreme enough:
>>
>> $ gcc -std=c11 -c c.c
>> c.c: In function ‘main’:
>> c.c:7:4: warning: implicit declaration of function ‘usleep’; did you mean ‘sleep’? [-Wimplicit-function-declaration]
>> 7 | usleep(2500000);
>> | ^~~~~~
>> | sleep
>> $
>
> What's actually happening is that -std=c11 causes <unistd.h> to hide
> the usleep declaration. (Even tough <unistd.h> isn't in ISO C).

That's an interesting choice. Just including <unistd.h> has undefined
behavior as far as ISO C is concerned, but gcc never (?) warns about
that regardless of the options.

In glibc on Ubuntu 22.04, the declaration of usleep() in <unistd.h>
is protected by:

#if (defined __USE_XOPEN_EXTENDED && !defined __USE_XOPEN2K8) \
|| defined __USE_MISC

IMHO it would have been better if standards that extend the C library
declared all additional declarations in non-standard headers like
<unistd.h> rather than adding them to ISO C standard headers like
<stdio.h> and <stdlib.h>. But a lot of the stuff that POSIX adds
probably predates ISO C90, so there was never a good opportunity to make
a clean split.

[...]

--
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 Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote:

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

It has always been thus
<https://manpages.debian.org/7/feature_test_macros.en.html>:

NOTE: In order to be effective, a feature test macro must be defined
before including any header files.

> Last time I looked into the system header files, three decades ago, I
> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code
> of dependencies; I'm astonished it works.

The whole concept of include files and string-based macro processing is
flawed. But that’s C for you ...

On 29/12/2023 02:35, Lawrence D'Oliveiro wrote:
> On Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote:
>
>> 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)
>
> It has always been thus
> <https://manpages.debian.org/7/feature_test_macros.en.html>:
>
> NOTE: In order to be effective, a feature test macro must be defined
> before including any header files.
>
>> Last time I looked into the system header files, three decades ago, I
>> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code
>> of dependencies; I'm astonished it works.
>
> The whole concept of include files and string-based macro processing is
> flawed. But that’s C for you ...

It's not just C's fault. It's the insistence of having have just ONE
system header that has to work for as many platforms and versions as
possible.

Then that is just added to over the years to include to result in the
patched-together mess that you see that is utterly unreadable. You can't
simplify it it take things out because something could break. It is fragile.

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.

If someone is maintaining compilers that need to work across a range of
targets, then they can have a process that synthesises the header needed
for a specific configuration.

(I guess this is something that is harder on Linux because there, many
standard headers are not part of a specific C compiler, but are a
resource shared by all C compilers, or tools that need to process C
headers.)

On 29/12/2023 14:31, Bart wrote:
> On 29/12/2023 02:35, Lawrence D'Oliveiro wrote:
> > On Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote:
> >
> >> 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)
> >
> > It has always been thus
> > <https://manpages.debian.org/7/feature_test_macros.en.html>:
> >
> >      NOTE: In order to be effective, a feature test macro must be
> defined
> >      before including any header files.
> >
> >> Last time I looked into the system header files, three decades ago, I
> >> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code
> >> of dependencies; I'm astonished it works.
> >
> > The whole concept of include files and string-based macro processing is
> > flawed. But that’s C for you ...
>
> It's not just C's fault. It's the insistence of having have just ONE
> system header that has to work for as many platforms and versions as
> possible.
>
> Then that is just added to over the years to include to result in the
> patched-together mess that you see that is utterly unreadable. You can't
> simplify it it take things out because something could break. It is
> fragile.
>
> 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.
>

This kind of dilemma turns up all the time in development. You
regularly have multiple variations of projects or code, where most
things are the same but there are a few important differences scattered
around. If you choose to have separate code bases, you have to
duplicate work for new features or bug fixes. If you choose to combine
them, you risk a mess of compile-time conditionals, or run-time
conditionals that complicate the code and make it less efficient. The
first method is a pain for people maintaining the general code, while
the second method is a pain for people only interested in one variation.
Sometimes it is possible to have a clean separation between common
parts and variant-specific parts, other times that just makes things
even more complicated.

There is no good answer here, and often you are stuck with decisions
that made sense when they were made, but are no longer the best choice
as the project has grown and developed. And yet at no point is it
feasible to throw things out and start again.

I agree it is not just C's fault - it is, I think, inevitable for any
long-lived large project that is used in many ways. And it is always
going to be a pain for some people, no matter what is done.

At least for things like glibc the great majority of people using it for
their development can ignore the mess and read the documentation instead
of looking into the header files. And most of those that /do/ need to
look in the headers, only need to do so occasionally.

A useful tool that someone might like to write for this particular
situation would be a partial C preprocessor, letting you choose what
gets handled. You could choose to expand the code here for, say,
_GNU_SOURCE and _BSD_SOURCE - any use of these in #ifdef's and
conditional compilation would be expanded according to whether you have
defined the symbols or not, leaving an output that is easier to
understand while keeping most of the pre-processor stuff unchanged (so
not affecting #includes, and leaving #define'd macros and constants
untouched and therefore more readable).

On 28.12.2023 20:11, Lowell Gilbert wrote:
>
> To be honest,I didn't actually understand where your problem came from
> in the first place -- I just chose not to bring up more than one point
> at a time. While usleep() is obsolete, it works fine, without any
> feature test macro games, on (as far as I know) all POSIX-ish
> systems. Certainly on recent Ubuntu, the following program compiles and
> runs perfectly well without even any warnings with even the most extreme
> levels of warning enabled:
> [snip code]

Here's the output of the compiler call with #define _GNU_SOURCE removed

$ cc -std=c99 -o warn warn.c
warn.c: In function ‘delay_time’:
warn.c:368:3: warning: implicit declaration of function ‘strnlen’
[-Wimplicit-function-declaration]
warn.c: In function ‘main’:
warn.c:579:5: warning: implicit declaration of function ‘usleep’
[-Wimplicit-function-declaration]

It compiles, but if I see warnings I nonetheless try to get rid of them.

$ cc --version
cc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

(It's no "recent Ubuntu", I'm sure.)

Janis

On 29.12.2023 00:04, Lowell Gilbert wrote:
>
> Yes, that's true. I was making an educated guess that the original poster
> wasn't actually asking for strict C99, despite referring to a "C99 program."

I switched (from the default cc setting) to -std=c99 since when a
compile run said that my program needs C99 to run. That was the
whole reason for it. And I mentioned it in my post since I thought
it would be relevant context information to answer the question.

Janis

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

>>> I'll just recommend that you follow POSIX and use nanosleep()
>>> instead.
>
>When I had read about the various 'sleep' options I decided to use one
>which supports sub-second resolution and with a most simple interface.
>That's why my choice was the simple 'usleep(usec);' even if obsolete
>by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
>litter my code with variables unnecessary in my context, and also the
>advertised "advantages" of this function do not apply in my case.[*]

You can always define your own usleep:

inline int
usleep(useconds_t microseconds)
{ struct timespec ts;
ts.tv_sec = microseconds / (useconds_t)1000000;
ts.tv_nsec = (long)(microseconds % (useconds_t)1000000) * 1000L;
return nanosleep(&ts, NULL);
}

On 29.12.2023 16:52, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>>>> I'll just recommend that you follow POSIX and use nanosleep()
>>>> instead.
>>
>> When I had read about the various 'sleep' options I decided to use one
>> which supports sub-second resolution and with a most simple interface.
>> That's why my choice was the simple 'usleep(usec);' even if obsolete
>> by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
>> litter my code with variables unnecessary in my context, and also the
>> advertised "advantages" of this function do not apply in my case.[*]
>
> You can always define your own usleep:

LOL, yes. :-)

I usually want to take what's already there and not re-implement
every function. What I mean is; in my case I use a function call
and that is it.

>
> inline int
> usleep(useconds_t microseconds)
> {
> struct timespec ts;
> ts.tv_sec = microseconds / (useconds_t)1000000;
> ts.tv_nsec = (long)(microseconds % (useconds_t)1000000) * 1000L;
> return nanosleep(&ts, NULL);
> }
>

Lowell Gilbert upthread already suggested to use nanosleep() and
do the multiplications, and he was confident, rightly, that I'm
able to "figure that out". :-)

BTW, is 'inline' meanwhile C standard? (I know that from C++ but
haven't done much C for long now.)

Janis

On 12/29/23 8:31 AM, Bart wrote:
> On 29/12/2023 02:35, Lawrence D'Oliveiro wrote:
> > On Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote:
> >
> >> 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)
> >
> > It has always been thus
> > <https://manpages.debian.org/7/feature_test_macros.en.html>:
> >
> >      NOTE: In order to be effective, a feature test macro must be
> defined
> >      before including any header files.
> >
> >> Last time I looked into the system header files, three decades ago, I
> >> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code
> >> of dependencies; I'm astonished it works.
> >
> > The whole concept of include files and string-based macro processing is
> > flawed. But that’s C for you ...
>
> It's not just C's fault. It's the insistence of having have just ONE
> system header that has to work for as many platforms and versions as
> possible.
>
> Then that is just added to over the years to include to result in the
> patched-together mess that you see that is utterly unreadable. You can't
> simplify it it take things out because something could break. It is
> fragile.
>
> 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.
>
> If someone is maintaining compilers that need to work across a range of
> targets, then they can have a process that synthesises the header needed
> for a specific configuration.
>
> (I guess this is something that is harder on Linux because there, many
> standard headers are not part of a specific C compiler, but are a
> resource shared by all C compilers, or tools that need to process C
> headers.)
>
>

And using #if in the headers is one way to "have a process" that
"synthesises the header needed for a specific configuration", without
needing some special code in the compiler, and still makes the header
available to the user for inspection.

I suppose the alternative is a separate include hierarchy for EVERY
combination of configurations, and needing to modify multiple headers to
add/fix features.

On 2023-12-29, Bart <bc@freeuk.cm> wrote:
> On 29/12/2023 02:35, Lawrence D'Oliveiro wrote:
> > On Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote:
> >
> >> 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)
> >
> > It has always been thus
> > <https://manpages.debian.org/7/feature_test_macros.en.html>:
> >
> > NOTE: In order to be effective, a feature test macro must be defined
> > before including any header files.
> >
> >> Last time I looked into the system header files, three decades ago, I
> >> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code
> >> of dependencies; I'm astonished it works.
> >
> > The whole concept of include files and string-based macro processing is
> > flawed. But that’s C for you ...
>
> It's not just C's fault. It's the insistence of having have just ONE
> system header that has to work for as many platforms and versions as
> possible.

Umm, no; system headers are largely system-specific.
>
> Then that is just added to over the years to include to result in the
> patched-together mess that you see that is utterly unreadable. You can't
> simplify it it take things out because something could break. It is fragile.

The preprocessing selection in system headers is for the different
expectations of programs which target different versions of the system
interfaces.

It is to prevent clashes. If an identifier like usleep is hidden,
it means that the program can use it without triggering a redefinition
or other error.

When you compile with, say, -std=c99 (and no other feature selection)
and include <stdio.h>, that header must not declare fdopen or fileno,
which are POSIX extensions. That matters if your program happens to
use these identifiers: which an ISO C program is entitled to do.

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

That's predominantly the case, other than (obviously) for libraries
that are intended to be widely portable.
>
> If someone is maintaining compilers that need to work across a range of
> targets, then they can have a process that synthesises the header needed
> for a specific configuration.

In fact, I remember from long ago that GCC used to have a script,
as part of its build, that would scan the platform's native headers and
generate sanitized versions for GCC. Not sure if that is the case any
more.

> (I guess this is something that is harder on Linux because there, many
> standard headers are not part of a specific C compiler, but are a
> resource shared by all C compilers, or tools that need to process C
> headers.)

Headers on GNU/Linux systems tend to assume GCC. Clang would not be
usable did it not have GCC compatibility.

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

On 2023-12-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 28.12.2023 20:11, Lowell Gilbert wrote:
>>
>> To be honest,I didn't actually understand where your problem came from
>> in the first place -- I just chose not to bring up more than one point
>> at a time. While usleep() is obsolete, it works fine, without any
>> feature test macro games, on (as far as I know) all POSIX-ish
>> systems. Certainly on recent Ubuntu, the following program compiles and
>> runs perfectly well without even any warnings with even the most extreme
>> levels of warning enabled:
>> [snip code]
>
> Here's the output of the compiler call with #define _GNU_SOURCE removed
>
> $ cc -std=c99 -o warn warn.c
> warn.c: In function ‘delay_time’:
> warn.c:368:3: warning: implicit declaration of function ‘strnlen’
> [-Wimplicit-function-declaration]
> warn.c: In function ‘main’:
> warn.c:579:5: warning: implicit declaration of function ‘usleep’
> [-Wimplicit-function-declaration]
>
> It compiles, but if I see warnings I nonetheless try to get rid of them.

This is a good plan because the implicit declaration of a function
is only a guess, which can easily be wrong. The return type is
guessed to be int (wrong for strnlen which has size_t). The number
of arguments and their types are guessed from the call, and could
be wrong. E.g. if sin is not declared then sin(0) implicity declares
it as int (int). Implicit declaration has been dropped from ISO C;
for a number of decades, it was there in support of K&R C programs.
Compiler vendors can support it as long as they like, but a diagnostic
is now required when an undeclared function is used.

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

In article <iXBjN.109557$p%Mb.36381@fx15.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
....
>You can always define your own usleep:
>
>inline int
>usleep(useconds_t microseconds)
> { etc... }

Or just:

int usleep(useconds_t microseconds);

The semicolon at the end is the key.
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Pedantic

David Brown <david.brown@hesbynett.no> writes:
> A useful tool that someone might like to write for this particular
> situation would be a partial C preprocessor, letting you choose what
> gets handled. You could choose to expand the code here for, say,
> _GNU_SOURCE and _BSD_SOURCE - any use of these in #ifdef's and
> conditional compilation would be expanded according to whether you
> have defined the symbols or not, leaving an output that is easier to
> understand while keeping most of the pre-processor stuff unchanged (so
> not affecting #includes, and leaving #define'd macros and constants
> untouched and therefore more readable).

The unifdef tool does some of this. (I haven't used it much.)

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