what about memset?

[Keith Thompson]

The binary notation means there's about 2-3v of electricity "turned on"
for 1 and "off" for 0. The absence or presence of an electrical charge.

Maybe. Or it means that there's 2-3v for 0 and "off" for 1. Or a
particular piece of iron oxide is magnetized in one way or an other.
Or there's a pit or lack of pit on the aluminum surface of a CD or
DVD. Or there is or isn't a hole in a punch card, or paper tape, or
mylar tape.

Files are stored as sequnces of 1s and 0s, typically (but not
necessarily) organized into bytes, typically (but not necessarily)
organized into blocks. But none of these details are relevant, as
long as the 0s and 1s stay the same when they're supposed to, and
change the way they're supposed to.

(Well, they can certainly become relevant if you're doing very
low-level programming, but I don't think you're doing that kind of
thing -- or should be.)

 

[Bill Cunningham]

For what it's worth, Intel C (and Fortran) are expanding the automatic
replacement of explicit 0 setting loops by memset(). Among other
implications, memset(), or an explicit loop eligible to be replaced by
memset(), are preferred over C++ equivalents.

The thing is that memset returns a void* and if I'm correct and could
very well not be, you can't really error check.

Bill

 

[Keith Thompson]

That's purely an implementation detail. Compilers are free to
generate whatever code they like (in this case, replacing an explicit
loop by a call to memset) as long as the effect is the same.

There may be some C++ issues here that I won't get into; beyond that,
see above.

The thing is that memset returns a void* and if I'm correct and could
very well not be, you can't really error check.

Right. It's up to the caller (whether it's user-written code or
compiler-generated code) to get the arguments right. Assuming that's
done, there are no detectable errors.

 

[Tim Prince]

I haven't seen a system where it didn't work, and C99 with the latest
corrections guarantees that it works for all integer types. For every
integer type, all value bits zero means the value is zero. There was
the possibility if integers had padding bits that all zero padding
bits would be a trap representation; the latest C99 version guarantees
that (all bits zero) is always a valid representation of the value
zero.

For what it's worth, Intel C (and Fortran) are expanding the automatic
replacement of explicit 0 setting loops by memset(). Among other
implications, memset(), or an explicit loop eligible to be replaced by
memset(), are preferred over C++ equivalents.

 

[Giorgos Keramidas]

I thought ASCII values are same for all platforms.

Yes, ASCII values are the same on all platforms that support the `ASCII'
standard and use it for the machine-specific representation of text.

The tricky part is that there are platforms out there that do not use
ASCII for representing text.

 

[Bill Cunningham]

Right. It's up to the caller (whether it's user-written code or
compiler-generated code) to get the arguments right. Assuming that's
done, there are no detectable errors.

I have also read that void* is the generic pointer. I am not quite sure
of this but the way I understand that is that somehow void* can also be a
pointer to any type so somehow one might be able to manipulate void* so that
it would be a char* or int* .

Bill

 

[Keith Thompson]

I have also read that void* is the generic pointer. I am not quite sure
of this but the way I understand that is that somehow void* can also be a
pointer to any type so somehow one might be able to manipulate void* so that
it would be a char* or int* .

Yes, of course. void* is a generic pointer type; you can convert a
pointer of any other type (other than a pointer-to-function) to void*
and back again without loss of information. Such conversions are
usually done implicitly, i.e., there's no need for a cast.

This has all been discussed here many many times.

 

[Giorgos Keramidas]

I have also read that void* is the generic pointer. I am not quite
sure of this but the way I understand that is that somehow void* can
also be a pointer to any type so somehow one might be able to
manipulate void* so that it would be a char* or int* .

If by `manipulate' you mean `assign to', then `yes' for `char *', but
`not necessarily' for `int *' . The `n1256.pdf' copy that I have
locally says:

§6.2.5 (27)

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.[39] Similarly,
pointers to qualified or unqualified versions of compatible types
shall have the same representation and alignment requirements. All
pointers to structure types shall have the same representation and
alignment requirements as each other. All pointers to union types
shall have the same representation and alignment requirements as each
other. Pointers to other types need not have the same representation
or alignment requirements.

[39] The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.

There are systems where `int *' pointers have stricter alignment
requirements from `char *' or `void *' pointers.

 

[vippstar]

I have also read that void* is the generic pointer. I am not quite
sure of this but the way I understand that is that somehow void* can
also be a pointer to any type so somehow one might be able to
manipulate void* so that it would be a char* or int* .

If by `manipulate' you mean `assign to', then `yes' for `char *', but
`not necessarily' for `int *' . The `n1256.pdf' copy that I have
locally says:

§6.2.5 (27)

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.[39] Similarly,
pointers to qualified or unqualified versions of compatible types
shall have the same representation and alignment requirements. All
pointers to structure types shall have the same representation and
alignment requirements as each other. All pointers to union types
shall have the same representation and alignment requirements as each
other. Pointers to other types need not have the same representation
or alignment requirements.

[39] The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.

There are systems where `int *' pointers have stricter alignment
requirements from `char *' or `void *' pointers.

That quote is for representations. If I understood correctly you used
that quote to support that the following is not valid?

void *p;
int *q;
/* ... */
p = q;
q = p;

In that case, you're wrong. It merely talks about representations.

 

[Bill Cunningham]

Yes, of course. void* is a generic pointer type; you can convert a
pointer of any other type (other than a pointer-to-function) to void*
and back again without loss of information. Such conversions are
usually done implicitly, i.e., there's no need for a cast.

This has all been discussed here many many times.

So does this mean I can get a return value somehow using memset ?

Bill

 

[Ian Collins]

So does this mean I can get a return value somehow using memset ?

Don't be daft (or obtuse?) read the declaration of memset, there's
nothing magical it its return value.

 

[Keith Thompson]

So does this mean I can get a return value somehow using memset ?

The documentation for memset will answer this question for you.

 

[Nick Keighley]

If that's the case, what is \0?

    It's supposed to mean null in addition to the string terminator.

but it doesn't. The nul *character* is spelt like this '\0'
(the single quotes are significant). \0 (without single quotes) is
meaningless

 

[Nick Keighley]

    When I want to clear memory space this is what I typically do myself,

char a[100];
int i;
for (i=0;i != 100;++i)
a='\0';

Now with the function memset I could do the same thing and it would be
portable. But would it always work?

how could it be "portable" and "not work"? What do you mean by these
words?

 

[Ben Bacarisse]

but it doesn't. The nul *character* is spelt like this '\0'

Nit (and it is a small one): The standard (correctly) calls it "the
null character". It has an abbreviated three-letter ASCII name, NUL,
but that is not how to refer to it in text. (Just as one would write,
in English, "the escape character" rather than "the esc character".)