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
next prev 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: linkBe 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.