473,903 Members | 4,817 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Deferencing void pointer

I can't believe I've been trying to work this out for hours now, and I
can't believe I couldn't find someone asking for a similar solution in
the newsgroups. No wonder I hate C so much, and every time I get the
textbooks out end up throwing them against the wall in rage. Thats
been going on for 10 years now.

Anyway, I have:

typedef struct _record {
int age;
} record;

typedef struct _LinkedList {
void *data;
struct _LinkedList *next;
} LinkedList;

I can add items to my linked list, traverse the list etc. However I
CANNOT get the data OUT of the list.

curr_ptr = head;
while ( curr_ptr != NULL ) {
printf ("traverse: this=%p data=%d\n",
curr_ptr, curr_ptr->data->age);
}

This results in the error:
warning: deferencing 'void *' pointer
request for member 'age' in something not a structure or union.

I know I have to cast it or something.... but I just can't figure it
out!
Arrgh!

Doug
Nov 13 '05
52 5681
On 21 Nov 2003 20:20:29 GMT, in comp.lang.c , Alex
<al*******@hotm ail.com> wrote:
CBFalconer <cb********@yah oo.com> wrote:
Alex wrote:
Sheldon Simms <sh**********@y ahoo.com> wrote:

> How is (0 == X) any less logical than (X == 0)?

How many times have you said aloud "if 0 is equal to X then ..."?
In languages other than C, how many times have you said:
if (0 <= x <= 3) then ....


This is an entirely different issue.


Not really, You attempted to show that English usage should govern how
C is written. Chuck showed why thats a false idea.
Your example is traditional mathematical notation.
so is if (x ==0) . Your point seems null.
If this was a feature of C, I /would/ use
t'would be nice wouldn't it?
A more relevant subsection of your example would be

if (0 <= x)

which, to me, is unreadable.
Its not uncommon to see this sort of expression in maths.


Alex


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
Nov 13 '05 #41
Mark McIntyre <ma**********@s pamcop.net> wrote:
On 21 Nov 2003 20:20:29 GMT, in comp.lang.c , Alex
<al*******@hotm ail.com> wrote:
CBFalconer <cb********@yah oo.com> wrote:
Alex wrote:
Sheldon Simms <sh**********@y ahoo.com> wrote:

> How is (0 == X) any less logical than (X == 0)?

How many times have you said aloud "if 0 is equal to X then ..."?

In languages other than C, how many times have you said:
if (0 <= x <= 3) then ....


This is an entirely different issue. Not really, You attempted to show that English usage should govern how
C is written. Chuck showed why thats a false idea.
To /me/, (x==0) is more natural than (0==x), while being
just as efficient of a construct. In the case of a range
expression, there is no efficient and natural way to
express:

if(x is between 0 and 3, inclusive)

This is the idea behind the simplification of such
expressions in C

if(x >= 0 && x <= 3)

....however, the simplification and repetition of the
variable, does not appeal to /me/.

This is a style issue and is, as such, moot. I was not
attempting to generalize my preference to other constructs,
other than the one presented. It is my preference to use
natural language constructs when they are as convenient to
use as their evil twins. /I/ find that this contributes
to readability.

Your example is traditional mathematical notation. so is if (x ==0) . Your point seems null.
Erm, unless you meant (0==x), this is in fact what I
was arguing.
A more relevant subsection of your example would be

if (0 <= x)

which, to me, is unreadable.

Its not uncommon to see this sort of expression in maths.


My math vocabulary is somewhat limited. However, I am
yet to see an expression of this sort, with a good reason.

Alex
Nov 13 '05 #42
In <bp**********@s parta.btinterne t.com> Richard Heathfield <do******@addre ss.co.uk.invali d> writes:
Dan Pop wrote:
In <bp**********@s parta.btinterne t.com> Richard Heathfield
<do******@addre ss.co.uk.invali d> writes:
Dan Pop wrote:

Just don't encourage other people to follow your example.

Oh, but I /do/. You see, it's a sensible technique for fallible people.


Nope, it isn't. All people are fallible, and the only technique that
catches any = vs == error that a compiler cannot or doesn't have to catch
is engaging your brain.


Why restrict yourself to techniques that a compiler cannot or doesn't have
to catch? It seems a very silly restriction.


It's a *very* practical one, too. You (subconciously, in my case)
concentrate your mental resources on the things the compiler cannot help
with.
If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view),


Logically, a==b and b==a are equivalent. (Duh.)


When was the last time you said "compare 0 to x" in plain English?
As a C beginner, how many times have you written "0 == x"?
if you do, you don't need it in the first place.


You seem to see brain engagement as a Boolean phenomenon. I don't believe
it's as simple as that; people /do/ make mistakes even when their brains
/are/ engaged.


Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #43
Dan Pop wrote:
If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view),
Logically, a==b and b==a are equivalent. (Duh.)


When was the last time you said "compare 0 to x" in plain English?


Never. But we're not discussing English here. We're discussing C. When I see
either 0==x or x==0, I don't think of it as "compare 0 to x" or "compare x
to 0" but rather, "compare these two quantities for equality". It makes no
difference whatsoever which way around you put them.
As a C beginner, how many times have you written "0 == x"?
Many times.
if you do, you don't need it in the first place.


You seem to see brain engagement as a Boolean phenomenon. I don't believe
it's as simple as that; people /do/ make mistakes even when their brains
/are/ engaged.


Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.


I accept that you claim that. I happen to disagree.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #44
In <3f******@news2 .power.net.uk> Richard Heathfield <in*****@addres s.co.uk.invalid > writes:
Dan Pop wrote:
If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view),

Logically, a==b and b==a are equivalent. (Duh.)


When was the last time you said "compare 0 to x" in plain English?


Never. But we're not discussing English here. We're discussing C.


Nope, we're discussing the way people think. From the C's point of view
it doesn't make any difference how you write it and nobody claimed
otherwise. But C code is not written for the exclusive perusal of the
C compilers. And when people read the code, *many* things that don't
make any difference to the compiler become (more or less) important.
As a C beginner, how many times have you written "0 == x"?


Many times.


How many years have you been a beginner?
if you do, you don't need it in the first place.

You seem to see brain engagement as a Boolean phenomenon. I don't believe
it's as simple as that; people /do/ make mistakes even when their brains
/are/ engaged.


Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.


I accept that you claim that. I happen to disagree.


Which means that you can't tell for sure which operator is which when
writing C code. If you could, it would be impossible to use the wrong
operator when performing an equality test. The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #45
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bp******** **@sunnews.cern .ch...
In <3f******@news2 .power.net.uk> Richard Heathfield <in*****@addres s.co.uk.invalid > writes:
Dan Pop wrote:
> If you don't engage the brain, the technique
> doesn't buy you anything (it just make your code look silly, from a
> logical point of view),

Logically, a==b and b==a are equivalent. (Duh.)

When was the last time you said "compare 0 to x" in plain English?


Never. But we're not discussing English here. We're discussing C.


Nope, we're discussing the way people think. From the C's point of view
it doesn't make any difference how you write it and nobody claimed
otherwise. But C code is not written for the exclusive perusal of the
C compilers. And when people read the code, *many* things that don't
make any difference to the compiler become (more or less) important.
As a C beginner, how many times have you written "0 == x"?


Many times.


How many years have you been a beginner?
> if you do, you don't need it in the first place.

You seem to see brain engagement as a Boolean phenomenon. I don't believe
it's as simple as that; people /do/ make mistakes even when their brains
/are/ engaged.

Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.


I accept that you claim that. I happen to disagree.


Which means that you can't tell for sure which operator is which when
writing C code. If you could, it would be impossible to use the wrong
operator when performing an equality test. The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.


That line of reasoning is equivalent to saying, "Don't use a debugger. You
should be able to desk-check your code to determine that it will work without
using a debugger to test it."

I actually had a manager say that.
Nov 13 '05 #46
Dan Pop wrote:
In <3f******@news2 .power.net.uk> Richard Heathfield
<in*****@addres s.co.uk.invalid > writes:
Dan Pop wrote:
> If you don't engage the brain, the technique
> doesn't buy you anything (it just make your code look silly, from a
> logical point of view),

Logically , a==b and b==a are equivalent. (Duh.)

When was the last time you said "compare 0 to x" in plain English?
Never. But we're not discussing English here. We're discussing C.


Nope, we're discussing the way people think.


No, we're discussing C. Psychology is down the hall.
From the C's point of view
it doesn't make any difference how you write it and nobody claimed
otherwise.
Quite so.
But C code is not written for the exclusive perusal of the
C compilers. And when people read the code, *many* things that don't
make any difference to the compiler become (more or less) important.
True enough, and I accept that there is a minor readability hit on
const==var for /some/ people, but I consider the benefit (of avoiding a
subtle error) to outweigh the cost. Obviously, you disagree.
As a C beginner, how many times have you written "0 == x"?


Many times.


How many years have you been a beginner?


Just over 14 years. How about you?
> if you do, you don't need it in the first place.

You seem to see brain engagement as a Boolean phenomenon. I don't
believe it's as simple as that; people /do/ make mistakes even when
their brains /are/ engaged.

Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.


I accept that you claim that. I happen to disagree.


Which means that you can't tell for sure which operator is which when
writing C code.


As a matter of fact, I can. Sometimes my fingers and/or keyboard can't,
though.
If you could, it would be impossible to use the wrong
operator when performing an equality test.
Wrong. It's not impossible at all.
The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.


The brain is often too busy to notice minor typos. Why not help the compiler
to pick up as many as it can? It seems perfectly logical to me.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #47
In <A_************ *******@newsrea d2.news.pas.ear thlink.net> "xarax" <xa***@email.co m> writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bp******* ***@sunnews.cer n.ch...

Which means that you can't tell for sure which operator is which when
writing C code. If you could, it would be impossible to use the wrong
operator when performing an equality test. The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.
That line of reasoning is equivalent to saying, "Don't use a debugger. You
should be able to desk-check your code to determine that it will work without
using a debugger to test it."


Bullshit! Locally checking the correctness of an operator in the context
of the code you're just writing is not the same thing as globally
checking the correctness of a program. The human mind has its
limitations.

BTW, I don't need a debugger to test the correctness of a program.
There are much better and more efficient ways of doing it.
I actually had a manager say that.


Either he was an idiot or you're quoting him out of context.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #48
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bq******** **@sunnews.cern .ch...
In <A_************ *******@newsrea d2.news.pas.ear thlink.net> "xarax" <xa***@email.co m> writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bp******* ***@sunnews.cer n.ch...

Which means that you can't tell for sure which operator is which when
writing C code. If you could, it would be impossible to use the wrong
operator when performing an equality test. The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.


That line of reasoning is equivalent to saying, "Don't use a debugger. You
should be able to desk-check your code to determine that it will work without
using a debugger to test it."


Bullshit! Locally checking the correctness of an operator in the context
of the code you're just writing is not the same thing as globally
checking the correctness of a program. The human mind has its
limitations.

BTW, I don't need a debugger to test the correctness of a program.
There are much better and more efficient ways of doing it.
I actually had a manager say that.


Either he was an idiot or you're quoting him out of context.


He was the former.
Nov 13 '05 #49
Dan Pop wrote:
"xarax" <xa***@email.co m> writes:

.... snip ...

That line of reasoning is equivalent to saying, "Don't use a
debugger. You should be able to desk-check your code to determine
that it will work without using a debugger to test it."


Bullshit! Locally checking the correctness of an operator in the
context of the code you're just writing is not the same thing as
globally checking the correctness of a program. The human mind has
its limitations.


Counter example:

if (p = malloc(N * sizeof *p)) {
/* carry on with gay abandon */
}
else {
/* cleanup */
exit(EXIT_FAILU RE);
}

is perfectly legitimate code, although some may disapprove. We
can also flip it to something slightly more readable with:

if (NULL == (p = malloc(N * sizeof *p))) {
/* cleanup */
exit(EXIT_FAILU RE);
}
else {
/* carry on with gay abandon */
}

or we could use (my preference):

if (!(p = malloc(N * sizeof *p))) {
/* cleanup */
exit(EXIT_FAILU RE);
}
else {
/* carry on with gay abandon */
}

and I am sure you can come up with further variations.

The point is that I have flipped operators about with some
abandon, but all the fragments are correct code. So, to requote,
"Locally checking the correctness of an operator in the
context of the code you're just writing" has very little to do
with it.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
Nov 13 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

15
4181
by: Stig Brautaset | last post by:
Hi group, I'm playing with a little generic linked list/stack library, and have a little problem with the interface of the pop() function. If I used a struct like this it would be simple: struct node { struct node *next; void *data; };
6
8280
by: bob_jenkins | last post by:
{ const void *p; (void)memset((void *)p, ' ', (size_t)10); } Should this call to memset() be legal? Memset is of type void *memset(void *, unsigned char, size_t) Also, (void *) is the generic pointer type. My real question is, is (void *) such a generic pointer type that it
188
17540
by: infobahn | last post by:
printf("%p\n", (void *)0); /* UB, or not? Please explain your answer. */
9
5309
by: Juggernaut | last post by:
I am trying to create a p_thread pthread_create(&threads, &attr, Teste, (void *)var); where var is a char variable. But this doesnt't work, I get this message: test.c:58: warning: cast to pointer from integer of different size. Now I thought that when it was a void I could pass anything? Thing is it works when I use an int, but in this case I wanted to use a char. It wouldnt be hard to work around it, but it annoys me because I've heard...
5
3532
by: Stijn van Dongen | last post by:
A question about void*. I have a hash library where the hash create function accepts functions unsigned (*hash)(const void *a) int (*cmp) (const void *a, const void *b) The insert function accepts a void* key argument, and uses the functions above to store this argument. It returns something (linked to the key) that the caller can store a value in. The actual key argument is always of the same pointer type (as seen in the caller,...
27
9005
by: Erik de Castro Lopo | last post by:
Hi all, The GNU C compiler allows a void pointer to be incremented and the behaviour is equivalent to incrementing a char pointer. Is this legal C99 or is this a GNU C extention? Thanks in advance. Erik
49
2830
by: elmar | last post by:
Hi Clers, If I look at my ~200000 lines of C code programmed over the past 15 years, there is one annoying thing in this smart language, which somehow reduces the 'beauty' of the source code ;-): char *cp; void *vp; void **vpp;
2
2184
by: Siv | last post by:
what is meant by dereferecing pointer? why does it occur? how to fix it?
28
1833
by: junky_fellow | last post by:
Guys, Consider a function func(void **var) { /* In function I need to typecast the variable var as (int **) I mean to say, I need to access var as (int **) }
0
9997
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
11279
Oralloy
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10872
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10981
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10499
tracyyun
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9675
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
8047
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6085
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4307
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.