Date: Fri, 19 Aug 2005 14:43:17 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Dmitry Mityugov <dmitry.mityugov@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: man malloc Message-ID: <20050819114317.GA2675@flame.pc> In-Reply-To: <b7052e1e05081904006a65f210@mail.gmail.com> References: <4303A632.1000809@FreeBSD.org> <4303B016.3030201@mac.com> <43044212.20909@FreeBSD.org> <20050818125348.GG1282@flame.pc> <b7052e1e05081811172b36182e@mail.gmail.com> <20050818214003.GA687@flame.pc> <b7052e1e05081904006a65f210@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-08-19 15:00, Dmitry Mityugov <dmitry.mityugov@gmail.com> wrote:
>On 8/19/05, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>>On 2005-08-18 22:17, Dmitry Mityugov <dmitry.mityugov@gmail.com> wrote:
>>>On 8/18/05, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>>>> It may be surprising, but casting back and forth *MAY* change the
>>>> value of the pointer.
>>>> ...
>>>
>>> Could you back up this assertion with an example, please?
>>
>> Do I really have to?
>> ...
>
> I just wanted to learn something new. Please, post an example if you can.
There is an easy to reproduce case, when running executables of certain
"memory models" in MS-DOS. Many users forget that function pointers are
*NOT* the same as object pointers. They generally happen to "just work"
on most UNIX machines, but they are not the same at all.
For instance, this will tend to work on FreeBSD:
1 #include <assert.h>
2 #include <stdio.h>
3 #include <stdlib.h>
4
5 static int increase(int *);
6 static int decrease(int *);
7
8 typedef int (*fptr_t)(int *);
9
10 int
11 main(void)
12 {
13 int k, oval, val;
14 char *p[] = { (char *)increase, (char *)decrease, };
15 fptr_t fptr;
16
17 val = 0;
18 for (k = 0; k < 10; k++) {
19 fptr = (fptr_t)(p[rand() % 2]);
20 oval = fptr(&val);
21 printf("%3d -> %3d\n", oval, val);
22 }
23 return (0);
24 }
25
26 int
27 increase(int *xp)
28 {
29 int old;
30
31 assert(xp != NULL);
32 old = *xp;
33 *xp += 1;
34 return (old);
35 }
36
37 int
38 decrease(int *xp)
39 {
40 int old;
41
42 assert(xp != NULL);
43 old = *xp;
44 *xp -= 1;
45 return (old);
46 }
On most UNIX installations I've seen, the (char *) pointers at line 14
can save the address of a function, even though this is not allowed by
the C standard. If you build this with GCC using the -std=c89 -pedantic
options, a warning *IS* printed both for the dubious casts of function
pointers to (char *) in line 14 and for the cast back to a function
pointer (simplified a bit through a typedef) at line 19:
% foo.c: In function `main':
% foo.c:14: warning: ISO C forbids conversion of function pointer to object pointer type
% foo.c:14: warning: ISO C forbids conversion of function pointer to object pointer type
% foo.c:19: warning: ISO C forbids conversion of object pointer to function pointer type
Having said that this is *NOT* standard C, now I can tell you why this may
bite you in bad ways on some environments, even though it just happens to work
on FreeBSD, Linux and Solaris, if you build the program without all the
warnings of -std=c89.
When programming with certain "memory models" in DOS though, you may find that
a pointer to a function requires 32 bits of storage, while a pointer to the
data area of the program requires only 16 (because, for instance, the program
has a very large code area but it has only one 65 KB segment for storing data).
In that case, a function pointer that is "coerced" into a (char *) may
end up being trimmed. When you "coerce" it back to a function pointer
it will almost certainly point to the wrong place. That's not very good.
- Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050819114317.GA2675>