memfrob and strfry ? OT

[Bill Cunningham]

My string.h headers declares two functions I have been using called
memfrob and strfry. They are encryption types functions. My man pages say
they are standard to linux c and gnu c. They sure aren't in my C books.
Interesting functions by they're OT here but this raises to me a question.
If a function returns a pointer to a void and and as it's first parameter a
pointer to a void. Then should that function's first parameter accept a
string or pointer to char or any other data type since the parameter is
declared a void * ?

Bill

 

[Richard Tobin]

My string.h headers declares two functions I have been using called
memfrob and strfry.

Laugh? I almost did.

-- Richard

 

[Bill Cunningham]

Laugh? I almost did.

-- Richard

<giggle> well it is kinda funny. Strfry looks like stirfry and memfrob
like some kind of frog. But no kidding they exist.

Bill

 

[Keith Thompson]

My string.h headers declares two functions I have been using called
memfrob and strfry. They are encryption types functions. My man pages say
they are standard to linux c and gnu c. They sure aren't in my C books.
Interesting functions by they're OT here but this raises to me a question.
If a function returns a pointer to a void and and as it's first parameter a
pointer to a void. Then should that function's first parameter accept a
string or pointer to char or any other data type since the parameter is
declared a void * ?

Since you're asking about what it accepts as an argument, the type
that it returns is irrelevant. And since strfry() takes an argument
of type char* and returns a char* result, it's also irrelevant. The
only thing you're asking about is the first parameter of memfrob().

For reference, the declaration is:

void *memfrob(void *s, size_t n);

(The function itself is off-topic; the fact that you can declare a
function like that is not. The use of a name starting with "mem"
raises some issues that I'll ignore.)

Any pointer type (other than a pointer-to-function type) can be
implicitly converted to void*. So the first argument in a call to
memfrob() can be an expression of any pointer type other than a
pointer-to-function type. (This includes array expressions, such as
string literals, which are converted to pointer values.) It can also
be a null pointer constant, such as the macro NULL or a literal 0
(though you wouldn't want to pass a null pointer to memfrob()).

 

[Bill Cunningham]

[snip]

Any pointer type (other than a pointer-to-function type) can be
implicitly converted to void*. So the first argument in a call to
memfrob() can be an expression of any pointer type other than a
pointer-to-function type. (This includes array expressions, such as
string literals, which are converted to pointer values.) It can also
be a null pointer constant, such as the macro NULL or a literal 0
(though you wouldn't want to pass a null pointer to memfrob()).

Thank you Keith. So if I wanted a function to return any number of types
as well as a void should a function return a void? That's my question.

Bill

 

[Keith Thompson]

[snip]

Any pointer type (other than a pointer-to-function type) can be
implicitly converted to void*. So the first argument in a call to
memfrob() can be an expression of any pointer type other than a
pointer-to-function type. (This includes array expressions, such as
string literals, which are converted to pointer values.) It can also
be a null pointer constant, such as the macro NULL or a literal 0
(though you wouldn't want to pass a null pointer to memfrob()).

Thank you Keith. So if I wanted a function to return any number
of types as well as a void should a function return a void? That's
my question.

No, that's an entirely new question, to which the answer is no.

A function declared to return void doesn't return anything.

A function declared to return void* (a very different thing from void)
returns what you can think of as a generic pointer; it can point to
any object. But to do that, there has to be an object for it to point
to, (which means you have think about allocating and deallocating it),
and you have to know somehow what type it points to if you want to do
anything with it.

What problem are you trying to solve? It's very likely that "a
function to return any number of types" isn't the right solution.

 

[Bill Cunningham]

[snip]

What problem are you trying to solve? It's very likely that "a
function to return any number of types" isn't the right solution.

I've been working with this OT function memfrb. It's a type I've never
encountered. I wouldn't know how in C to take a block of memory I tried 64
bytes the partition table I saved from a mbr. I thought I'd use this to
encypt some bytes. Closest I got was some garbage and a segmention fault.

void *pv;
pv=memfrb("file",64);
printf("%s\n",pv);

Didn't work.

printf("%s\n",(memfrob("b",64));

didn't work. How would you use this type of function? Not so much memfrob
but a function that returned a void* and took a void*s as a first parameter.
I've never worked with voids is the simple statement. I wouldn't know what
to do with this one.

Bill

 

[Keith Thompson]

[snip]

What problem are you trying to solve? It's very likely that "a
function to return any number of types" isn't the right solution.

I've been working with this OT function memfrb. It's a type I've never
encountered. I wouldn't know how in C to take a block of memory I tried 64
bytes the partition table I saved from a mbr. I thought I'd use this to
encypt some bytes. Closest I got was some garbage and a segmention fault.

void *pv;
pv=memfrb("file",64);
printf("%s\n",pv);

It's "memfrob", not "memfrb". This typo indicates that you didn't
copy-and-paste your actual code, so I can't reliably infer anything.

Again, for reference, the declaration is:

void *memfrob(void *s, size_t n);

It's a very very poor encryption routine (it merely xors each byte
with the number 42). It can defeat a rudimentary attempt to search
for readable strings, nothing more.

Didn't work.

Well of course it didn't work. Your call

memfrob("file", 64);

attempts to modify the first 64 bytes of the string literal "file".
This immediately invokes undefined behavior by (a) attempting to
modify a string literal, and (b) attempting to modify 64 bytes of a
5-byte object.

If you want to "encrypt" data from a file, you first need to open the
file, and then read the data from the file. Passing the string "file"
to memfrob(), or to any other non-I/O function, will not magically
access a file named "file".

printf("%s\n",(memfrob("b",64));

And what is "b" supposed to be?

didn't work. How would you use this type of function? Not so much memfrob
but a function that returned a void* and took a void*s as a first parameter.
I've never worked with voids is the simple statement. I wouldn't know what
to do with this one.

Ok, you want to learn about void*.

My advice: Forget about memfrob(). It's non-standard, and it doesn't
do anything particularly useful. Take a look at the various standard
mem*() functions: memcpy, memmove, memcmp, memchr, memset. To start
learning about them, read a book.

 

[Spiros Bousbouras]

My string.h headers declares two functions I have been using called
memfrob and strfry. They are encryption types functions. My man pages say
they are standard to linux c and gnu c. They sure aren't in my C books.
Interesting functions by they're OT here but this raises to me a question.
If a function returns a pointer to a void and and as it's first parameter a
pointer to a void. Then should that function's first parameter accept a
string or pointer to char or any other data type since the parameter is
declared a void * ?

What you should pass as a first parameter depends on what the function
does. For example realloc() accepts as a first parameter void * but
you
cannot pass anything you want to it , it has to be either NULL or a
pointer previously returned by malloc() or realloc().

How would you use this type of function? Not so much memfrob
but a function that returned a void* and took a void*s as a first parameter.
I've never worked with voids is the simple statement. I wouldn't know what
to do with this one.

Find some code which uses realloc() and study it.

 

[Spiros Bousbouras]

<SNIP>

Any pointer type (other than a pointer-to-function type) can be
implicitly converted to void*.

Of course on Linux a void * can hold even pointers to functions.

 

[Default User]

Laugh? I almost did.

I had Hunan chicken for lunch. Oh wait, that's stir-fry.





Brian

 

[Antoninus Twink]

Of course on Linux a void * can hold even pointers to functions.

And more generally on POSIX. Actually, like so many things, this is
really Not A Problem in real life, but the clc regulars try to make it
into a problem so that they've got something to beef about.

 

[Bill Cunningham]

Ok, you want to learn about void*.

My advice: Forget about memfrob(). It's non-standard, and it doesn't
do anything particularly useful. Take a look at the various standard
mem*() functions: memcpy, memmove, memcmp, memchr, memset. To start
learning about them, read a book.

Here's what I have learned. Sec 5.4 pg 103. "...except for void *, to
assign a pointer of one type to a pointerr of another type withou a
cast." --k and r 2

Bill

 

[Bill Cunningham]

Find some code which uses realloc() and study it.

That's the thing. I can't find any. I have about 64 bytes worth of
partition table data I can play with. According to what I've read this
function changes the size somehow.

Bill

 

[Harald van Dijk]

And more generally on POSIX.

Wrong.

 

[Antoninus Twink]

Wrong.

In that case, what do you do with the void * returned by dlsym()? Put it
on a shelf and admire its object-pointer-ness?

 

[Keith Thompson]

Wrong.

<OT>
See <http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html>,
particularly the rationale section.
</OT>

 

[Kenny McCormack]

In that case, what do you do with the void * returned by dlsym()? Put it
on a shelf and admire its object-pointer-ness?

Is dlsym() POSIX?

I would assume that that is the picky point being made. And I would
assume that the answer is "no", FSVO "POSIX".

Probably some early draft release...

 

[Harald van Dijk]

<OT>
See
<http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html>,
particularly the rationale section.

POSIX does not require implementations to support dlsym; see the synopsis.

</OT>

Getting back on topic, the rationale is wrong about the C standard. It
states:

"Note that compilers conforming to the ISO C standard are required to
generate a warning if a conversion from a void * pointer to a function
pointer is attempted as in:
fptr = (int (*)(int))dlsym(handle, "my_function");"

This is not a syntax error and violates no constraints. While the C
standard does not define the behaviour of a conversion from void * to a
function pointer type, it allows implementations to accept them without
any diagnostic. The only constraint on casts is that both types involved
are scalar. void * is, and so is int(*)(int). In fact, I'm not even sure
if implementations are allowed to reject the cast (even though some do)
unless they can prove the code will always be reached.

 

[Walter Roberson]

Getting back on topic, the rationale is wrong about the C standard. It
states:

"Note that compilers conforming to the ISO C standard are required to
generate a warning if a conversion from a void * pointer to a function
pointer is attempted as in:
fptr = (int (*)(int))dlsym(handle, "my_function");"

This is not a syntax error and violates no constraints.

It is not one of the allowed casts in C89 3.3.4 Cast Operators.
C89 3.3.4 allows pointers to function types to be converted
to pointers to other function types, but there is no provision
there for conversion between function type and void*.

The conversions for void* are described in C89 3.2.2.3 Pointers,
which only describes the conversions between void* and pointers
to objects or pointer to incomplete types.

If your point is that there isn't any paragraph that specifically
says that it is not permissible to convert between void* and function
pointers, then that would be correct, but neither does the C89
standard specifically make the result implementation defined. I take
it then, that you are going for a "That which is not forbidden is
permissible" interpretation ?