Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: Pointer dereference rather than sizeof? (http://www.velocityreviews.com/forums/t632183-re-pointer-dereference-rather-than-sizeof.html)

Keith Thompson 08-25-2008 07:31 AM

Re: Pointer dereference rather than sizeof?
 
Micheal Smith <xulfer@cheapbsd.net> writes:
> I recently read an article containing numerous gripes about common C
> practices. One of them contained a gripe about the use of the sizeof
> operator as an argument to malloc calls. The supposed "right" way to go
> about calling malloc instead is to dereference a pointer; apparently even
> if said pointer is undefined.
>
> E.g.
> ptr = malloc(sizeof(struct some_struct)); = wrong
>
> ptr = malloc(*ptr); = right
>
> The method works on my platform, but doesn't really sit right with me. Is
> the code portable? Standard? I've been looking myself, but haven't come
> across anything forbidding it as of yet.


As you acknowledged later in the thread, the correct form is

ptr = malloc(sizeof *ptr);

or, if you're uncomfortable with using sizeof without parentheses:

ptr = malloc(sizeof(*ptr));

Or if you want to allocate an array:

ptr = malloc(N * sizeof *ptr);

As "fjblurt" pointed out, this has the advantage that it's obvious
you're using the correct type; if during later maintenance you change
ptr from a foo* to a bar*, the malloc call will continue to be
correct.

The trick here is that the pointer isn't actually dereferenced. The
operand of a sizeof operator is not evaluated; it's only used to
determine the type of the expression. (Variable-length arrays, or
VLAs, a new features in C99, are an exception to this.) So the
expression ``sizeof *ptr'' is guaranteed not to attempt to dereference
ptr. It doesn't even evaluate the pointer value itself.

Your discomfort over what looks like deferencing a possibly invalid
pointer is reasonable, but it's perfectly safe in this case.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Bill Reid 08-26-2008 12:48 AM

Re: Pointer dereference rather than sizeof?
 

Keith Thompson <kst-u@mib.org> wrote in message
news:ln8wulczzu.fsf@nuthaus.mib.org...
> Micheal Smith <xulfer@cheapbsd.net> writes:


> > I recently read an article containing numerous gripes about common C
> > practices. One of them contained a gripe about the use of the sizeof
> > operator as an argument to malloc calls. The supposed "right" way to go
> > about calling malloc instead is to dereference a pointer; apparently

even
> > if said pointer is undefined.
> >
> > E.g.
> > ptr = malloc(sizeof(struct some_struct)); = wrong
> >
> > ptr = malloc(*ptr); = right
> >
> > The method works on my platform, but doesn't really sit right with me.

Is
> > the code portable? Standard? I've been looking myself, but haven't

come
> > across anything forbidding it as of yet.

>
> As you acknowledged later in the thread, the correct form is
>
> ptr = malloc(sizeof *ptr);
>
> or, if you're uncomfortable with using sizeof without parentheses:
>
> ptr = malloc(sizeof(*ptr));
>
> Or if you want to allocate an array:
>
> ptr = malloc(N * sizeof *ptr);
>
> As "fjblurt" pointed out, this has the advantage that it's obvious
> you're using the correct type; if during later maintenance you change
> ptr from a foo* to a bar*, the malloc call will continue to be
> correct.
>
> The trick here is that the pointer isn't actually dereferenced. The
> operand of a sizeof operator is not evaluated; it's only used to
> determine the type of the expression. (Variable-length arrays, or
> VLAs, a new features in C99, are an exception to this.) So the
> expression ``sizeof *ptr'' is guaranteed not to attempt to dereference
> ptr. It doesn't even evaluate the pointer value itself.
>
> Your discomfort over what looks like deferencing a possibly invalid
> pointer is reasonable, but it's perfectly safe in this case.


Of course it looks like it is de-referencing the pointer, because that's
what de-referencing a pointer looks like everywhere else in "C" code.

At the risk of repeating myself, I'm going to repeat myself:

"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". NO non-lunatic has ever been able
to grasp the total non-logic of the topic, which is just one
incomprehensible aspect of an ostensible "programming language"
that was obviously actually designed as a cruel joke on anybody
who would attempt to use it (I can just hear the uber-techno-trolls
K&R sniggering about it now)..."

If you DO choose to use this so-called "language", NEVER blame
yourself if you get massively confused by this type of inconsistent
syntax, IT'S NOT YOUR FAULT, YOU'VE BEEN "KERNIGHANED
AND RITCHIED", PUNK...

---
William Ernest Reid



Nick Keighley 08-26-2008 08:53 AM

Re: Pointer dereference rather than sizeof?
 
On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.net> wrote:
> Keith Thompson <ks...@mib.org> wrote in message
> news:ln8wulczzu.fsf@nuthaus.mib.org...


<snip>

discussing
ptr = malloc (sizeof *ptr)


> > Your discomfort over what looks like deferencing a possibly invalid
> > pointer is reasonable, but it's perfectly safe in this case.

>
> Of course it looks like it is de-referencing the pointer, because that's
> what de-referencing a pointer looks like everywhere else in "C" code.
>
> At the risk of repeating myself, I'm going to repeat myself:
>
> "It's completely friggin' impossible to learn all the bass-ackwards
> and semi-sideways inconsistent methods of declaring and
> dereferencing pointers in "C". *NO non-lunatic has ever been able
> to grasp the total non-logic of the topic


<snip rant>

so what is a simple, easy to learn, well defined language.
What would *you* recommend?

--
Nick Keighley



Richard Bos 08-26-2008 10:44 AM

Re: Pointer dereference rather than sizeof?
 
Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:

> On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.net> wrote:
> > At the risk of repeating myself, I'm going to repeat myself:
> >
> > "It's completely friggin' impossible to learn all the bass-ackwards
> > and semi-sideways inconsistent methods of declaring and
> > dereferencing pointers in "C". =A0NO non-lunatic has ever been able
> > to grasp the total non-logic of the topic

>
> so what is a simple, easy to learn, well defined language.
> What would *you* recommend?


For Bill? Logo. _With_ turtle.

Richard

Bartc 08-26-2008 11:32 AM

Re: Pointer dereference rather than sizeof?
 
Nick Keighley wrote:
> On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.net> wrote:


>discussing
> ptr = malloc (sizeof *ptr)


>> "It's completely friggin' impossible to learn all the bass-ackwards
>> and semi-sideways inconsistent methods of declaring and
>> dereferencing pointers in "C". NO non-lunatic has ever been able
>> to grasp the total non-logic of the topic

>
> so what is a simple, easy to learn, well defined language.
> What would *you* recommend?


It came as a surprise to me that there apparently were no other languages
that do the same sorts of things as C does (ignoring C++).

So that explains why C is that widespread -- there are no alternatives! Not
when a low-level language is needed anyway.

C is on the face of it very simple; basic datatypes like:

Integers (of say 8,16,32,64 bits)
Floats (of say 32,64 bits)
Pointers (of say 32 or 64 bits)

And fixed-length arrays, and struct collections, of this lot and each other.

But, C seems to come with a huge amount of baggage, and seems to spread
itself too thinly across every system ever conceived, past present and
future. With the result that the obvious way to do anything is nearly always
wrong -- according to this newsgroup, because it might break on some obscure
system.

--
Bartc


Nick Keighley 08-26-2008 12:06 PM

Re: Pointer dereference rather than sizeof?
 
On 26 Aug, 11:44, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.net> wrote:


> > > At the risk of repeating myself, I'm going to repeat myself:

>
> > > "It's completely friggin' impossible to learn all the bass-ackwards
> > > and semi-sideways inconsistent methods of declaring and
> > > dereferencing pointers in "C". =A0NO non-lunatic has ever been able
> > > to grasp the total non-logic of the topic

>
> > so what is a simple, easy to learn, well defined language.
> > What would *you* recommend?

>
> For Bill? Logo. _With_ turtle.


I thought that was for bright children?

--
Nick Keighley

Flash Gordon 08-26-2008 05:58 PM

Re: Pointer dereference rather than sizeof?
 
Bartc wrote, On 26/08/08 12:32:
> Nick Keighley wrote:
>> On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.net> wrote:

>
>> discussing
>> ptr = malloc (sizeof *ptr)

>
>>> "It's completely friggin' impossible to learn all the bass-ackwards
>>> and semi-sideways inconsistent methods of declaring and
>>> dereferencing pointers in "C". NO non-lunatic has ever been able
>>> to grasp the total non-logic of the topic

>>
>> so what is a simple, easy to learn, well defined language.
>> What would *you* recommend?

>
> It came as a surprise to me that there apparently were no other
> languages that do the same sorts of things as C does (ignoring C++).
>
> So that explains why C is that widespread -- there are no alternatives!
> Not when a low-level language is needed anyway.


I've used Pascal derivative for low-level programming including embedded
systems development. I've known people to do it in ADA. I came across
one computer where the OS was developed in Forth. I'm sure it is done in
other languages as well.

> C is on the face of it very simple; basic datatypes like:
>
> Integers (of say 8,16,32,64 bits)
> Floats (of say 32,64 bits)
> Pointers (of say 32 or 64 bits)
>
> And fixed-length arrays, and struct collections, of this lot and each
> other.


You can get very complex things with just that lot. This applies to
other languages as well.

> But, C seems to come with a huge amount of baggage,


? It's a very small language.

> and seems to spread
> itself too thinly across every system ever conceived, past present and
> future.


That is part of why it is still a small language.

> With the result that the obvious way to do anything is nearly
> always wrong -- according to this newsgroup, because it might break on
> some obscure system.


Only some stuff hits that. You then just have to decide if the extra
effort to make it more portable is worth it (for example, with the code
I currently work on making it portable to non-8-bit byte systems is
*not* worth the effort.
--
Flash Gordon

REH 08-27-2008 08:37 PM

Re: Pointer dereference rather than sizeof?
 
On Aug 26, 1:58*pm, Flash Gordon <s...@flash-gordon.me.uk> wrote:
> I've used Pascal derivative for low-level programming including embedded
> systems development. I've known people to do it in ADA. I came across
> one computer where the OS was developed in Forth. I'm sure it is done in
> other languages as well.


Just a nit: it's "Ada."

REH

Bill Reid 09-03-2008 01:36 PM

Re: Pointer dereference rather than sizeof?
 

Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote in message
news:48b3de7a.677861242@news.xs4all.nl...
> Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> > On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.net> wrote:


> > > At the risk of repeating myself, I'm going to repeat myself:
> > >
> > > "It's completely friggin' impossible to learn all the bass-ackwards
> > > and semi-sideways inconsistent methods of declaring and
> > > dereferencing pointers in "C". =A0NO non-lunatic has ever been able
> > > to grasp the total non-logic of the topic

> >
> > so what is a simple, easy to learn, well defined language.
> > What would *you* recommend?

>
> For Bill? Logo. _With_ turtle.


Close! JavaScript!!!

---
William Ernest Reid




All times are GMT. The time now is 06:13 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.