Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #75726 > unrolled thread

memset extensions

Back to article view | Back to comp.lang.c

Contents

  memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 11:05 +0100
    Re: memset extensions Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-11-11 11:08 +0100
      Re: memset extensions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-11 04:56 -0800
    Re: memset extensions Philipp Klaus Krause <pkk@spth.de> - 2015-11-11 13:39 +0100
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 17:34 +0100
        Re: memset extensions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 17:22 +0000
          Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 21:19 +0100
            Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 12:51 -0800
            Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 16:01 -0500
              Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 22:03 +0100
                Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 13:19 -0800
                  Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 22:45 +0100
                    Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 16:51 -0500
                      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 23:01 +0100
                        Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 17:29 -0500
                          Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 23:36 +0100
                    Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 15:00 -0800
                Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 16:48 -0500
            Re: memset extensions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 22:15 +0000
    Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 08:05 -0500
    Re: memset extensions Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-11 08:31 -0500
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 17:34 +0100
    Re: memset extensions Les Cargill <lcargill99@comcast.com> - 2015-11-11 08:30 -0600
      Re: memset extensions Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-11 09:48 -0500
      Re: memset extensions gwowen <gwowen@gmail.com> - 2015-11-11 07:55 -0800
      Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 11:24 -0500
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 17:32 +0100
        Re: memset extensions Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-11 11:44 -0500
        Re: memset extensions raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:53 +0000
          Re: memset extensions supercat@casperkitty.com - 2015-11-17 15:37 -0800
            Re: memset extensions raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:27 +0000
              Re: memset extensions supercat@casperkitty.com - 2015-11-20 08:45 -0800
    Re: memset extensions supercat@casperkitty.com - 2015-11-11 08:25 -0800
    Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 09:09 -0800
      Re: memset extensions supercat@casperkitty.com - 2015-11-11 09:18 -0800
        Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 10:57 -0800
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 21:17 +0100

Page 1 of 2  [1] 2  Next page →

#75726 — memset extensions

void *memset(void *srcPtr,unsigned char value,size_t size);

I want to add extensions to it:

void memset16( void *srcPtr, int16_t  value, size_t size);
void memset32( void *srcPtr, int32_t  value, size_t size);
void memset64( void *srcPtr, int64_t  value, size_t size);
void memset128(void *srcPtr, int128_t value, size_t size);

Are the names OK? Or it would be better to just

void memsetShort(...);
void memsetInt(...);
void memsetLongLong(...);
void memset128(...);

Microsoft has this functions as RTLFillMemory. I do not know if other 
compilers support anything like this.

What do you think?

[toc] | [next] | [standalone]

#75727

On 2015-11-11 11:05, jacobnavia wrote:

You might try something more flexible, eg:

FillMem (size_t tolen, void *to,
          size_t patternlen, const void *pattern);

[toc] | [prev] | [next] | [standalone]

#75735

On Wednesday, November 11, 2015 at 5:11:13 AM UTC-5, Lőrinczy Zsigmond wrote:
> On 2015-11-11 11:05, jacobnavia wrote:
> 
> You might try something more flexible, eg:
> 
> FillMem (size_t tolen, void *to,
>           size_t patternlen, const void *pattern);

Why not #undef memset() from your header file, and replace it with your
own, with one that performs logic on the standard memset() parameters,
and if they are evenly divisible by 2 or 4 or 8 or 16, then call the
appropriate handlers internally?

FWIW, I'd be surprised if memset() didn't already do this on its own.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#75733

On 11.11.2015 11:05, jacobnavia wrote:
> void *memset(void *srcPtr,unsigned char value,size_t size);
> 
> I want to add extensions to it:
> 
> void memset16( void *srcPtr, int16_t  value, size_t size);
> void memset32( void *srcPtr, int32_t  value, size_t size);
> void memset64( void *srcPtr, int64_t  value, size_t size);
> void memset128(void *srcPtr, int128_t value, size_t size);
> 
> Are the names OK? Or it would be better to just
> 
> void memsetShort(...);
> void memsetInt(...);
> void memsetLongLong(...);
> void memset128(...);
> 
> Microsoft has this functions as RTLFillMemory. I do not know if other
> compilers support anything like this.
> 
> What do you think?

Why only for signed values? Why not use _Generic?

Philipp

[toc] | [prev] | [next] | [standalone]

#75763

Le 11/11/2015 13:39, Philipp Klaus Krause a écrit :
> On 11.11.2015 11:05, jacobnavia wrote:
>> void *memset(void *srcPtr,unsigned char value,size_t size);
>>
>> I want to add extensions to it:
>>
>> void memset16( void *srcPtr, int16_t  value, size_t size);
>> void memset32( void *srcPtr, int32_t  value, size_t size);
>> void memset64( void *srcPtr, int64_t  value, size_t size);
>> void memset128(void *srcPtr, int128_t value, size_t size);
>>
>> Are the names OK? Or it would be better to just
>>
>> void memsetShort(...);
>> void memsetInt(...);
>> void memsetLongLong(...);
>> void memset128(...);
>>
>> Microsoft has this functions as RTLFillMemory. I do not know if other
>> compilers support anything like this.
>>
>> What do you think?
>
> Why only for signed values? Why not use _Generic?
>
> Philipp
>


_Generic can't be used since

'A' --> integer
120 --> integer also

You would never get a value less than int since all others are promoted 
automatically

[toc] | [prev] | [next] | [standalone]

#75779

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 11/11/2015 13:39, Philipp Klaus Krause a écrit :
>> On 11.11.2015 11:05, jacobnavia wrote:
>>> void *memset(void *srcPtr,unsigned char value,size_t size);
>>>
>>> I want to add extensions to it:
>>>
>>> void memset16( void *srcPtr, int16_t  value, size_t size);
>>> void memset32( void *srcPtr, int32_t  value, size_t size);
>>> void memset64( void *srcPtr, int64_t  value, size_t size);
>>> void memset128(void *srcPtr, int128_t value, size_t size);
<snip>
>> Why only for signed values? Why not use _Generic?
>
> _Generic can't be used since
>
> 'A' --> integer
> 120 --> integer also
>
> You would never get a value less than int since all others are
> promoted automatically

That's not true.  The controlling expression of _Generic does not
undergo promotion.

What's more, if you make the first parameter type-specific
(i.e. ditching void * and using int16_t * and so on) you could use
_Generic on that (in a macro) to avoid the problem caused by 'A' being
of type int.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#75786

Le 11/11/2015 18:22, Ben Bacarisse a écrit :
> The controlling expression of _Generic does not
> undergo promotion.

When you type

'A' in C it is the same as you would have typed "65".

This is done in the lexical analysis phase.

[toc] | [prev] | [next] | [standalone]

#75787

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 11/11/2015 18:22, Ben Bacarisse a écrit :
>> The controlling expression of _Generic does not
>> undergo promotion.
>
> When you type
>
> 'A' in C it is the same as you would have typed "65".
>
> This is done in the lexical analysis phase.

Yes, character constants are of type int.  That's not type promotion;
it's just the type of the constant.  An expression of type char is still
recognized as a char if it's the first operand of _Generic.  For
example:

    #include <stdio.h>
    #include <stdint.h>
    #define TYPEOF(expr) \
        (_Generic(expr, \
                  char: "char", \
                  int: "int", \
                  default: "other"))
    int main(void) {
        int16_t i16;
        printf("TYPEOF('A') = %s\n", TYPEOF('A'));
        printf("TYPEOF((char)'A') = %s\n", TYPEOF((char)'A'));
        printf("TYPEOF(i16) = %s\n", TYPEOF(i16));
    }

The output is:

    TYPEOF('A') = int
    TYPEOF((char)'A') = char
    TYPEOF(i16) = other

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

[toc] | [prev] | [next] | [standalone]

#75788

On 11/11/2015 03:19 PM, jacobnavia wrote:
> Le 11/11/2015 18:22, Ben Bacarisse a écrit :
>> The controlling expression of _Generic does not
>> undergo promotion.
> 
> When you type
> 
> 'A' in C it is the same as you would have typed "65".

The numeric valued depends upon which encoding is supported by the
implementation, but the fact that character constants have 'int' type is
independent of that issue.

> This is done in the lexical analysis phase.

True. But it's not a promotion.

If you want to do something memset()-like using 'A' to initialize one
byte at a time, just use the original memset(). Your extended versions
of memset() would only be used when you want to initialize using
something other than a narrow character constant - which means that
_Generic could be used to determine the appropriate way to handle it.

[toc] | [prev] | [next] | [standalone]

#75789

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.

jacob

[toc] | [prev] | [next] | [standalone]

#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"

[toc] | [prev] | [next] | [standalone]

#75791

Le 11/11/2015 22:19, Keith Thompson a écrit :
> 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.

What about shorts?

25987

Is that a short or an int?

How can I (without explicit cast) make it a short?

[toc] | [prev] | [next] | [standalone]

#75794

On 11/11/2015 04:45 PM, jacobnavia wrote:
> Le 11/11/2015 22:19, Keith Thompson a écrit :
>> 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.
> 
> What about shorts?
> 
> 25987
> 
> Is that a short or an int?
> 
> How can I (without explicit cast) make it a short?

   short limit = 25987;

[toc] | [prev] | [next] | [standalone]

#75795

Le 11/11/2015 22:51, James Kuyper a écrit :
> On 11/11/2015 04:45 PM, jacobnavia wrote:
>> Le 11/11/2015 22:19, Keith Thompson a écrit :
>>> 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.
>>
>> What about shorts?
>>
>> 25987
>>
>> Is that a short or an int?
>>
>> How can I (without explicit cast) make it a short?
>
>     short limit = 25987;
>

I was speaking of course in the context of a _Generic expression

The problem is that there is no suffix to add to an integer constant in 
C to force it to a short int.

[toc] | [prev] | [next] | [standalone]

#75797

On 11/11/2015 05:01 PM, jacobnavia wrote:
> Le 11/11/2015 22:51, James Kuyper a écrit :
>> On 11/11/2015 04:45 PM, jacobnavia wrote:
>>> Le 11/11/2015 22:19, Keith Thompson a écrit :
>>>> 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.
>>>
>>> What about shorts?
>>>
>>> 25987
>>>
>>> Is that a short or an int?
>>>
>>> How can I (without explicit cast) make it a short?
>>
>>     short limit = 25987;
>>
> 
> I was speaking of course in the context of a _Generic expression

_Generic(limit, ...) works fine.

> The problem is that there is no suffix to add to an integer constant in 
> C to force it to a short int.

The possibility that you'll want to use integer constants as the second
argument is what makes it more reasonable to apply _Generic() to the
first argument than the second. It's dangerous to pass anything other
than a uint32_t* value as the first argument of _memset32(), so
requiring a cast to uint32_t* in those cases serves the useful purpose
of marking the code as dangerous.

Note: I'm not saying that you have to use _Generic(); merely defending
Philipp Klause Krause's suggest that you use it. I recommend replacing
the void* arguments with type-safe arguments, whether or not you choose
to use _Generic().

[toc] | [prev] | [next] | [standalone]

#75798

Le 11/11/2015 23:29, James Kuyper a écrit :
> I recommend replacing
> the void* arguments with type-safe arguments, whether or not you choose
> to use _Generic().

That's true. Thanks.

I will replace the first void * argument with type specific args.

[toc] | [prev] | [next] | [standalone]

#75800

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 11/11/2015 22:19, Keith Thompson a écrit :
>> 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.
>
> What about shorts?
>
> 25987
>
> Is that a short or an int?

That's an int.  The rules for determining the type of an integer
constant are in N1570 6.4.4.1; there are no integer constants of type
short.  I'm guessing the question was rhetorical; you write a C
compiler, so I presume you already know this.

> How can I (without explicit cast) make it a short?

Why do you say "without explicit cast"?  A cast is what I suggested
upthread: `(short)25987`.  If you don't like that for some reason:

    const short n = 25987;

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

[toc] | [prev] | [next] | [standalone]

#75792

On 11/11/2015 04:03 PM, jacobnavia wrote:
> 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.

In the previous message where you used the word "promoted", you gave the
supposed occurence of a promotion as a reason why _Generic couldn't be used:

> _Generic can't be used since
> 
> 'A' --> integer
> 120 --> integer also
> 
> You would never get a value less than int since all others are promoted 
> automatically

_Generic() can recognize types smaller than int (which, I presume, is
what you meant by "get a value less than int"), because promotions don't
occur in the argument of a _Generic() association.

#define Memset(dest, value, count) _Generic(value, \
    uint16_t: _memset16( (dest), (value), (count)),      \
    uint32_t: _memset32( (dest), (value), (count)),      \
    uint64_t: _memset64( (dest), (value), (count)),      \
    uint128_t:_memset128((dest), (value), (count))       \
    default: /* Error handling */)

All of the following cases should be correctly handled by Memset(),
assuming I wrote this correctly (this is untested code, and therefore
likely to contain errors):

    uint16_t ui16 = 12345;
    uint32_t ui32 = 1234567890;
    uint64_t ui64 = 12345678901234567890;
    uint128_t ui128 =
        123456789012345678901234567890123456789;
    uint16_t  array16[128];
    uint32_t  array32[ 64];
    uint64_t  array64[ 32];
    uint128_t array128[16];

    Memset(array16,  ui16, 128);
    Memset(array32,  ui32,  64);
    Memset(array64,  ui64,  32);
    Memset(array128, ui128, 16);

These, on the other hand, won't work:

    char c = 'A';
    // will trigger default: because the argument type is 'char'
    Memset(array16, c, 256);

   // will trigger default: because argument type is 'int'
    Memset(array16, 'A', 256);

However, that shouldn't matter, because with those values you probably
should be calling memset() rather than Memset().

[toc] | [prev] | [next] | [standalone]

#75796

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 11/11/2015 18:22, Ben Bacarisse a écrit :
>> The controlling expression of _Generic does not
>> undergo promotion.
>
> When you type
>
> 'A' in C it is the same as you would have typed "65".
>
> This is done in the lexical analysis phase.

I know.  I said that.  I was just correcting your statement about
promotion.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#75736

On 11/11/2015 05:05 AM, jacobnavia wrote:
> void *memset(void *srcPtr,unsigned char value,size_t size);
> 
> I want to add extensions to it:
> 
> void memset16( void *srcPtr, int16_t  value, size_t size);
> void memset32( void *srcPtr, int32_t  value, size_t size);
> void memset64( void *srcPtr, int64_t  value, size_t size);
> void memset128(void *srcPtr, int128_t value, size_t size);
> 
> Are the names OK? Or it would be better to just
> 
> void memsetShort(...);
> void memsetInt(...);
> void memsetLongLong(...);
> void memset128(...);
> 
> Microsoft has this functions as RTLFillMemory. I do not know if other 
> compilers support anything like this.
> 
> What do you think?

The standard has reserved the right to add new functions with any name
starting with "mem" to <string.h> (7.31.13p1).
If you're proposing that these be officially added to that header, then
you've chosen reasonable names.
If these are to be part of a conforming extension to the C library, they
should be given names that are a) reserved to the implementation and b)
have no chance of conflicting with those that might be added to
<string.h>. Have the names start with _mem rather than mem.
If this is to be part of a third-party library, rather than part of the
implementation, it should use names that are neither reserved to the
implementation nor reserved for future additions to <string.h>. Starting
with Mem rather than mem is one possibility.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web