Lol. The mossy side of a boulder is the alloc, the non-mossy side is
the free!
:P
regards,
dan carpenter
Dan Carpenter writes:
> Hike up the mountain, then if you get stuck hike back down using the
> exact same path.
OK, I understand what you say. I just can't resist objecting to that
example ;)
In my experience, finding the exact same path back after hiking up a
mountain is really hard. Especial
On Tue, Aug 23, 2016 at 01:03:15PM +0200, Bjørn Mork wrote:
> "Michael S. Tsirkin" writes:
>
> > foo = kmalloc(SIZE, GFP_KERNEL);
> > if (!foo)
> > goto err_foo;
> >
> > foo->bar = kmalloc(SIZE, GFP_KERNEL);
> >
"Michael S. Tsirkin" writes:
> foo = kmalloc(SIZE, GFP_KERNEL);
> if (!foo)
> goto err_foo;
>
> foo->bar = kmalloc(SIZE, GFP_KERNEL);
> if (!foo->bar)
> goto err_bar;
>
On Mon, Aug 22, 2016 at 09:50:06PM +0300, Dan Carpenter wrote:
> On Mon, Aug 22, 2016 at 05:53:02PM +0300, Michael S. Tsirkin wrote:
> > The point is really naming label for the part of init that failed
> > (and so needs to be skipped), rather than the part that will run.
>
> Naming labels after w
On Mon, Aug 22, 2016 at 05:53:02PM +0300, Michael S. Tsirkin wrote:
> The point is really naming label for the part of init that failed
> (and so needs to be skipped), rather than the part that will run.
Naming labels after what "needs to be skipped" doesn't work. How does
that meaning make sense
On Mon, Aug 22, 2016 at 09:31:40PM +0300, Dan Carpenter wrote:
>
> vhost_dev_set_owner() is an example of why come-from labels are
> bad style.
>
> devel/drivers/vhost/vhost.c
>473 /* Caller should have device mutex */
>474 long vhost_dev_set_owner(struct vhost_dev *dev)
>475 {
>
vhost_dev_set_owner() is an example of why come-from labels are
bad style.
devel/drivers/vhost/vhost.c
473 /* Caller should have device mutex */
474 long vhost_dev_set_owner(struct vhost_dev *dev)
475 {
476 struct task_struct *worker;
477 int err;
478
4
On Mon, Aug 22, 2016 at 08:16:17AM -0600, Jonathan Corbet wrote:
> On Mon, 22 Aug 2016 16:57:46 +0300
> "Michael S. Tsirkin" wrote:
>
> > commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> > add some more error handling guidelines") suggests never naming goto
> > labels after
On Mon, Aug 22, 2016 at 04:57:46PM +0300, Michael S. Tsirkin wrote:
> commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> add some more error handling guidelines") suggests never naming goto
> labels after the goto location - that is the error that is handled.
>
> But it's actu
On Mon, 22 Aug 2016 16:57:46 +0300
"Michael S. Tsirkin" wrote:
> commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> add some more error handling guidelines") suggests never naming goto
> labels after the goto location - that is the error that is handled.
>
> But it's actuall
> Please provide your point of view.
I would like to interpret the key word "goto" from the C programming
language a bit more here so that a better common understanding can
eventually be achieved.
Strong opinions might be floating around for the consistent naming
of jump labels. My reasoning work
On 12/03/14 17:00, SF Markus Elfring wrote:
Which name pattern do you find more appropriate in such
an use case?
I think Dan wants the label to be descriptive about the tasks
needed in the exception handling itself.
I would usually prefer also such a target-oriented labelling
for the affected
>> Which name pattern do you find more appropriate in such
>> an use case?
>
> I think Dan wants the label to be descriptive about the tasks
> needed in the exception handling itself.
I would usually prefer also such a target-oriented labelling
for the affected identifiers.
How are the chances to
On 12/03/14 14:24, SF Markus Elfring wrote:
Sorry. I misread your email. If the code looks like this:
foo = kmalloc();
if (!foo)
goto kmalloc_failed;
The "kmalloc_failed" doesn't add any information.
I find that this such a name approach would fit to your
exp
> Sorry. I misread your email. If the code looks like this:
>
> foo = kmalloc();
> if (!foo)
> goto kmalloc_failed;
>
> The "kmalloc_failed" doesn't add any information.
I find that this such a name approach would fit to your
expectation of a source-oriented labeling
Sorry. I misread your email. If the code looks like this:
foo = kmalloc();
if (!foo)
goto kmalloc_failed;
The "kmalloc_failed" doesn't add any information. We can see that
kmalloc failed from the context.
regards,
dan carpenter
--
To unsubscribe from this list
On Wed, Dec 03, 2014 at 01:52:53PM +0100, Julia Lawall wrote:
> On Wed, 3 Dec 2014, Dan Carpenter wrote:
>
> > On Wed, Dec 03, 2014 at 01:31:19PM +0100, SF Markus Elfring wrote:
> > >
> > > * To which source code place should the word "location" refer to?
> > > - jump source
> > > - jump targe
>> * To which source code place should the word "location" refer to?
>> - jump source
>> - jump target
>
> jump target.
Thanks for the clarification of your intention.
I wonder then why I got the feedback "That is a useless thing to do."
from you yesterday.
I hope that we can still clarify o
On Wed, 3 Dec 2014, Dan Carpenter wrote:
> On Wed, Dec 03, 2014 at 01:31:19PM +0100, SF Markus Elfring wrote:
> >
> > * To which source code place should the word "location" refer to?
> > - jump source
> > - jump target
>
> jump target.
I think you mean source? Or it really is ambiguous. Th
>> * To which source code place should the word "location" refer to?
>>- jump source
>>- jump target
>
> I think you digested the paragraph in too small bits.
I would prefer to reduce the probability for misunderstandings of the
proposed wording a bit more.
> The term "goto location" l
On Wed, Dec 03, 2014 at 01:31:19PM +0100, SF Markus Elfring wrote:
>
> * To which source code place should the word "location" refer to?
> - jump source
> - jump target
jump target.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 12/03/14 13:31, SF Markus Elfring wrote:
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 9f28b14..9c8a234 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits
from multiple
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> index 9f28b14..9c8a234 100644
> --- a/Documentation/CodingStyle
> +++ b/Documentation/CodingStyle
> @@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits
> from multiple
> locations and some common work
On Tue, 2 Dec 2014 10:09:02 +0100 (CET)
Julia Lawall wrote:
> kmalloc actually takes two arguments. Perhaps it would be better to show
> something that looks like a valid call.
Agreed; I took the liberty of sticking in a GFP_KERNEL as I applied the
patch with Julia's ack.
Thanks,
jon
--
To un
> @@ -403,9 +408,10 @@ The rationale is:
> int fun(int a)
> {
> int result = 0;
> - char *buffer = kmalloc(SIZE);
> + char *buffer;
>
> - if (buffer == NULL)
> + buffer = kmalloc(SIZE);
kmalloc actually takes two arguments. Perhaps it would be better to show
something that
26 matches
Mail list logo
