On 1/20/24 23:46, Kaz Kylheku wrote:
> On 2024-01-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
....
>> named is part of the implementation, or it isn't. If the named
>> header is part of the implementation, then it constitutes a
>> language extension, and so it must be documented (and defined).
>
> The problem with this reasoning is
> 1. Implementations in fact have internal headers that are not
> documented, and which are not supposed to be included directly. You
> will not get documentation for every single header that
> is accessible via #include, and it is not reasonable for ISO C to
> require it. I don't see where it does.

"An implementation shall be accompanied by a document that defines all
implementation-defined and locale-specific characteristics and all
extensions." 4p9

Initially, I accidentally sent my response as private e-mail to Kaz
rather than to the group. With his permission, here's the response he sent:

On 1/21/24 01:37, Kaz Kylheku wrote:
> On 2024-01-20 21:50, James Kuyper wrote:
>> "An implementation shall be accompanied by a document that defines all
>> implementation-defined and locale-specific characteristics and all
>> extensions." 4p9
> That sentence says something subtly different from something like
> "an implementation shall document everything that looks stable enough
> to be an extension".
>
> It is saying that there is required to be a document, and that in
> that document there may be a list of one or more extensions.
>
> The standard is defining the *fact* that this list is exhaustive:
> it comprises all the extensions that are offered in the contract
> between implementor and programmer.
>
> Thus, for instance, if programmers empirically discover a behavior
> which is not defined by ISO C, and which is not in that list,
> it is not an extension. The standard states that that list has
> all the extensions, and that discovered feature is not on it.
>
> The sentence does not require implementors to document,
> as an extension, every header file that is reachable by an #include
> directive.
The standard doesn't provide a definition for "extension", though it
makes many uses of the term, identifying a variety of things as possible
or common extensions to C. What you're saying is, essentially, that
extensions are defined as such by the fact that they are listed as such
in that document. The biggest problem I have with that is that ISO has a
convention that allows them to say just that - all they would have had
to do is put "extension" in italics in 4p9, and that would identify the
sentence in which it occurs as the definition of the term. They didn't
choose to do so. I concede that they might not have thought of doing so.

However, it seems more reasonable to me that whether or not something is
an extension is not supposed to be up to the implementor to decide.
Instead, anything that is an extension must be listed. This would be an
easier interpretation to defend if there were any explicit definition of
"extension" in the standard.

On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> However, it seems more reasonable to me that whether or not something is
> an extension is not supposed to be up to the implementor to decide.
> Instead, anything that is an extension must be listed. This would be an
> easier interpretation to defend if there were any explicit definition of
> "extension" in the standard.

The implication is that anything that works by accident must be listed
as an extension. If function arguments happen to be evaluated left to
right, with all side effects complete between them, this has to be
listed as an extension. Then in the future when the vendor finds that
inconvenient for further compiler work, they have to take away the
extension.

I don't see how it can not be the implementor's privilege to assert what
is reliable for use and documented, versus what is not.

Unless they have some legal contract with particular customers,
requiring certain things be provided.

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

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

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

I did answer your question. My answer is "I'm trying to provide a
helpful answer to the person I was responding to [...]". I don't
know why you think that wasn't an answer.

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

You need to learn that declining is not refusing. Providing a
more complete explanation would uselessly muddy the waters. You
are completely free to ask any questions you want. You have no
right to demand answers, especially when my judgment is that what
you think of as an answer would be a waste of time. Stop being so
self-centered.

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

I'm not denigrating your opinion. I'm simply pointing out that
it is an opinion, and that other people have different opinions.
I'm not presenting my opinion (even assuming I have one on this
subject, which is not guaranteed), because my purpose in posting
was to provide options to the OP, so they could make a decision
based on /their/ needs and their own opinions. I didn't consider,
or even start to consider, what my own opinions on the question
might be.

I have a general observation. In giving your opinions, often they
include a degree of argument or justification for why the views
expressed are a good idea. I have very little interest in getting
into an argument over personal opinions. If you want to hear more
of my opinions, probably it would help if you could focus on the
opinions more, and on the justifications or arguments less. If
and when I feel like it would be useful to express an opinion,
that does not automatically mean I think it would be useful to
explain it or justify it, or have any interest in doing so. For
me the first step is always understanding what it is the other
person is thinking (and hopefully vice versa); anything past
that is optional, and in most cases not worth pursuing.

On 1/21/24 12:55, Kaz Kylheku wrote:
> On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> However, it seems more reasonable to me that whether or not something is
>> an extension is not supposed to be up to the implementor to decide.
>> Instead, anything that is an extension must be listed. This would be an
>> easier interpretation to defend if there were any explicit definition of
>> "extension" in the standard.
>
> The implication is that anything that works by accident must be listed
> as an extension. If function arguments happen to be evaluated left to
> right, with all side effects complete between them, this has to be
> listed as an extension. Then in the future when the vendor finds that
> inconvenient for further compiler work, they have to take away the
> extension.

No, that's unspecified behavior, if 4p9 were intended to be understood
as mandating documentation of all unspecified behavior, it would make
the category of implementation-defined behavior redundant.

Since extensions are also explicitly prohibited from changing the
behavior of strictly conforming code, I think that in order for
something qualify as an extension, it has to define behavior that the
standard leaves undefined. In a certain sense, every implementation
implicitly defines that behavior - whatever it is that actually happens
when the behavior is undefined is that definition. However, I think an
extension should have to be explicitly activated by some deliberate user
choice, such as a compiler option or by defining the behavior of some
kinds of syntax not allowed by the C standard. That's just IMHO, of
course - in the absence of a explicit definition in the standard, it's
hard to be sure what the committee intended.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/21/24 12:55, Kaz Kylheku wrote:
>
>> On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> However, it seems more reasonable to me that whether or not
>>> something is an extension is not supposed to be up to the
>>> implementor to decide. Instead, anything that is an extension
>>> must be listed. This would be an easier interpretation to defend
>>> if there were any explicit definition of "extension" in the
>>> standard.
>>
>> The implication is that anything that works by accident must be
>> listed as an extension. If function arguments happen to be
>> evaluated left to right, with all side effects complete between
>> them, this has to be listed as an extension. Then in the future
>> when the vendor finds that inconvenient for further compiler work,
>> they have to take away the extension.
>
> No, that's unspecified behavior, if 4p9 were intended to be
> understood as mandating documentation of all unspecified behavior,
> it would make the category of implementation-defined behavior
> redundant.

Quite so.

> Since extensions are also explicitly prohibited from changing the
> behavior of strictly conforming code, I think that in order for
> something qualify as an extension, it has to define behavior that
> the standard leaves undefined.

The essential property of an extension is that it must specify a
language feature or library feature that is not specified in the C
standard. Implementations are free to /define/ undefined behavior
any way they want, and doing so doesn't require an extension; the
point of documenting an extension is to /specify what happens/ in
certain cases, which also means giving a guarantee that what is
documented is what will happen (with the understanding that the
guarantee is only that the implementation will make its best
efforts to do so, because some results are outside of an
implementation's ability to control).

(I note in passing that an odd consequence of how the C standard
uses certain terminology is that "defining" something doesn't stop
it from being "undefined". The term "undefined behavior" is thus
something of a misnomer. But I digress.)

Conversely, an extension can specify a feature that is not, or
might not be, undefined behavior, but still needs to be documented
as an extension. For example

#include <foo.h>

is not undefined behavior, but must be documented as an extension
if the header <foo.h> is part of the implementation, because what
is in the header <foo.h> is not specified in the C standard.
Similarly, a declaration like

typedef __uint128_t U128;

is not necessarily undefined behavior, because implementations are
free to define reserved identifiers any way they wish. But if it's
important that it work, then it must be documented as an extension,
as otherwise an implementation is free to reject it by virtue of
using a language feature not specified in the C standard (which
therefore means the program is not strictly conforming, and so can
be rejected).

> In a certain sense, every
> implementation implicitly defines that behavior - whatever it is
> that actually happens when the behavior is undefined is that
> definition. However, I think an extension should have to be
> explicitly activated by some deliberate user choice, such as a
> compiler option or by defining the behavior of some kinds of
> syntax not allowed by the C standard. That's just IMHO, of course
> - in the absence of a explicit definition in the standard, it's
> hard to be sure what the committee intended.

That's a QOI issue. I'm not convinced that it's a good idea in
all cases. For example, either of the two cases mentioned above:

#include <foo.h>

typedef __uint128_t U128;

do not IMO need an explicit user action to activate, because it's
obvious they are making use of extensions, and are pretty unlikely
to occur by accident. I concede however that other people may
reasonably hold other views on that question.

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

> On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> However, it seems more reasonable to me that whether or not something is
>> an extension is not supposed to be up to the implementor to decide.
>> Instead, anything that is an extension must be listed. This would be an
>> easier interpretation to defend if there were any explicit definition of
>> "extension" in the standard.
>
> The implication is that anything that works by accident must be
> listed as an extension. If function arguments happen to be
> evaluated left to right, with all side effects complete between
> them, this has to be listed as an extension. Then in the future
> when the vendor finds that inconvenient for further compiler work,
> they have to take away the extension.
>
> I don't see how it can not be the implementor's privilege to
> assert what is reliable for use and documented, versus what is
> not.

It's important to understand what constitutes an extension. And
there are different kinds of extensions.

If an implementation chooses, say, to evaluate function arguments
always left-to-right, that is perfectly okay (and need not be an
extension). But if an there is to be a /guarantee/ that function
arguments will always be evaluated left-to-right, that means
providing a guarantee that the C standard does not; thus we have an
extension (to the requirements in the C standard), and the extension
must be documented. This case is one kind of extension.

If an implementation chooses to alter the semantics of, for example,
an extern declaration inside a function body, so that the declared
identifier has file scope rather than block scope, that is a
different kind of extension. At the point of the extern declaration
we can't actually detect any difference. A subsequent use, however,
outside the function body, would normally be a constraint violation
and so require a diagnostic, but under the altered semantics the
identifier has already been declared and so no diagnostic is needed.
(Note that this behavior is one of the cases listed in Annex J.5,
"Common extensions".) This example illustrates a second kind of
extension, and they always must be documented as such.

If an implementation chooses to define, for example, __uint128_t to
be the name of an integer type, that represents a third kind of
extension. (Annex J.5 also mentions such definitions as an example
on its list of "Common extensions".) Such cases must be documented
as extensions because, one, the expected default is that there be no
definition (which normally would cause a diagnostic because of some
constraint violation), and two, only the implementation is in a
position to know if the symbol in question was defined by the
implementation or by something else. Clearly any definition the
implementation provides signals a change from the expected default,
which by any reasonable definition of the word constitutes an
extension, and hence must be documented.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
> It's important to understand what constitutes an extension. And
> there are different kinds of extensions.
>
> If an implementation chooses, say, to evaluate function arguments
> always left-to-right, that is perfectly okay (and need not be an
> extension). But if an there is to be a /guarantee/ that function
> arguments will always be evaluated left-to-right, that means
> providing a guarantee that the C standard does not; thus we have an
> extension (to the requirements in the C standard), and the extension
> must be documented. This case is one kind of extension.

If an implementation chooses to guarantee left-to-right evaluation, I
don't see anything in the standard that requires that guarantee to be
documented. (Of course it can and should be.)

It's not entirely clear to me exactly what must or must not be
considered to be an "extension" as the C standard uses the term. The
standard doesn't show the word "extension" in italics or provide a
definition in section 3.

Unless your point is that it's not a guarantee unless it's documented?
But I don't see that that documentation is required *by the standard*.

[...]

> If an implementation chooses to define, for example, __uint128_t to
> be the name of an integer type, that represents a third kind of
> extension. (Annex J.5 also mentions such definitions as an example
> on its list of "Common extensions".) Such cases must be documented
> as extensions because, one, the expected default is that there be no
> definition (which normally would cause a diagnostic because of some
> constraint violation), and two, only the implementation is in a
> position to know if the symbol in question was defined by the
> implementation or by something else. Clearly any definition the
> implementation provides signals a change from the expected default,
> which by any reasonable definition of the word constitutes an
> extension, and hence must be documented.

Again, that can and should be documented, but since any use of the
identifer __uint128_t has undefined behavior, I don't see any
requirement in the standard that it must be documented.

(Aside: gcc has an extension adding __int128 as a keyword, supporting
types "__int128" and "unsigned __int128", but only on some target
systems. These do not qualify as extended integer types. I understand
that "__uint128_t" was a hypothetical example.)

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

On 31/01/2024 22:41, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> It's important to understand what constitutes an extension. And
>> there are different kinds of extensions.
>>
>> If an implementation chooses, say, to evaluate function arguments
>> always left-to-right, that is perfectly okay (and need not be an
>> extension). But if an there is to be a /guarantee/ that function
>> arguments will always be evaluated left-to-right, that means
>> providing a guarantee that the C standard does not; thus we have an
>> extension (to the requirements in the C standard), and the extension
>> must be documented. This case is one kind of extension.
>
> If an implementation chooses to guarantee left-to-right evaluation, I
> don't see anything in the standard that requires that guarantee to be
> documented. (Of course it can and should be.)
>

I would say that a "guarantee" is a promise - in this case, from the
compiler writers to compiler users. It's not a guarantee if they don't
tell anyone! Then it's just an implementation detail. But I don't see
that it has to be documented in any particular way, or called an
"extension". IIRC MSVC's "guarantee" that it won't use type-based alias
analysis for optimisation (and thus casting between pointer types will
work as some people think they should work) is "documented" in a blog
post by one of the compiler developers.

Of course it is up to the user to decide how much they trust the
guaranteed additional behaviour. A mailing list post with "We'll
evaluate left to right, or your money back!" or a note in a blog page
would probably not inspire as much confidence as clear information in
the main reference documentation for a compiler.

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

> On 2024-01-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> [...] Just including <unistd.h> has undefined behavior as far as
>>> ISO C is concerned, [...]
>>
>> Not true. The behavior of #include <unistd.h> is defined in
>> section 6.10.2 p2. One of two things is true: either the header
>> named is part of the implementation, or it isn't. If the named
>> header is part of the implementation, then it constitutes a
>> language extension, and so it must be documented (and defined).
>
> The problem with this reasoning is
>
> 1. Implementations in fact have internal headers that are not
> documented, and which are not supposed to be included directly.
> You will not get documentation for every single header that
> is accessible via #include, and it is not reasonable for ISO C to
> require it. I don't see where it does.

First, James Kuyper already identified section 4 paragraph 9.

Second, implementations do have lots of internal headers that are
not meant to be included directly, but just because such headers
exist doesn't mean they can be #include'd. Consider these lines
at the start of <bits/byteswap.h>

#if !defined _BYTESWAP_H && !defined _NETINET_IN_H && !defined _ENDIAN_H
# error "Never use <bits/byteswap.h> directly; include <byteswap.h> instead."
#endif

Clearly implementations can and do distinguish between headers
that are meant to be user #include-able and those that are not,
and take steps to protect the hidden ones. It seems obvious
that implementations consider it reasonable to document headers
that are meant to be user #include-able, and to protect the
hidden headers so they can't be #included directly, because
that is what existing implementations do.

> 2. A documented extension continues to be undefined behavior.
> The behavior is "defined", but not "ISO C defined". So even
> if all the implementation's internal headers were documented
> as extensions, their use would still be UB.
>
> Undefined behavior is for which "this document imposes not
> requirements", right?
>
> It is not behavior for which "this document, together with the
> ocumentation accompanying a given implementation, imposes
> no requirements". Just "this document" (and no other).
>
> If "this document" imposes no requirements, it's "undefined
> behavior", no matter who or what imposes additional requirements!

Your logic here is all messed up. The very first sentence uses
circular reasoning. Next you ignore the point that the "define" in
section 4 paragraph 9 is a Standard-imposed requirement, and surely
the Standard means to require that implementations obey their own
definitions, because that's what "define" means. The idea that
having to document extensions doesn't imply an ISO C requirement is
just being obtuse.

Perhaps a more fundamental flaw is you have the key implication
backwards. IF using a particular program construct or data value
has been identified as undefined behavior, THEN the C standard
imposes no requirements on those uses. The implication doesn't go
the other way. For example, the C standard imposes no requirements
for what happens on Tuesdays. That does not mean that compiling a
program on a Tuesday is undefined behavior. The universe of
discourse is program constructs and data values ("values" here also
includes things such as trap representations). Saying "an unknown
header is undefined behavior" is meaningless, because it's outside
the universe of discourse, just like Tuesdays are. The C construct
in question is "#include <unistd.h>", and the C standard defines
behavior for that construct.

> Intuitively, a header which is part of an implementation can do
> anything. For instance #include <pascal.h> can cause the rest of
> the translation unit to be analyzed as Pascal syntax, and not C.
>
> An implementation can provide a header <reboot.h>, including
> which causes a reboot at compile time, link time, or
> execution time.
>
> If such headers happen to exist, what in the standard is violated?

More bad logic. Of course the contents of a header or #include'd
file can have, for example, syntax errors, that result in crossing
the line into undefined behavior. The question is not whether an
unknown header /can/ cross the line into undefined behavior but
whether it /must/ cross that line. Whether a #include of an unknown
header encounters undefined behavior depends on the contents of the
header, and nothing else. A #include <unistd.h> MIGHT cross the
line into UB land, but there is nothing that says it MUST cross that
line.

Note by the way that exactly the same reasoning applies to an
unknown source file, such as #include "foo.h". If we don't know
what's in foo.h (maybe it was left by a hacker in a little-used
byway of where the implementation looks for #include'd source
files), then undefined behavior is possible, but whether UB
actually happens depends only on the contents of the file, not on
whether we know what's in it.

> I used to experience a lot of push-back against the above views,
> but I'm seeing that people are coming around.

I expect that is simply a consequence of your dogged persistence
and the brighter people dropping out of the conversations. It's
not whether some people start to be convinced, but rather which
people are convinced, and how firmly convinced, and why.

On Thu, 18 Jan 2024 19:40:44 -0000 (UTC), Kaz Kylheku
<433-929-6894@kylheku.com> wrote:

> On 2024-01-18, bart <bc@freeuk.com> wrote:

> > All I know about PowerShell is that instead of typing 'prog' to run the
> > 'prog.exe' you've just created, you have to do '.\prog' just like you
> > have to do './prog' in Linux.
>
That's not true for 'prog', but is true for any name of a PS cmdlet or
alias. In that case you must use a pathname (which can be EITHER
..\name OR ./name) OR name.exe.

CMD has some builtins which similarly make program files inaccessible
by simple name, but fewer. The ones I recall off the top of my head
are cd pushd popd dir mkdir md rmdir rd erase type set rem. And here
..\name or name.exe works but not ./name.

> I don't know anything about PowerShell. In the case of the POSIX-like
> shells, this is just a consequence of the . directory not being listed
> in the PATH variable, which is an end-user configuration matter.
>
> If you care about the convenience of just typing "prog", more than
> about the security aspect, you can just add . to your PATH.
>
No. In PS (_and_ in CMD) current directory aka dot is _always_ tried
even if it's not in PATH (which by default it isn't). But cmdlets and
aliases or builtins are tried first and override any file, per above.

Unix shells similarly won't find by simple name a program in . even
when . IS in PATH if the name is a builtin or keyword like 'cd' or
'if' or 'test' (probably the most popular name to encounter this
error), or a function or alias (shells don't come with lots of aliases
predefined like PS, but many distros or users add them).

dave_thompson_2@comcast.net writes:
>On Thu, 18 Jan 2024 19:40:44 -0000 (UTC), Kaz Kylheku
><433-929-6894@kylheku.com> wrote:
>
>> On 2024-01-18, bart <bc@freeuk.com> wrote:
>
>> > All I know about PowerShell is that instead of typing 'prog' to run the
>> > 'prog.exe' you've just created, you have to do '.\prog' just like you
>> > have to do './prog' in Linux.
>>
>That's not true for 'prog', but is true for any name of a PS cmdlet or
>alias. In that case you must use a pathname (which can be EITHER
>.\name OR ./name) OR name.exe.

Actually, on linux, one can just do 'prog', if PATH includes
an path element containing a single dot. One generally doesn't
do this, but it is certainly possible.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> It's important to understand what constitutes an extension. And
>> there are different kinds of extensions.
>>
>> If an implementation chooses, say, to evaluate function arguments
>> always left-to-right, that is perfectly okay (and need not be an
>> extension). But if an there is to be a /guarantee/ that function
>> arguments will always be evaluated left-to-right, that means
>> providing a guarantee that the C standard does not; thus we have an
>> extension (to the requirements in the C standard), and the extension
>> must be documented. This case is one kind of extension.
>
> If an implementation chooses to guarantee left-to-right evaluation, I
> don't see anything in the standard that requires that guarantee to be
> documented. (Of course it can and should be.)
>
> It's not entirely clear to me exactly what must or must not be
> considered to be an "extension" as the C standard uses the term. The
> standard doesn't show the word "extension" in italics or provide a
> definition in section 3.
>
> Unless your point is that it's not a guarantee unless it's documented?
> But I don't see that that documentation is required *by the standard*.

It seems likely that we have different notions of what "a guarantee"
is. As I am using the term it does not mean a statement of what
does happen but a promise for what will happen. Consulting some
online dictionaries, I find the following definitions (among others
that for the most part are not relevant). Note that all of these
are for "guarantee" used as a noun (presented in the order of
shortest first):

an assurance for the fulfillment of a condition

Something that assures a particular outcome or condition.

A pledge that something will be performed in a specified
manner.

an unconditional commitment that something will happen or
that something is true

a written assurance that some product or service will be
provided or will meet certain specifications

A promise or assurance, especially one given in writing, that
attests to the quality or durability of a product or service.

a promise or assurance, especially one in writing, that
something is of specified quality, content, benefit, etc.,
or that it will perform satisfactorily for a given length of
time: "a money-back guarantee".

In the context of a C implementation, for some condition to be a
guarantee I would say it must be written down (which is to say,
documented), as otherwise it doesn't qualify as a guarantee. In
any case that is how I am using the term.

Incidentally, as best I can determine the C standard uses the
term "guarantee" as a noun in only one place in normative text
(6.5.2.3 p6) and in two places in informative text (5.1.2.4 p23
and a footnote to 7.22.2.1 p2). Various forms of "guarantee"
used as a verb appear in the C standard in lots of places. I am
specifically using the noun form in my comments here.

I think most people would agree that any documented guarantee of
behavior beyond what the C standard requires of all implementations
(and is not part of the documentation for implementation-defined
behaviors) qualifies as an extension to the C language, and thus
should be considered an extension as the ISO C standard uses the
term, given that the C standard itself does not define the term
but (one assumes) uses the word in its ordinary English sense.

> [...]
>
>> If an implementation chooses to define, for example, __uint128_t to
>> be the name of an integer type, that represents a third kind of
>> extension. (Annex J.5 also mentions such definitions as an example
>> on its list of "Common extensions".) Such cases must be documented
>> as extensions because, one, the expected default is that there be no
>> definition (which normally would cause a diagnostic because of some
>> constraint violation), and two, only the implementation is in a
>> position to know if the symbol in question was defined by the
>> implementation or by something else. Clearly any definition the
>> implementation provides signals a change from the expected default,
>> which by any reasonable definition of the word constitutes an
>> extension, and hence must be documented.
>
> Again, that can and should be documented, but since any use of the
> identifer __uint128_t has undefined behavior,

That isn't right. The C standard says that declaring or defining a
reserved identifier is undefined behavior. The C standard does NOT
say that using a reserved identifier is undefined behavior. If an
implementation does not define an identifier like __uint128_t, then
any use in ordinary code (that is, not part of a pre-processor
directive) should produce a diagnostic due to a syntax or constraint
violation. If we don't get a diagnostic we know that the identifier
/must/ have been defined by the implementation, and because it is a
change in behavior over standard C it must be documented as an
extension.

(Note added during editing: "any use in ordinary code" is meant in
the sense of "a use that is not a declaration or definition".)

> I don't see any
> requirement in the standard that it must be documented.

It must be documented because it represents a change in behavior
over what the C standard requires, and any such change constitutes
an extension to the language, and the C standard requires extensions
to be documented.

> (Aside: gcc has an extension adding __int128 as a keyword, supporting
> types "__int128" and "unsigned __int128", but only on some target
> systems. These do not qualify as extended integer types. I understand
> that "__uint128_t" was a hypothetical example.)

On the systems I use the identifiers __int128_t and __uint128_t are
both predefined type names (and not keywords), under both gcc and
clang. I see some support for __int128 as a keyword, but the
predefined type names seem to be more reliable (at least in my
environments).

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

[...]

P.S. My apologies for not responding to your posting earlier.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> (Aside: gcc has an extension adding __int128 as a keyword, supporting
>> types "__int128" and "unsigned __int128", but only on some target
>> systems. These do not qualify as extended integer types. I understand
>> that "__uint128_t" was a hypothetical example.)
>
> On the systems I use the identifiers __int128_t and __uint128_t are
> both predefined type names (and not keywords), under both gcc and
> clang. I see some support for __int128 as a keyword, but the
> predefined type names seem to be more reliable (at least in my
> environments).

That's odd. The gcc documentation describes __int128 as an extension:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/_005f_005fint128.html

As an extension the integer scalar type __int128 is supported for
targets which have an integer mode wide enough to hold 128
bits. Simply write __int128 for a signed 128-bit integer, or
unsigned __int128 for an unsigned 128-bit integer. There is no
support in GCC for expressing an integer constant of type __int128
for targets with long long integer less than 128 bits wide.

It doesn't mention __int128_t or __uint128_t at all, though I see it
does recognize both, and as you say it doesn't treat them as keywords.
Likewise for clang, though I haven't checked the clang documentation.

(I might reply to other parts of your post later.)

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

om@iki.fi (Otto J. Makela) writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 16.01.2024 19:03, David Brown wrote:
>>> [...], because they know that Norwegians are superior to Swedes in
>>> every way...
>>
>> I just wanted to reply on that but then I saw your email address... :-)
>
> A Finn smirking from the sidelines.

As if you have no rivalry with Swedes. What's the score? 5-1? Ooops, now
it's 5-6. We have a great view here from Estonia.

> /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */

Send my regards to Vastarannan Kiiski.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/