All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Mohr <andi@lisas.de>
To: Jiri Slaby <jslaby@suse.cz>
Cc: tiwai@suse.de, jirislaby@gmail.com, perex@perex.cz,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	Andreas Mohr <andi@lisas.de>
Subject: Re: [PATCH 1/1] SOUND: azt3328, fix broken AZF_FMT_XLATE macro
Date: Sat, 22 Jan 2011 21:01:27 +0100	[thread overview]
Message-ID: <20110122200127.GA1824@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <1295704570-27015-1-git-send-email-jslaby@suse.cz>

On Sat, Jan 22, 2011 at 02:56:10PM +0100, Jiri Slaby wrote:
> Despite the AZF_FMT_XLATE macro looks totally weird and useless, it's
> heavily broken (apart it also broke my parser).
> The 'break' in the macro belongs to the do-while loop and not to the
> switch. So it always falls through the all cases till the end.
> 
> Remove the do-while from the macro.

Hmm, there doesn't remain much to say other than "Double ouch. Mea culpa.".

However I'd like to add one bit, that the usual macro-side
do ... while(0) loop has been added by me due to a checkpatch.pl warning
which called for attention. IOW, it could be argued that checkpatch.pl
led people into ""improving"" formely "working" (whatever one may think of it)
code.
Something to be investigated, methinks.

> Also people should terminate statements with semicolons. So force
> people to do so by removing the last one in the macro.

Oh dammit of course, I'm normally implementing it this way as well.
Unfortunately I failed to submit it that way in this particular case.

> I vote for removing that crap completely because it makes the code
> weird anyway -- you have to specify manually both of freq and bits
> which is I would expect to be avoided exactly by such a macro.

The reason that it broke your parser is certainly a very valid one.
Macro syntax is known to be arcane and quite variable between compilers
(e.g. I read that the gcc people said that they were the only one who
_really_ grokked macro evaluation order and token pasting the way
it was meant to be implemented - go figure...).

As such I support a change here.
I'll try to come up with a translation table instead, 
or else probably best just revert this wetware fart.

Thanks,

Andreas Mohr

WARNING: multiple messages have this Message-ID (diff)
From: Andreas Mohr <andi@lisas.de>
To: Jiri Slaby <jslaby@suse.cz>
Cc: alsa-devel@alsa-project.org, jirislaby@gmail.com, tiwai@suse.de,
	linux-kernel@vger.kernel.org, Andreas Mohr <andi@lisas.de>
Subject: Re: [PATCH 1/1] SOUND: azt3328, fix broken AZF_FMT_XLATE macro
Date: Sat, 22 Jan 2011 21:01:27 +0100	[thread overview]
Message-ID: <20110122200127.GA1824@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <1295704570-27015-1-git-send-email-jslaby@suse.cz>

On Sat, Jan 22, 2011 at 02:56:10PM +0100, Jiri Slaby wrote:
> Despite the AZF_FMT_XLATE macro looks totally weird and useless, it's
> heavily broken (apart it also broke my parser).
> The 'break' in the macro belongs to the do-while loop and not to the
> switch. So it always falls through the all cases till the end.
> 
> Remove the do-while from the macro.

Hmm, there doesn't remain much to say other than "Double ouch. Mea culpa.".

However I'd like to add one bit, that the usual macro-side
do ... while(0) loop has been added by me due to a checkpatch.pl warning
which called for attention. IOW, it could be argued that checkpatch.pl
led people into ""improving"" formely "working" (whatever one may think of it)
code.
Something to be investigated, methinks.

> Also people should terminate statements with semicolons. So force
> people to do so by removing the last one in the macro.

Oh dammit of course, I'm normally implementing it this way as well.
Unfortunately I failed to submit it that way in this particular case.

> I vote for removing that crap completely because it makes the code
> weird anyway -- you have to specify manually both of freq and bits
> which is I would expect to be avoided exactly by such a macro.

The reason that it broke your parser is certainly a very valid one.
Macro syntax is known to be arcane and quite variable between compilers
(e.g. I read that the gcc people said that they were the only one who
_really_ grokked macro evaluation order and token pasting the way
it was meant to be implemented - go figure...).

As such I support a change here.
I'll try to come up with a translation table instead, 
or else probably best just revert this wetware fart.

Thanks,

Andreas Mohr

  parent reply	other threads:[~2011-01-22 20:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-22 13:56 [PATCH 1/1] SOUND: azt3328, fix broken AZF_FMT_XLATE macro Jiri Slaby
2011-01-22 16:26 ` Takashi Iwai
2011-01-22 16:26   ` Takashi Iwai
2011-01-25  5:46   ` [PATCH] azt3328: repair breakage (Re: [PATCH 1/1] SOUND: azt3328, fix broken AZF_FMT_XLATE macro) Andreas Mohr
2011-01-25  5:46     ` Andreas Mohr
2011-01-25  7:13     ` Takashi Iwai
2011-01-25  7:13       ` Takashi Iwai
2011-01-25  8:23     ` Jiri Slaby
2011-01-25  9:40       ` Takashi Iwai
2011-01-25  9:40         ` Takashi Iwai
2011-01-22 20:01 ` Andreas Mohr [this message]
2011-01-22 20:01   ` [PATCH 1/1] SOUND: azt3328, fix broken AZF_FMT_XLATE macro Andreas Mohr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110122200127.GA1824@rhlx01.hs-esslingen.de \
    --to=andi@lisas.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.