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 17  1223  te********@gmail.com 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.
--
Ian Collins.
>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.
Gordon Burditt wrote:
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
Is sizeof(void) defined ? sizeof works for complete types not for
incomplete types. Atleast i get compilation error on Comeau c99.
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.
>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
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. te********@gmail.com 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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www. go***********@burditt.org (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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. te********@gmail.com wrote:
<snip>
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 te********@gmail.com 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 .
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.
--
Chris "3 out of 3 need not be a /good/ thing" Dollin
Nit-picking is best done among friends. te********@gmail.com 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 .
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".
In article <12*************@corp.supernews.com>,
Gordon Burditt <go***********@burditt.orgwrote:
>>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
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.
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.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it? te********@gmail.com 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 .
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:Th*************@gmail.com>
<te********@gmail.comwrote in message
news:11**********************@38g2000cwa.googlegro ups.com...
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.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
"David T. Ashley" wrote:
>
.... 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>
"CBFalconer" <cb********@yahoo.comwrote in message
news:45***************@yahoo.com...
"David T. Ashley" wrote:
>>
... 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.
Good catch! I missed that! You'd never know when the last free() call for
a block. Yeah, that is just plain unworkable.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
"David T. Ashley" wrote:
"CBFalconer" <cb********@yahoo.comwrote in message
>"David T. Ashley" wrote:
>>>
... 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.
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> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jbailo |
last post by:
I just tore down my mandrake 91
home puter and installed rh91 instead.
i must have had a bad rh91 d1, because
i began this process a week or two ago
and so haven't been online from home
since...
|
by: Arto Viitanen |
last post by:
What is the best way to implement three value data, where the values are
no/yes/not applicable ?
I have used bool?, but I remember seeing some class (or most likely
enum) on .net for this.
--...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
