Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: C String terminator
Date: Thu, 02 Apr 2020 19:17:43 -0700
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <86a73tpb20.fsf@linuxsc.com>
References: <qvktc8$gvf$1@dont-email.me> <1by2u7s456.fsf@pfeifferfamily.net> <87o8v3cg0i.fsf@bsb.me.uk> <qvqn8b$3kq$2@dont-email.me> <877e1rc6f7.fsf@bsb.me.uk> <qvt1s7$jfr$1@dont-email.me> <87v9p9bylk.fsf@bsb.me.uk> <qvt6iq$j73$1@dont-email.me> <qvt6ts$l0m$1@dont-email.me> <qvt7l5$q6n$1@dont-email.me> <qvt8kp$v1f$1@dont-email.me> <861rrtj9hx.fsf@linuxsc.com> <87d0bc8xf6.fsf@nosuchdomain.example.com> <861rquhlqk.fsf@linuxsc.com> <87wo8m9nm4.fsf@nosuchdomain.example.com> <86imjyd2hl.fsf@linuxsc.com> <87blpqa6y6.fsf@nosuchdomain.example.com> <867dz589t3.fsf@linuxsc.com> <875zepvvu1.fsf@nosuchdomain.example.com> <86sghl6eop.fsf@linuxsc.com> <61f8fb26-45fb-46c4-8bf4-d85d8fb94a8d@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="764a289b4fffae23755ccdbd2c0254f8"; logging-data="17123"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+1JrCghkl0xjH5puUhEQY7iOfbrys5i58="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:lrEOqi9GB1dU++RqinUpEq8JQeE= sha1:i10J26oMU68qqliynCwIoIPILD0=
Xref: csiph.com comp.lang.c:150967

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch  wrote:
>
>>> Regarding a point I raised above, 3.7.1 defines a "character"
>>> as a "bit representation that fits in a byte", and 7.1.1 defines
>>> a "string" as a sequence of characters -- but "%s" specifically
>>> requires a pointer to the initial element of an array of character
>>> type, i.e., one of char, signed char, or unsigned char.  I see
>>> no requirement that a "character" must be of "character type".
>>> Possibly the standard's definition of "character" is incomplete
>>> and/or does not fully convey the intent.
>>
>> The term "character" is a restriction on values, not types.  The
>> constant 's' is a character, but has type int.
>
> That's so that EOF can be coded as -1, and is not a "character".
>
>> .
>> I haven't checked this, but I feel confident the Standard avoids
>> all of these problems by, eg, using parameter types such as 'char *'
>> so there is no question about what type is being referred to, or
>> by doing what is done for printf, namely, giving the specification
>> so it references "an array of character type".
>
> The "%s" format specifier can take char *, unsigned char *, or signed char *.
> That's quite a mouthful, so "array of character type" is used as shorthand.

The depth of your understanding truly defies my
ability to describe it.