On 1/28/22 20:13, Meredith Montgomery wrote:
....
> What's a freestanding implementation?

"The two forms of conforming implementation are hosted and freestanding.
A conforming hosted implementation shall accept any strictly conforming
program. A conforming freestanding implementation shall accept any
strictly conforming program in which the use of the features specified
in the library clause (Clause 7) is confined to the contents of the
standard headers <float.h> , <iso646.h> , <limits.h> , <stdalign.h> ,
<stdarg.h> , <stdbool.h> , <stddef.h> , <stdint.h> , and <stdnoreturn.h>
.. Additionally, a conforming freestanding implementation shall accept
any strictly conforming program in which the use of the features
specified in the header <string.h> , except the following functions:
strdup , strndup , strcoll , strxfrm , strerror ." (4p6)

That last sentence is new in n2731.pdf, the latest draft of the CX 202X
that I have. It's not grammatically correct; I suspect that the word
"except" in the final sentence should have been "is confined to the use
of", paralleling the structure of the previous sentence.

Basically, freestanding implementations have no obligation to implement
most of the C standard library.

Meredith Montgomery <mmontgomery@levado.to> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> [...]
>>>>> "... the value is converted by repeatedly adding ... one more than the
>>>>> maximum value that can be represented in the new type until the value is
>>>>> in the range of the new type." (6.3.1.3p2).
>>>>>
>>>>> It's the other direction that's dangerous: conversion of an integer
>>>>> value to a signed integer type that is not representable in that type
>>>>> has undefined behavior.
>>>>
>>>> No, converting an out-of-range integer value to a signed integer type
>>>> yields an implementation-defined result or raises an
>>>> implementation-defined signal. (C99 added the option of raising a
>>>> signal; in my opinion that was a bad idea.)
>>>
>>> Just curious --- why do you think a signal is a bad idea?
>>
>> A signal isn't inherently a bad idea, particularly if portable code can
>> handle it. But the fact that the signal is implementation-defined makes
>> that impossible. (And freestanding implementations needn't support
>> <signal.h>.)
>
> What's a freestanding implementation?

See section 4 of any edition of the C standard. I usually use
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, a draft
that's close to C11.

The two forms of *conforming implementation* are hosted and
freestanding. A *conforming hosted implementation* shall accept any
strictly conforming program. A *conforming freestanding implementation*
shall accept any strictly conforming program in which the use of the
features specified in the library clause (clause 7) is confined to the
contents of the standard headers <float.h>, <iso646.h>, <limits.h>,
<stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and
<stdnoreturn.h>. A conforming implementation may have extensions
(including additional library functions), provided they do not alter
the behavior of any strictly conforming program.

Basically a hosted implementation is the kind that you're most likely to
encounter. It generates code that runs under an operating system, and
it supports the entire standard library. A freestanding implementation
targets an embedded system that might not have an operating system at
all. The only standard library headers that must be supported are the
ones that don't declare any functions. A freestanding implementation
might provide some library functions, but it isn't required to.

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

Am 16.01.2022 um 03:53 schrieb Tim Rentsch:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> I've seen this somewhere or I wrote this some time in the past for some
>> reason and I can't see how this make sense any longer. In a procedure
>> to read a numeric string and turn it into a number, we need to convert
>> each char-digit to some kind of integer:
>>
>> (uint64_t) (unsigned char) (s[pos] - '0');
>>
>> But the double cast here seems odd. I could have written this by
>> copying it from somewhere else. Today, what I would write is just
>>
>> (uint64_t) (s[pos] - '0');
>>
>> Am I making a mistake now? I can't anything wrong with this. Isn't a
>> char just an int? I'm turning an int into an unsigned integer (of a
>> larger size).
>
> The original context for the expression in question is this
> function:
>
>> [posted by Meredith Montgomery]
>>
>> #include <limits.h>
>> #include <inttypes.h>
>>
>> int scan_ulong(register char *s, register unsigned long *u)
>> {
>> register unsigned int pos;
>> register unsigned long r;
>> register unsigned long c;
>>
>> pos = 0; r = 0;
>>
>> for ( ;; ) {
>> c = (unsigned long) (unsigned char) (s[pos] - '0');
>> if (c < 10) {
>> if( ((ULONG_MAX - c) / 10) >= r)
>> r = r * 10 + c;
>> else return -1; /* lack of space */
>> ++pos; continue;
>> }
>> break;
>> }
>>
>> *u = r;
>> return pos;
>> }
>
> In this context, the casts are superfluous. Just write
>
> c = s[pos] - '0';

This makes different results if "s[pos] - '0'" is negative.

>
> and the right thing will happen, because the assignment to 'c'
> converts the value on the right hand side to 'unsigned long',
> and so takes care of any negative values.

On Saturday, 29 January 2022 at 17:57:34 UTC+2, Bonita Montero wrote:
> Am 16.01.2022 um 03:53 schrieb Tim Rentsch:
> > Meredith Montgomery <mmont...@levado.to> writes:
> >
> >> I've seen this somewhere or I wrote this some time in the past for some
> >> reason and I can't see how this make sense any longer. In a procedure
> >> to read a numeric string and turn it into a number, we need to convert
> >> each char-digit to some kind of integer:
> >>
> >> (uint64_t) (unsigned char) (s[pos] - '0');
> >>
> >> But the double cast here seems odd. I could have written this by
> >> copying it from somewhere else. Today, what I would write is just
> >>
> >> (uint64_t) (s[pos] - '0');
> >>
> >> Am I making a mistake now? I can't anything wrong with this. Isn't a
> >> char just an int? I'm turning an int into an unsigned integer (of a
> >> larger size).
> >
> > The original context for the expression in question is this
> > function:
> >
> >> [posted by Meredith Montgomery]
> >>
> >> #include <limits.h>
> >> #include <inttypes.h>
> >>
> >> int scan_ulong(register char *s, register unsigned long *u)
> >> {
> >> register unsigned int pos;
> >> register unsigned long r;
> >> register unsigned long c;
> >>
> >> pos = 0; r = 0;
> >>
> >> for ( ;; ) {
> >> c = (unsigned long) (unsigned char) (s[pos] - '0');
> >> if (c < 10) {
> >> if( ((ULONG_MAX - c) / 10) >= r)
> >> r = r * 10 + c;
> >> else return -1; /* lack of space */
> >> ++pos; continue;
> >> }
> >> break;
> >> }
> >>
> >> *u = r;
> >> return pos;
> >> }
> >
> > In this context, the casts are superfluous. Just write
> >
> > c = s[pos] - '0';
> This makes different results if "s[pos] - '0'" is negative.

Your usual incapability to read next sentence below that addresses it
specifically noted.

> >
> > and the right thing will happen, because the assignment to 'c'
> > converts the value on the right hand side to 'unsigned long',
> > and so takes care of any negative values.

Works, unlike your pathetically borken functions in another thread:
https://groups.google.com/g/comp.lang.c/c/pfgpeqAm0h8/m/y9MHNBwuAQAJ

On 1/29/2022 4:37 AM, Keith Thompson wrote:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>>> [...]
>>>>>> "... the value is converted by repeatedly adding ... one more than the
>>>>>> maximum value that can be represented in the new type until the value is
>>>>>> in the range of the new type." (6.3.1.3p2).
>>>>>>
>>>>>> It's the other direction that's dangerous: conversion of an integer
>>>>>> value to a signed integer type that is not representable in that type
>>>>>> has undefined behavior.
>>>>>
>>>>> No, converting an out-of-range integer value to a signed integer type
>>>>> yields an implementation-defined result or raises an
>>>>> implementation-defined signal. (C99 added the option of raising a
>>>>> signal; in my opinion that was a bad idea.)
>>>>
>>>> Just curious --- why do you think a signal is a bad idea?
>>>
>>> A signal isn't inherently a bad idea, particularly if portable code can
>>> handle it. But the fact that the signal is implementation-defined makes
>>> that impossible. (And freestanding implementations needn't support
>>> <signal.h>.)
>>
>> What's a freestanding implementation?
>
> See section 4 of any edition of the C standard. I usually use
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, a draft
> that's close to C11.
>
> The two forms of *conforming implementation* are hosted and
> freestanding. A *conforming hosted implementation* shall accept any
> strictly conforming program. A *conforming freestanding implementation*
> shall accept any strictly conforming program in which the use of the
> features specified in the library clause (clause 7) is confined to the
> contents of the standard headers <float.h>, <iso646.h>, <limits.h>,
> <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and
> <stdnoreturn.h>. A conforming implementation may have extensions
> (including additional library functions), provided they do not alter
> the behavior of any strictly conforming program.
>
> Basically a hosted implementation is the kind that you're most likely to
> encounter. It generates code that runs under an operating system, and
> it supports the entire standard library. A freestanding implementation
> targets an embedded system that might not have an operating system at
> all. The only standard library headers that must be supported are the
> ones that don't declare any functions. A freestanding implementation
> might provide some library functions, but it isn't required to.
>

A freestanding implementation might also target the OS itself of a
common system (not necessarily embedded), right?

Manfred <noname@add.invalid> writes:
> On 1/29/2022 4:37 AM, Keith Thompson wrote:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>>>> [...]
>>>>>>> "... the value is converted by repeatedly adding ... one more than the
>>>>>>> maximum value that can be represented in the new type until the value is
>>>>>>> in the range of the new type." (6.3.1.3p2).
>>>>>>>
>>>>>>> It's the other direction that's dangerous: conversion of an integer
>>>>>>> value to a signed integer type that is not representable in that type
>>>>>>> has undefined behavior.
>>>>>>
>>>>>> No, converting an out-of-range integer value to a signed integer type
>>>>>> yields an implementation-defined result or raises an
>>>>>> implementation-defined signal. (C99 added the option of raising a
>>>>>> signal; in my opinion that was a bad idea.)
>>>>>
>>>>> Just curious --- why do you think a signal is a bad idea?
>>>>
>>>> A signal isn't inherently a bad idea, particularly if portable code can
>>>> handle it. But the fact that the signal is implementation-defined makes
>>>> that impossible. (And freestanding implementations needn't support
>>>> <signal.h>.)
>>>
>>> What's a freestanding implementation?
>> See section 4 of any edition of the C standard. I usually use
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, a draft
>> that's close to C11.
>> The two forms of *conforming implementation* are hosted and
>> freestanding. A *conforming hosted implementation* shall accept any
>> strictly conforming program. A *conforming freestanding implementation*
>> shall accept any strictly conforming program in which the use of the
>> features specified in the library clause (clause 7) is confined to the
>> contents of the standard headers <float.h>, <iso646.h>, <limits.h>,
>> <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and
>> <stdnoreturn.h>. A conforming implementation may have extensions
>> (including additional library functions), provided they do not alter
>> the behavior of any strictly conforming program.
>> Basically a hosted implementation is the kind that you're most
>> likely to
>> encounter. It generates code that runs under an operating system, and
>> it supports the entire standard library. A freestanding implementation
>> targets an embedded system that might not have an operating system at
>> all. The only standard library headers that must be supported are the
>> ones that don't declare any functions. A freestanding implementation
>> might provide some library functions, but it isn't required to.
>
> A freestanding implementation might also target the OS itself of a
> common system (not necessarily embedded), right?

Sure. Any implementation that meet's the standard's requirements can be
a conforming freestanding implementation -- even one that targets an OS.
You could call an implementation "freestanding" even if it's just
because you haven't implemented all the required parts of the standard
library.

The standard does have more to say about freestanding implementations
(N1570 5.1.2.1):

In a freestanding environment (in which C program execution
may take place without any benefit of an operating system),
the name and type of the function called at program startup are
implementation-defined. Any library facilities available to a
freestanding program, other than the minimal set required by
clause 4, are implementation-defined.

The effect of program termination in a freestanding environment
is implementation-defined.

And the ANSI C Rationale:

By defining conforming implementations in terms of the programs they
accept, the Standard leaves open the door for a broad class of
extensions as part of a conforming implementation. By defining both
conforming hosted and conforming freestanding implementations, the
Standard recognizes the use of C to write such programs as operating
systems and ROM-based applications, as well as more conventional
hosted applications. Beyond this two-level scheme, no additional
subsetting is defined for C, since the Committee felt strongly that
too many levels dilutes the effectiveness of a standard.

I think the intent is that freestanding implementations are for embedded
systems, likely with no OS, or you're using the implementation to build
the OS, but it's not a strict requirement.

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

Am 29.01.2022 um 18:54 schrieb Öö Tiib:
> On Saturday, 29 January 2022 at 17:57:34 UTC+2, Bonita Montero wrote:
>> Am 16.01.2022 um 03:53 schrieb Tim Rentsch:
>>> Meredith Montgomery <mmont...@levado.to> writes:
>>>
>>>> I've seen this somewhere or I wrote this some time in the past for some
>>>> reason and I can't see how this make sense any longer. In a procedure
>>>> to read a numeric string and turn it into a number, we need to convert
>>>> each char-digit to some kind of integer:
>>>>
>>>> (uint64_t) (unsigned char) (s[pos] - '0');
>>>>
>>>> But the double cast here seems odd. I could have written this by
>>>> copying it from somewhere else. Today, what I would write is just
>>>>
>>>> (uint64_t) (s[pos] - '0');
>>>>
>>>> Am I making a mistake now? I can't anything wrong with this. Isn't a
>>>> char just an int? I'm turning an int into an unsigned integer (of a
>>>> larger size).
>>>
>>> The original context for the expression in question is this
>>> function:
>>>
>>>> [posted by Meredith Montgomery]
>>>>
>>>> #include <limits.h>
>>>> #include <inttypes.h>
>>>>
>>>> int scan_ulong(register char *s, register unsigned long *u)
>>>> {
>>>> register unsigned int pos;
>>>> register unsigned long r;
>>>> register unsigned long c;
>>>>
>>>> pos = 0; r = 0;
>>>>
>>>> for ( ;; ) {
>>>> c = (unsigned long) (unsigned char) (s[pos] - '0');
>>>> if (c < 10) {
>>>> if( ((ULONG_MAX - c) / 10) >= r)
>>>> r = r * 10 + c;
>>>> else return -1; /* lack of space */
>>>> ++pos; continue;
>>>> }
>>>> break;
>>>> }
>>>>
>>>> *u = r;
>>>> return pos;
>>>> }
>>>
>>> In this context, the casts are superfluous. Just write
>>>
>>> c = s[pos] - '0';
>> This makes different results if "s[pos] - '0'" is negative.
>
> Your usual incapability to read next sentence below that addresses it
> specifically noted.
>
>>>
>>> and the right thing will happen, because the assignment to 'c'
>>> converts the value on the right hand side to 'unsigned long',
>>> and so takes care of any negative values.

That's not true. The compiler may give a negative value
converted to an unsigned value:

__declspec(noinline)
unsigned long f( char c )
{ return c - '0';
}

movsx eax, cl
sub eax, 48
ret 0

On 1/30/22 3:01 AM, Keith Thompson wrote:
> Manfred <noname@add.invalid> writes:
>> On 1/29/2022 4:37 AM, Keith Thompson wrote:
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>>>>> [...]
>>>>>>>> "... the value is converted by repeatedly adding ... one more than the
>>>>>>>> maximum value that can be represented in the new type until the value is
>>>>>>>> in the range of the new type." (6.3.1.3p2).
>>>>>>>>
>>>>>>>> It's the other direction that's dangerous: conversion of an integer
>>>>>>>> value to a signed integer type that is not representable in that type
>>>>>>>> has undefined behavior.
>>>>>>>
>>>>>>> No, converting an out-of-range integer value to a signed integer type
>>>>>>> yields an implementation-defined result or raises an
>>>>>>> implementation-defined signal. (C99 added the option of raising a
>>>>>>> signal; in my opinion that was a bad idea.)
>>>>>>
>>>>>> Just curious --- why do you think a signal is a bad idea?
>>>>>
>>>>> A signal isn't inherently a bad idea, particularly if portable code can
>>>>> handle it. But the fact that the signal is implementation-defined makes
>>>>> that impossible. (And freestanding implementations needn't support
>>>>> <signal.h>.)
>>>>
>>>> What's a freestanding implementation?
>>> See section 4 of any edition of the C standard. I usually use
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, a draft
>>> that's close to C11.
>>> The two forms of *conforming implementation* are hosted and
>>> freestanding. A *conforming hosted implementation* shall accept any
>>> strictly conforming program. A *conforming freestanding implementation*
>>> shall accept any strictly conforming program in which the use of the
>>> features specified in the library clause (clause 7) is confined to the
>>> contents of the standard headers <float.h>, <iso646.h>, <limits.h>,
>>> <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and
>>> <stdnoreturn.h>. A conforming implementation may have extensions
>>> (including additional library functions), provided they do not alter
>>> the behavior of any strictly conforming program.
>>> Basically a hosted implementation is the kind that you're most
>>> likely to
>>> encounter. It generates code that runs under an operating system, and
>>> it supports the entire standard library. A freestanding implementation
>>> targets an embedded system that might not have an operating system at
>>> all. The only standard library headers that must be supported are the
>>> ones that don't declare any functions. A freestanding implementation
>>> might provide some library functions, but it isn't required to.
>>
>> A freestanding implementation might also target the OS itself of a
>> common system (not necessarily embedded), right?
>
> Sure. Any implementation that meet's the standard's requirements can be
> a conforming freestanding implementation -- even one that targets an OS.
> You could call an implementation "freestanding" even if it's just
> because you haven't implemented all the required parts of the standard
> library.
>
> The standard does have more to say about freestanding implementations
> (N1570 5.1.2.1):
>
> In a freestanding environment (in which C program execution
> may take place without any benefit of an operating system),
> the name and type of the function called at program startup are
> implementation-defined. Any library facilities available to a
> freestanding program, other than the minimal set required by
> clause 4, are implementation-defined.
>
> The effect of program termination in a freestanding environment
> is implementation-defined.
>
> And the ANSI C Rationale:
>
> By defining conforming implementations in terms of the programs they
> accept, the Standard leaves open the door for a broad class of
> extensions as part of a conforming implementation. By defining both
> conforming hosted and conforming freestanding implementations, the
> Standard recognizes the use of C to write such programs as operating
> systems and ROM-based applications, as well as more conventional
> hosted applications. Beyond this two-level scheme, no additional
> subsetting is defined for C, since the Committee felt strongly that
> too many levels dilutes the effectiveness of a standard.
>
> I think the intent is that freestanding implementations are for embedded
> systems, likely with no OS, or you're using the implementation to build
> the OS, but it's not a strict requirement.
>

I suppose that means that most 'Windows' implementations are technically
'freestanding' since the program starts at winmain not main (or just not
conforming, which also sounds sort of right).

On Sunday, 30 January 2022 at 14:17:37 UTC+2, Bonita Montero wrote:
> Am 29.01.2022 um 18:54 schrieb Öö Tiib:
> > On Saturday, 29 January 2022 at 17:57:34 UTC+2, Bonita Montero wrote:
> >> Am 16.01.2022 um 03:53 schrieb Tim Rentsch:
> >>> Meredith Montgomery <mmont...@levado.to> writes:
> >>>
> >>>> I've seen this somewhere or I wrote this some time in the past for some
> >>>> reason and I can't see how this make sense any longer. In a procedure
> >>>> to read a numeric string and turn it into a number, we need to convert
> >>>> each char-digit to some kind of integer:
> >>>>
> >>>> (uint64_t) (unsigned char) (s[pos] - '0');
> >>>>
> >>>> But the double cast here seems odd. I could have written this by
> >>>> copying it from somewhere else. Today, what I would write is just
> >>>>
> >>>> (uint64_t) (s[pos] - '0');
> >>>>
> >>>> Am I making a mistake now? I can't anything wrong with this. Isn't a
> >>>> char just an int? I'm turning an int into an unsigned integer (of a
> >>>> larger size).
> >>>
> >>> The original context for the expression in question is this
> >>> function:
> >>>
> >>>> [posted by Meredith Montgomery]
> >>>>
> >>>> #include <limits.h>
> >>>> #include <inttypes.h>
> >>>>
> >>>> int scan_ulong(register char *s, register unsigned long *u)
> >>>> {
> >>>> register unsigned int pos;
> >>>> register unsigned long r;
> >>>> register unsigned long c;
> >>>>
> >>>> pos = 0; r = 0;
> >>>>
> >>>> for ( ;; ) {
> >>>> c = (unsigned long) (unsigned char) (s[pos] - '0');
> >>>> if (c < 10) {
> >>>> if( ((ULONG_MAX - c) / 10) >= r)
> >>>> r = r * 10 + c;
> >>>> else return -1; /* lack of space */
> >>>> ++pos; continue;
> >>>> }
> >>>> break;
> >>>> }
> >>>>
> >>>> *u = r;
> >>>> return pos;
> >>>> }
> >>>
> >>> In this context, the casts are superfluous. Just write
> >>>
> >>> c = s[pos] - '0';
> >> This makes different results if "s[pos] - '0'" is negative.
> >
> > Your usual incapability to read next sentence below that addresses it
> > specifically noted.
> >
> >>>
> >>> and the right thing will happen, because the assignment to 'c'
> >>> converts the value on the right hand side to 'unsigned long',
> >>> and so takes care of any negative values.
>
> That's not true. The compiler may give a negative value
> converted to an unsigned value:
>
> __declspec(noinline)
> unsigned long f( char c )
> {
> return c - '0';
> }
>
> movsx eax, cl
> sub eax, 48
> ret 0

And little negative value converted to unsigned value does not
satisfy < 10. Works, unlike your pathetically borken functions
in another thread:
https://groups.google.com/g/comp.lang.c/c/pfgpeqAm0h8/m/y9MHNBwuAQAJ

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

> On 1/28/22 20:13, Meredith Montgomery wrote:
> ...
>
>> What's a freestanding implementation?
>
> "The two forms of conforming implementation are hosted and freestanding.
> A conforming hosted implementation shall accept any strictly conforming
> program. A conforming freestanding implementation shall accept any
> strictly conforming program in which the use of the features specified
> in the library clause (Clause 7) is confined to the contents of the
> standard headers <float.h> , <iso646.h> , <limits.h> , <stdalign.h> ,
> <stdarg.h> , <stdbool.h> , <stddef.h> , <stdint.h> , and <stdnoreturn.h>
> . Additionally, a conforming freestanding implementation shall accept
> any strictly conforming program in which the use of the features
> specified in the header <string.h> , except the following functions:
> strdup , strndup , strcoll , strxfrm , strerror ." (4p6)
>
> That last sentence is new in n2731.pdf, the latest draft of the CX 202X
> that I have. It's not grammatically correct; I suspect that the word
> "except" in the final sentence should have been "is confined to the use
> of", paralleling the structure of the previous sentence.

Surely what is intended is just the opposite: interfaces in <string.h>
may be used, except that strdup, strndup, strcoll, strxfrm, strerror
may not be used.

On Friday, February 4, 2022 at 1:29:20 AM UTC-5, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
....
> > . Additionally, a conforming freestanding implementation shall accept
> > any strictly conforming program in which the use of the features
> > specified in the header <string.h> , except the following functions:
> > strdup , strndup , strcoll , strxfrm , strerror ." (4p6)
> >
> > That last sentence is new in n2731.pdf, the latest draft of the CX 202X
> > that I have. It's not grammatically correct; I suspect that the word
> > "except" in the final sentence should have been "is confined to the use
> > of", paralleling the structure of the previous sentence.
> Surely what is intended is just the opposite: interfaces in <string.h>
> may be used, except that strdup, strndup, strcoll, strxfrm, strerror
> may not be used.

You might be right about that; it does make sense. However, regardless of what
they actually meant, the actual wording was messed up. It doesn't clearly
express either of our guesses as to the intended meaning.