Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.std.c
Subject: Re: Add @ to basic character set?
Date: Sun, 06 Dec 2020 14:07:12 -0800
Organization: None to speak of
Lines: 44
Message-ID: <87lfeafv1r.fsf@nosuchdomain.example.com>
References: <rqfeip$lrr$1@solani.org> <rqgae4$1u1$1@dont-email.me> <87pn3ngao5.fsf@nosuchdomain.example.com> <rqiik6$58p$1@dont-email.me> <rqijtd$dbr$1@dont-email.me> <ud5zH.388173$gR8.7685@fx45.iad>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="de68eac51acee32b20f4ae1a08adb63c"; logging-data="18472"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19q9qQeS5WjlF63YHF815+A"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock: sha1:HDQHwcNshJVOwkmGz0ycvLlfnsY= sha1:R8cH3wMO/SsnezFkmQNyZKPvdZ8=
Xref: csiph.com comp.std.c:6174

Richard Damon <Richard@Damon-Family.org> writes:
[...]
> The issue with making them part of the basic character set is that it
> makes any system that can't do this, because it uses a strange character
> set, non-conforming. Since systems ARE allowed to add any characters
> they want to the source or execution character set, those that currently
> support them can do so. Forcing them to be included drops some system
> from being able to have a conforming implementation, and the committee
> has traditionally avoided gratuitously making systems non-conforming.

(Context: The ASCII characters '@', '$', and '`'.)

I'd be interested in seeing an implementation for which this would
be relevant.  Such an implementation (a) would be unable to (easily)
represent those three character in source code and/or during
execution *and* (b) would otherwise conform to the hypothetical
edition of the C standard that would add them to the basic character
set if it were not for this change.

Implementations that can't support those characters are likely to be
for tiny exotic target systems, and very likely won't be conforming
anyway, and so could simply ignore the addition of those characters
to the basic character set.

> The only case that can be made to make them part, is that then programs
> that use those characters might be able to become strictly conforming
> programs instead of just being conforming programs, but strict
> conformance isn't really that big of a deal in practicality, as
> virtually all real programs are going to fail strict performance because
> they are going to depend on some aspect of the environment (Like how I/O
> actually works)

I suppose I agree that it's not that big a deal.  Code that uses
those characters is *practically* 100% portable already, and I haven't
found a way to coax either gcc or clang to warn about puts("$@`").
The benefit would be minor, and the cost would be very close to zero
(unless an implementation as I've described above actually exists).
It would be one less thing to think about when writing code that's
intended to be as portable as possible.

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