Forum unknown
· Programming
Contemplating the void *
41 messages in this thread
In the Manx header file <functions.h> is the following declaration: void
*AllocMem();
I've asked around a little bit, and what this seems to mean is that (to Manx)
AllocMem returns an address that may point to whatever you want it to– that
the pointer is not assigned to any particular type, and may be explicitly or
implicitly cast.
If this is true, and (void *) is Manx's general-purpose pointer, it might be
a good idea to change <exec/types.h> so that APTR (which seems to be Exec's
generic pointer form) is declared as void *. Right now, APTR assignments
generally invoke warnings from the Manx compiler. (Try assigning a pointer to
IOStdReq.io_data, which is APTR.) I experimented by changing IOStdReq.io_data
from APTR to void *, and eliminated warnings about ptr/ptr assignments.
(IOStdReq.io_data is surely an instance where all sorts of data will be
pointed to, and where no single type declaration will suffice.) Any thoughts
on this? -Steve
As I recall the specification of the void type, it generally means, at least
in a function definition, like void foo(), etc. that NO VALUE is returned at
all, or at least nothing meaningful. I'm not sure about void *. But if manx
uses it as a generic type, it MAY not be portable. Also, my C book tells me
that any type may be cast to void, but that void may not be cast to anything.
I don't know if this also applies to void *, but it seems possible. Maybe
someone out there knows the official K&R position on this. I kind of like
thinking of an untyped area of memory as UBYTE * or something like that, in
that it really implies no special meaning to that area (unlike char, int,
float, etc.); this is just a personal pref. -Dave Haynie
Hi, Dave. Just poping in and I saw your message… As far as I know, VOID is
DEFined as "int." The only reason that they use VOID at all is to let others
know that the int value returned isn't used… One of the fundamental
principles of C is that every "subroutine" is a function– and all of C's
functions ALWAYS return a value.
VOID may be an int, but "VOID" is a #define or typedef involving another
intrinsic type. The type "void" was added to C after the original K&R book.
A compiler implements void as an intrinsic type, and a type of void
function(); returns NO value, like a PASCAL function. Lots of folks use VOID
as a compiler independent version of void — if my compiler supports void, my
ctypes file says #define VOID void, otherwise I say #define VOID int. Of
course, if I define VOID as int, I'm not going to be fully portable. If I
use VOID (= int) as a generic pointer, I'll definately run into trouble in
Aztec C unless I redefine VOID long int. -Dave Haynie
you sure about that dave? i think that a function declared of type void does
indeed return a function. the void is just a polite way of indicating to all
involved that the function return value is meaningless. (sorry, make last
word of 2nd sentence “value''.) i know with deficient compilers, its a good
habit to typedef or #define void to int to ease the porting of proper
lintable code to the deficient compiler. wish one of the lattice or manx
authors could give us definative answer. sdp
you sure about that dave? i think that a function declared of type void does
indeed return a function. the void is just a polite way of indicating to all
involved that the function return value is meaningless. (sorry, make last
word of 2nd sentence “value''.) i know with deficient compilers, its a good
habit to typedef or #define void to int to ease the porting of proper
lintable code to the deficient compiler. wish one of the lattice or manx
authors could give us definative answer. sdp
VOID may be an int, but "VOID" is a #define or typedef involving another
intrinsic type. The type "void" was added to C after the original K&R book.
A compiler implements void as an intrinsic type, and a type of void
function(); returns NO value, like a PASCAL function. Lots of folks use VOID
as a compiler independent version of void — if my compiler supports void, my
ctypes file says #define VOID void, otherwise I say #define VOID int. Of
course, if I define VOID as int, I'm not going to be fully portable. If I
use VOID (= int) as a generic pointer, I'll definately run into trouble in
Aztec C unless I redefine VOID long int. -Dave Haynie
Hi, Dave. Just poping in and I saw your message… As far as I know, VOID is
DEFined as "int." The only reason that they use VOID at all is to let others
know that the int value returned isn't used… One of the fundamental
principles of C is that every "subroutine" is a function– and all of C's
functions ALWAYS return a value.
As I recall the specification of the void type, it generally means, at least
in a function definition, like void foo(), etc. that NO VALUE is returned at
all, or at least nothing meaningful. I'm not sure about void *. But if manx
uses it as a generic type, it MAY not be portable. Also, my C book tells me
that any type may be cast to void, but that void may not be cast to anything.
I don't know if this also applies to void *, but it seems possible. Maybe
someone out there knows the official K&R position on this. I kind of like
thinking of an untyped area of memory as UBYTE * or something like that, in
that it really implies no special meaning to that area (unlike char, int,
float, etc.); this is just a personal pref. -Dave Haynie
As I recall the specification of the void type, it generally means, at least
in a function definition, like void foo(), etc. that NO VALUE is returned at
all, or at least nothing meaningful. I'm not sure about void *. But if manx
uses it as a generic type, it MAY not be portable. Also, my C book tells me
that any type may be cast to void, but that void may not be cast to anything.
I don't know if this also applies to void *, but it seems possible. Maybe
someone out there knows the official K&R position on this. I kind of like
thinking of an untyped area of memory as UBYTE * or something like that, in
that it really implies no special meaning to that area (unlike char, int,
float, etc.); this is just a personal pref. -Dave Haynie
As I recall the specification of the void type, it generally means, at least
in a function definition, like void foo(), etc. that NO VALUE is returned at
all, or at least nothing meaningful. I'm not sure about void *. But if manx
uses it as a generic type, it MAY not be portable. Also, my C book tells me
that any type may be cast to void, but that void may not be cast to anything.
I don't know if this also applies to void *, but it seems possible. Maybe
someone out there knows the official K&R position on this. I kind of like
thinking of an untyped area of memory as UBYTE * or something like that, in
that it really implies no special meaning to that area (unlike char, int,
float, etc.); this is just a personal pref. -Dave Haynie
I don't really like the way Manx did this – I think it is going to cause some
portability problems. Whatever happened to the old practice of declaring a
function as char * or unsigned char *, and then using casts?? I much prefer
this way… Works fine, too. In the latest mass of loose sheets from c-a,
wasn't there something about not using APTR anymore?? I'll have to check…
sdb
Scott, Now that I go back and recheck, I don't get undue warnings (in testfiles
anyway). See msg # 12881.
The warnings I was getting came from a program that had been compiling clean
with Lattice. I was getting warnings in things like IntuiText.IText and
NewWindow.Title. I thought I had tried casting (worked with Lattice, right?)
but now I'm not sure. I'll check again… I don't get loose sheets from C-A;
if they say "don't use APTR" that's good to know. Maybe this means that
they're going to do some revision of the header files, and things like UBYTE
*IntuiText.IText; will be cleared up so that some castings are unnecessary.
For myself, I've gone through <intuition.h> and changed all text pointers to
char *. I've also gone ahead and changed APTR to void * in <exec/types.h>.
("I'd rather see only the Meaningful warnings," he said arrogantly, "and not
be blinded by this picayune stuff.")
It's my feeling (subject to challenge) that <exec/types.h> exists mostly to
shield the programmer from the particular implementation of the compiler, and
should be adapted as necessary. Please set me straight on this if I'm wrong.
-Steve
You are probably right about exec/types.h being used to help increase
portability of code, but personally, I think you may be making a mistake in
making those changes. For example, if you shift an unsigned byte, you have a
shifted byte but if you shift a signed character, lot'sa compilers willl sign
extend, so you don't get what you are after. You might be safe with the APTR
* void, but I would change back the stuff that is UBYTE etc. Just what I
think. sdb
.
P.S. (To use IntuiText etc. with manx, just do (UBYTE *)"Text". Same with
window titles, etc. Works fine for me…
I'm puzzled about <intuition.h>'s tendency to type text as UBYTE in the
first place. If it's always gonna be text, why should it be unsigned? Is
IntuiText.IText ever going to be anything besides text strings? I have the
sneaking suspicion that RJ and company were preparing for a contingency that
won't occur, that is, having text pointers like Intuitext.IText and
Window.Title point to data other than text. In fact, when there is an
ambiguous pointer, f'rinstance, MenuItem.SelectFill, it's typed as APTR.
-Steve
I think that indeed they are thinking into the future Steve. There is a bit
of a hint somewhere in the Intuition manual that says we will not always be
limited to text in menu titles, but can put pretty pics in there someday.
You CAN put pics into menus right now… Just use an Image structure. (Maybe
they were going to extend it to Border structs????).
You CAN put pics into menus right now… Just use an Image structure. (Maybe
they were going to extend it to Border structs????).
I think that indeed they are thinking into the future Steve. There is a bit
of a hint somewhere in the Intuition manual that says we will not always be
limited to text in menu titles, but can put pretty pics in there someday.
Well, I think that maybe you will have pointers to stuff that isn't text
someday. Besides, I think text should be unsigned. Period. I hate this
default to signed characters in most new compilers. Maybe they don't like it
either. Not all ambiguous pointers are APTR – look at the UserData field in
the Window struct, for example. (Now, that seems to me like it should have
been APTR. Oh well…) sdb
Yes but what pointers have to be long-word aligned (4 byte). B(etter) C(heck)
P(ointers) to L(ongs). <heheheh>
But you only have to worry about that kind of thing when dealing with
<B>letcherous & <C>rufty <P>rogramming <L>anguages. <yuk yuk>
{B>ig <C>omputer <P>rograms <L>ost
<B>ritians <C>ontribution to <P>rogramming <L>anguages.
How about this in the BCPL monicker race….
<B>ulls**t with many <C>omplaints from <P>rogrammers about this <L>anguage?
How about this in the BCPL monicker race….
<B>ulls**t with many <C>omplaints from <P>rogrammers about this <L>anguage?
<B>ritians <C>ontribution to <P>rogramming <L>anguages.
{B>ig <C>omputer <P>rograms <L>ost
But you only have to worry about that kind of thing when dealing with
<B>letcherous & <C>rufty <P>rogramming <L>anguages. <yuk yuk>
Yes but what pointers have to be long-word aligned (4 byte). B(etter) C(heck)
P(ointers) to L(ongs). <heheheh>
Well, I think that maybe you will have pointers to stuff that isn't text
someday. Besides, I think text should be unsigned. Period. I hate this
default to signed characters in most new compilers. Maybe they don't like it
either. Not all ambiguous pointers are APTR – look at the UserData field in
the Window struct, for example. (Now, that seems to me like it should have
been APTR. Oh well…) sdb
I'm puzzled about <intuition.h>'s tendency to type text as UBYTE in the
first place. If it's always gonna be text, why should it be unsigned? Is
IntuiText.IText ever going to be anything besides text strings? I have the
sneaking suspicion that RJ and company were preparing for a contingency that
won't occur, that is, having text pointers like Intuitext.IText and
Window.Title point to data other than text. In fact, when there is an
ambiguous pointer, f'rinstance, MenuItem.SelectFill, it's typed as APTR.
-Steve
You are probably right about exec/types.h being used to help increase
portability of code, but personally, I think you may be making a mistake in
making those changes. For example, if you shift an unsigned byte, you have a
shifted byte but if you shift a signed character, lot'sa compilers willl sign
extend, so you don't get what you are after. You might be safe with the APTR
* void, but I would change back the stuff that is UBYTE etc. Just what I
think. sdb
.
P.S. (To use IntuiText etc. with manx, just do (UBYTE *)"Text". Same with
window titles, etc. Works fine for me…
Scott, Now that I go back and recheck, I don't get undue warnings (in testfiles
anyway). See msg # 12881.
The warnings I was getting came from a program that had been compiling clean
with Lattice. I was getting warnings in things like IntuiText.IText and
NewWindow.Title. I thought I had tried casting (worked with Lattice, right?)
but now I'm not sure. I'll check again… I don't get loose sheets from C-A;
if they say "don't use APTR" that's good to know. Maybe this means that
they're going to do some revision of the header files, and things like UBYTE
*IntuiText.IText; will be cleared up so that some castings are unnecessary.
For myself, I've gone through <intuition.h> and changed all text pointers to
char *. I've also gone ahead and changed APTR to void * in <exec/types.h>.
("I'd rather see only the Meaningful warnings," he said arrogantly, "and not
be blinded by this picayune stuff.")
It's my feeling (subject to challenge) that <exec/types.h> exists mostly to
shield the programmer from the particular implementation of the compiler, and
should be adapted as necessary. Please set me straight on this if I'm wrong.
-Steve
Scott, Now that I go back and recheck, I don't get undue warnings (in testfiles
anyway). See msg # 12881.
The warnings I was getting came from a program that had been compiling clean
with Lattice. I was getting warnings in things like IntuiText.IText and
NewWindow.Title. I thought I had tried casting (worked with Lattice, right?)
but now I'm not sure. I'll check again… I don't get loose sheets from C-A;
if they say "don't use APTR" that's good to know. Maybe this means that
they're going to do some revision of the header files, and things like UBYTE
*IntuiText.IText; will be cleared up so that some castings are unnecessary.
For myself, I've gone through <intuition.h> and changed all text pointers to
char *. I've also gone ahead and changed APTR to void * in <exec/types.h>.
("I'd rather see only the Meaningful warnings," he said arrogantly, "and not
be blinded by this picayune stuff.")
It's my feeling (subject to challenge) that <exec/types.h> exists mostly to
shield the programmer from the particular implementation of the compiler, and
should be adapted as necessary. Please set me straight on this if I'm wrong.
-Steve
Scott, Now that I go back and recheck, I don't get undue warnings (in testfiles
anyway). See msg # 12881.
The warnings I was getting came from a program that had been compiling clean
with Lattice. I was getting warnings in things like IntuiText.IText and
NewWindow.Title. I thought I had tried casting (worked with Lattice, right?)
but now I'm not sure. I'll check again… I don't get loose sheets from C-A;
if they say "don't use APTR" that's good to know. Maybe this means that
they're going to do some revision of the header files, and things like UBYTE
*IntuiText.IText; will be cleared up so that some castings are unnecessary.
For myself, I've gone through <intuition.h> and changed all text pointers to
char *. I've also gone ahead and changed APTR to void * in <exec/types.h>.
("I'd rather see only the Meaningful warnings," he said arrogantly, "and not
be blinded by this picayune stuff.")
It's my feeling (subject to challenge) that <exec/types.h> exists mostly to
shield the programmer from the particular implementation of the compiler, and
should be adapted as necessary. Please set me straight on this if I'm wrong.
-Steve
Scott, Now that I go back and recheck, I don't get undue warnings (in testfiles
anyway). See msg # 12881.
The warnings I was getting came from a program that had been compiling clean
with Lattice. I was getting warnings in things like IntuiText.IText and
NewWindow.Title. I thought I had tried casting (worked with Lattice, right?)
but now I'm not sure. I'll check again… I don't get loose sheets from C-A;
if they say "don't use APTR" that's good to know. Maybe this means that
they're going to do some revision of the header files, and things like UBYTE
*IntuiText.IText; will be cleared up so that some castings are unnecessary.
For myself, I've gone through <intuition.h> and changed all text pointers to
char *. I've also gone ahead and changed APTR to void * in <exec/types.h>.
("I'd rather see only the Meaningful warnings," he said arrogantly, "and not
be blinded by this picayune stuff.")
It's my feeling (subject to challenge) that <exec/types.h> exists mostly to
shield the programmer from the particular implementation of the compiler, and
should be adapted as necessary. Please set me straight on this if I'm wrong.
-Steve
Scott, Now that I go back and recheck, I don't get undue warnings (in testfiles
anyway). See msg # 12881.
The warnings I was getting came from a program that had been compiling clean
with Lattice. I was getting warnings in things like IntuiText.IText and
NewWindow.Title. I thought I had tried casting (worked with Lattice, right?)
but now I'm not sure. I'll check again… I don't get loose sheets from C-A;
if they say "don't use APTR" that's good to know. Maybe this means that
they're going to do some revision of the header files, and things like UBYTE
*IntuiText.IText; will be cleared up so that some castings are unnecessary.
For myself, I've gone through <intuition.h> and changed all text pointers to
char *. I've also gone ahead and changed APTR to void * in <exec/types.h>.
("I'd rather see only the Meaningful warnings," he said arrogantly, "and not
be blinded by this picayune stuff.")
It's my feeling (subject to challenge) that <exec/types.h> exists mostly to
shield the programmer from the particular implementation of the compiler, and
should be adapted as necessary. Please set me straight on this if I'm wrong.
-Steve
I don't really like the way Manx did this – I think it is going to cause some
portability problems. Whatever happened to the old practice of declaring a
function as char * or unsigned char *, and then using casts?? I much prefer
this way… Works fine, too. In the latest mass of loose sheets from c-a,
wasn't there something about not using APTR anymore?? I'll have to check…
sdb
I don't really like the way Manx did this – I think it is going to cause some
portability problems. Whatever happened to the old practice of declaring a
function as char * or unsigned char *, and then using casts?? I much prefer
this way… Works fine, too. In the latest mass of loose sheets from c-a,
wasn't there something about not using APTR anymore?? I'll have to check…
sdb
I don't really like the way Manx did this – I think it is going to cause some
portability problems. Whatever happened to the old practice of declaring a
function as char * or unsigned char *, and then using casts?? I much prefer
this way… Works fine, too. In the latest mass of loose sheets from c-a,
wasn't there something about not using APTR anymore?? I'll have to check…
sdb