Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: memset extensions
Date: Wed, 11 Nov 2015 13:19:59 -0800
Organization: None to speak of
Lines: 43
Message-ID: <lnsi4cqlmo.fsf@kst-u.example.com>
References: <n1v3pk$967$1@dont-email.me> <n1vctl$jg8$1@solani.org> <n1vqhm$u0o$2@dont-email.me> <87lha4ladh.fsf@bsb.me.uk> <n207p4$o0l$2@dont-email.me> <5643AC9B.2030305@verizon.net> <n20aav$3rt$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="6541"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+hkmaQd7TVgxdpgV+8AOnR"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:LJwMkQXbxZBbEYgtJt+hpC9eLTs= sha1:TmB4YZjBRqXsz8c6lo1SldM9b4w=
Xref: csiph.com comp.lang.c:75790

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 11/11/2015 22:01, James Kuyper a écrit :
> I wrote
>>> This is done in the lexical analysis phase.
>
>> True. But it's not a promotion.
>
> Exactly. That is why _Generic will not work, as I stated in my message.

That's only a problem if the argument is a character constant -- and if
it is, then you're probably going to use memset() anyway.

For your extended memset*() functions, if they're implemented as a macro
using _Generic, then the argument can be either an object of the
expected type:

    const uint16_t value = 0xabcd;
    new_memset(addr, value, count);

or a cast can be used to guarantee that _Generic unambiguously sees
the type you want it to:

    new_memset(addr, (uint16_t)0xabcd, count);

I'm not suggesting that _Generic is the best way to implement this, just
that type promotion is not a barrier to doing so.

On the other hand, the substantially different behavior depending on the
type of the argument could cause some confusion.  Programmers are likely
to expect an argument to be implicitly converted to the parameter type.
Giving it an all-caps name to make it clear that it's a macro and
clearly documenting the behavior might avoid most of that confusion.

I *think* that separate functions are still a better way to do this.

You might even want to have functions for each of the uintN_t types
*and* for the predefined unsigned types.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"