Few questinos

[temper3243]

1) According to this
http://prokutfaq.byethost15.com/FindSizeWithoutSizeof

size_t size_type = (char*)((type*)0 + 1) - (char*)(type*)0;
Does this work for void type ? sizeof(void) is undefined but here we
get size of void * as
sizeof void.


int main()
{
size_t size=(char*)((int*)0 + 1) - (char*)(int*)0;
printf("Size of int = %u\n",size);
return 0;
}

Is this code correct ? We are subtracting pointers that are not within
the array.Undefined behaviour or
implementation defined ?


2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

 

[Ian Collins]

(e-mail address removed) wrote:

I'll leave part one to others

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

Because it is one or all of dangerous, daft, erroneous, lazy.

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

It could, but imagine the overhead involved in maintaining and searching
the table of pointers.

 

[Gordon Burditt]

1) According to this

http://prokutfaq.byethost15.com/FindSizeWithoutSizeof

ANSI C says you are allowed to use sizeof. This overrides
homework assignments which say you can't.

size_t size_type = (char*)((type*)0 + 1) - (char*)(type*)0;
Does this work for void type ?

I'll dispute that it "works" for any type.

sizeof(void) is undefined but here we
get size of void * as
sizeof void.

IMHO, p++ should be a no-op where p is a void * . That is,
sizeof(void) = 0, and p == p + i holds where p is a void *, i is
an integer, for any value of i. Either that, or it should be
equivalent to abort(). Either of those is a valid implementation
choice.

int main()
{
size_t size=(char*)((int*)0 + 1) - (char*)(int*)0;
printf("Size of int = %u\n",size);
return 0;
}

Is this code correct ?

No, for the reason you give below.

We are subtracting pointers that are not within
the array.Undefined behaviour or
implementation defined ?

Undefined behavior.

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

No, it's undefined. And if the implementation concentrates on speed
as opposed to sanity checking, the second free() call is likely to
cause a segfault or other type of memory access error on systems which
have such errors.

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

Why do all of the advocates of this forget that POINTERS CAN BE COPIED?

If I write linked-list routines, I'm going to have functions for
adding and deleting nodes from the linked list as separate functions.
They can set the passed parameter to NULL until they're blue in the
face, but it won't set the corresponding pointer in the calling
function to NULL. And there are plenty of other places where you're
NOT going to be able to find and eradicate all of the other copies
of the same pointer.

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

"Undefined behavior" includes the possibility that the implementation
checks and ignores stupid requests, or does what some people think
is the obvious "right thing to do". But don't count on that unless
you know something about the implementation. C programmers should
believe in the theory of Malevolent Design when thinking about
users, programmers, or operating systems.

 

[temper3243]

ANSI C says you are allowed to use sizeof. This overrides
homework assignments which say you can't.


I'll dispute that it "works" for any type.


IMHO, p++ should be a no-op where p is a void * . That is,
sizeof(void) = 0, and p == p + i holds where p is a void *, i is

Is sizeof(void) defined ? sizeof works for complete types not for
incomplete types. Atleast i get compilation error on Comeau c99.

 

[Gordon Burditt]

1) According to this

Is sizeof(void) defined ?

No, but some compilers give it a value anyway. GCC seems to use 1.
Further, pointer arithmetic seems to work like sizeof(void) is 1.

sizeof works for complete types not for
incomplete types. Atleast i get compilation error on Comeau c99.

That's also a valid implementation choice. I think I like it
better than what GCC does.

 

[Richard Heathfield]

(e-mail address removed) said:

1) According to this
http://prokutfaq.byethost15.com/FindSizeWithoutSizeof

size_t size_type = (char*)((type*)0 + 1) - (char*)(type*)0;

That page says nothing of the kind. You are misrepresenting it. The code on
that page is broken, but not as broken as yours.

Does this work for void type ? sizeof(void) is undefined but here we
get size of void * as
sizeof void.

Since sizeof(void *) is just the size of a pointer of a particular type, I'd
expect it to be 1 or 2 or 4 or 8 (not because it *must* be a power of 2,
but because it often is).

Since sizeof(void) is a constraint violation, I'd expect it to generate a
diagnostic message. If you're not getting one, your compiler is not a
conforming C compiler.

int main()
{
size_t size=(char*)((int*)0 + 1) - (char*)(int*)0;
printf("Size of int = %u\n",size);
return 0;
}

Is this code correct ?

No. It exhibits undefined behaviour in at least three ways:

1) calling a variadic function without a valid function prototype in scope.
2) pointer arithmetic on a null pointer.
3) passing a value of the wrong type to printf

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .
Why?

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

So what if there is? That doesn't mean all implementations are bound by that
definition.

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

What would be the point, apart from slowing programs down? 10ms is an
eternity in programming.

 

[Keith Thompson]

(e-mail address removed) (Gordon Burditt) writes:
^
|
|
See that, Gordon? It's called an attribution line. It's really a
simple concept.

[...]

IMHO, p++ should be a no-op where p is a void * . That is,
sizeof(void) = 0, and p == p + i holds where p is a void *, i is
an integer, for any value of i. Either that, or it should be
equivalent to abort(). Either of those is a valid implementation
choice.

Making sizeof(void) == 0 doesn't make much sense, IMHO. void is not a
type of size zero. If it were, an object of type void would have a
size of zero; in fact, an object of type void is simply an
impossibility.

 

[Nick Keighley]

(e-mail address removed) wrote:

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

I don't think this is possible

char* func()
{
char* s1 = malloc (100); /* check omitted */
char* s2;
do_it (s1);
free (s1);
s2 = malloc (100); /* the implementation may malloc
the same memory as s1 points
to */
free (s1);
return s2;
}

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

--
Nick Keighley

"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Chris Dollin]

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

Why do you want to restrict the implementation in this way?

A portable program couldn't use the knowledge anyway. A /non/-portable
program can use implementation-specific knowledge anyway. What do
you hope to gain?

[Perhaps you think that "undefined behaviour" means "some specific
thing", but what it means is, "the Standard imposes no constraints
whatsoever on the behaviour".]

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

Then it would be broken as well as providing a useless feature
in a clumsy way. The argument to `free` might (a) not have an
lvalue, eg be `f(x)`, so that the assignment is illegal, or (b)
have side-effects, which the macro would duplicate. Broken. There
may be other pointers to the same storage, and /they/ won't be
set to null; the nulling of /this/ pointer is a misleading illusion.
Useless. And /if/ you really really wanted to do this, you could
write it as `#define free(p) (libfree(p), (p) = NULL)` which means
you don't need the do-while gubbins. Clumsy.

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

> 2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);
What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

You have still called free() twice on the same pointer, and that's
what the standard says is undefined. What actually happens underneat,
is of little concern regarding this.

Remember that undefinded behavior doesn't mean "bad things WILL happen".

 

[Kenneth Brody]

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

Consider:

void *pointer = malloc(1);
FILE *f;
...
free(pointer);
f = fopen("foo.txt","r");
free(pointer);

What happens if fopen() mallocs a buffer, and happens to get the
same address to which pointer points?

You could make an argument that you can define it if the multiple
free's occur with no intervening memory management calls, but
only in that case. Even a simple:

free(pointer1);
free(pointer2);
free(pointer1);

becomes problematic.

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

I believe that an implementation is allowed to define what happens
if UB is invoked.

Also, the #define is broken. Among other things, "p" need not be
an l-value.

Finally, what happens when a second free() occurs 11ms later? (And
don't forget my fopen example above.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Greg Comeau]

No, but some compilers give it a value anyway. GCC seems to use 1.
Further, pointer arithmetic seems to work like sizeof(void) is 1.


That's also a valid implementation choice. I think I like it
better than what GCC does.

In strict mode (and even relaxed mode) "we" (Comeau C99) give a
diagnostic, but in gcc mode, we support the GNU extension that
it evaluate to 1. Note that I'm referring to sizeof(void),
not size(void *), the latter of which is fine, so long as it
is what is desired.

 

[David T. Ashley]

1) According to this
http://prokutfaq.byethost15.com/FindSizeWithoutSizeof

size_t size_type = (char*)((type*)0 + 1) - (char*)(type*)0;
Does this work for void type ? sizeof(void) is undefined but here we
get size of void * as
sizeof void.

The code above would work on all machines I'm familiar with, but I'm
uncomfortable with it. I can't think of a specific machine architecture on
which it would fail ... but why not just use sizeof()?

int main()
{
size_t size=(char*)((int*)0 + 1) - (char*)(int*)0;
printf("Size of int = %u\n",size);
return 0;
}

Is this code correct ? We are subtracting pointers that are not within
the array.Undefined behaviour or
implementation defined ?

The only "hard" flaw in the above I'm aware of is that size_t may not be
compatible with "%u". Other than that, it would work on any machine I'm
aware of. But the code makes me squirm.

2) According to standard freeing a pointer twice (not setting it to
NULL after first free) allocated
by malloc is undefined behaviour. Why ? Shouldn't it be implementation
defined .

(free'ing twice) is a separate issue from (setting the pointer to NULL after
the first free). One has nothing to do with the other.

The reason that free()'ing a pointer twice is undefined is that malloc(),
free() and friends are optimized this may cause the library to corrupt its
internal data structures.

What if there is a implementation where #define free(p) do{\
libfree(p);p=NULL; \} while(0);

This solves nothing. The program should be logically correct and free()
each allocated block of memory only once. The real question is why the
program is trying to free a block multiple times.

What if a free(p) that frees after sometime 10 ms
a) where it actually counts the number of frees to that pointer and
then frees it once

Um ... no. That is a library interface design question. The current
implementation of malloc(), free() and friends assume that a block will be
free()'d only once. That is a very reasonable assumption. It could be
changed (at the loss of some efficiency), but why change it? It seems
easier just to write programs that free() each block only once.

 

[CBFalconer]

.... snip ...

Um ... no. That is a library interface design question. The
current implementation of malloc(), free() and friends assume
that a block will be free()'d only once. That is a very
reasonable assumption. It could be changed (at the loss of
some efficiency), but why change it? It seems easier just to
write programs that free() each block only once.

At very heavy loss of efficiency. That would make it impossible to
combine freed blocks and then reallocate them as a larger block.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

 

[David T. Ashley]

At very heavy loss of efficiency. That would make it impossible to
combine freed blocks and then reallocate them as a larger block.

Good catch! I missed that! You'd never know when the last free() call for
a block. Yeah, that is just plain unworkable.

 

[CBFalconer]

Good catch! I missed that! You'd never know when the last free()
call for a block. Yeah, that is just plain unworkable.

It helps to have implemented several memory management systems.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

 

[Old Wolf]

(e-mail address removed) said:


That page says nothing of the kind. You are misrepresenting it.

Actually, the above code was copy-pasted from the above site
(it's about halfway down the page).

 

[Richard Heathfield]

Old Wolf said:

Actually, the above code was copy-pasted from the above site
(it's about halfway down the page).

So it was. My mistake - apologies to (e-mail address removed).