* sizeof *data, when data isn't initalized, is that right?
@ 2015-01-22 18:19 Daniel Hilst Selli
2015-01-22 18:38 ` Hubert CHAUMETTE
2015-01-22 18:39 ` Hubert CHAUMETTE
0 siblings, 2 replies; 4+ messages in thread
From: Daniel Hilst Selli @ 2015-01-22 18:19 UTC (permalink / raw)
To: linux-c-programming
I came across this code:
struct mcp23s08_driver_data *data;
...
data = kzalloc(sizeof *data + chips * sizeof(struct mcp23s08),
GFP_KERNEL);
Since data wasn't initialized when `sizeof *data' is called, wasn't this a non-initialized pointer dereference?
Cheers
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sizeof *data, when data isn't initalized, is that right?
2015-01-22 18:19 sizeof *data, when data isn't initalized, is that right? Daniel Hilst Selli
@ 2015-01-22 18:38 ` Hubert CHAUMETTE
2015-01-22 18:39 ` Hubert CHAUMETTE
1 sibling, 0 replies; 4+ messages in thread
From: Hubert CHAUMETTE @ 2015-01-22 18:38 UTC (permalink / raw)
To: Daniel Hilst Selli, linux-c-programming
Hi,
As I understand it, sizeof(*data) is the same as sizeof(struct mcp23s08_driver_data). There should be no pointer dereference here, so I would say it isn't an issue. That notation is quite confusing though.
Note that data is surrounded by parenthesis, at least in Linux 3.18, in gpio-mcp23s08.c
Regards,
Hubert
Le 22/01/2015 19:19, Daniel Hilst Selli a écrit :
> I came across this code:
>
> struct mcp23s08_driver_data *data;
> ...
> data = kzalloc(sizeof *data + chips * sizeof(struct mcp23s08),
> GFP_KERNEL);
>
>
> Since data wasn't initialized when `sizeof *data' is called, wasn't this a non-initialized pointer dereference?
>
> Cheers
> --
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sizeof *data, when data isn't initalized, is that right?
2015-01-22 18:19 sizeof *data, when data isn't initalized, is that right? Daniel Hilst Selli
2015-01-22 18:38 ` Hubert CHAUMETTE
@ 2015-01-22 18:39 ` Hubert CHAUMETTE
2015-01-23 7:33 ` Trevor Woerner
1 sibling, 1 reply; 4+ messages in thread
From: Hubert CHAUMETTE @ 2015-01-22 18:39 UTC (permalink / raw)
To: Daniel Hilst Selli, linux-c-programming
Hi,
As I understand it, sizeof(*data) is the same as sizeof(struct mcp23s08_driver_data). There should be no pointer dereference here, so I would say it isn't an issue. That notation is quite confusing though.
Note that data is surrounded by parenthesis, at least in Linux 3.18, in gpio-mcp23s08.c
Regards,
Hubert
Le 22/01/2015 19:19, Daniel Hilst Selli a écrit :
> I came across this code:
>
> struct mcp23s08_driver_data *data;
> ...
> data = kzalloc(sizeof *data + chips * sizeof(struct mcp23s08),
> GFP_KERNEL);
>
>
> Since data wasn't initialized when `sizeof *data' is called, wasn't this a non-initialized pointer dereference?
>
> Cheers
> --
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sizeof *data, when data isn't initalized, is that right?
2015-01-22 18:39 ` Hubert CHAUMETTE
@ 2015-01-23 7:33 ` Trevor Woerner
0 siblings, 0 replies; 4+ messages in thread
From: Trevor Woerner @ 2015-01-23 7:33 UTC (permalink / raw)
To: Hubert CHAUMETTE, Daniel Hilst Selli, linux-c-programming
On 01/22/15 13:39, Hubert CHAUMETTE wrote:
> As I understand it, sizeof(*data) is the same as sizeof(struct mcp23s08_driver_data). There should be no pointer dereference here, so I would say it isn't an issue.
In most cases (always?) sizeof() is a compile-time operator; it is up to
the compiler to perform the calculation of an object's size and simply
place that constant into the code. This is why the target of a sizeof()
operation needs to be fully defined at compile time.
Therefore, since this calculation takes place at compile time, there is
no run-time pointer dereference taking place.
> That notation is quite confusing though.
This idiom is quite common, so it would be good to become familiar with
it. Without using this idiom one would have to write:
sizeof (struct mpc23s08_driver_data)
which is fine... until someone else comes along and changes "data"'s
type (defined way up at the start of the function) to, say,
mpc23s08_driver_data_2. Then someone would need to go through all the
code and find all instances of
sizeof (struct mpc23s08_driver_data)
and change all of them to
sizeof (struct mpc23s08_driver_data_2)
As you might guess, this is prone to error. However, if the original
developer used
sizeof (*data)
throughout their code, no such subsequent changes would be needed. The
compiler is smart enough to figure out that *data is an object of struct
mpc23s08_driver_data and use that in its sizeof calculation. If/when
"data"'s definition gets changed, the compiler is then able to use
mpc23s08_driver_data_2 in its calculation, without any necessary
subsequent changes to the code.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-01-23 7:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-22 18:19 sizeof *data, when data isn't initalized, is that right? Daniel Hilst Selli
2015-01-22 18:38 ` Hubert CHAUMETTE
2015-01-22 18:39 ` Hubert CHAUMETTE
2015-01-23 7:33 ` Trevor Woerner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.