| To: | jim@jtan.com |
|---|---|
| Subject: | Re: PATCH: io.h remove detrimental do {...} whiles, add sequence points, add const modifiers |
| From: | Justin Carlson <justinca@ri.cmu.edu> |
| Date: | 07 Dec 2001 14:36:28 -0500 |
| Cc: | linux-mips@oss.sgi.com |
| In-reply-to: | <20011207131521.A3942@neurosis.mit.edu> |
| References: | <20011207121416.A9583@dev1.ltc.com> <Pine.GSO.4.21.0112071830000.29896-100000@mullein.sonytel.be> <20011207123833.A23784@nevyn.them.org> <20011207160636.B23798@dea.linux-mips.net> <20011207131521.A3942@neurosis.mit.edu> |
| Sender: | owner-linux-mips@oss.sgi.com |
> So Brad's way allows things that weren't allowed before. But does
> it break anything that works with the do/while construct?
>
> You can take care of attempts to use the return type by voiding it:
>
> #define set_io_port_base(base) \
> (void)(*(unsigned long *)&mips_io_port_base = (base))
>
Maybe I missed this, but is there any reason for the patch, other then
a personal preference of how to do macros that look like functions?
I've seen gcc do strange non-optimal things with functions declared
inlines, but I've never seen it generate bad code WRT to do{}while(0)
constructs.
Unless I'm missing something, this patch looks like a solution in search
of a problem...
-Justin
|
| Previous by Date: | Re: PATCH: io.h remove detrimental do {...} whiles, add sequence points, add const modifiers, Jim Paris |
|---|---|
| Next by Date: | not getting the kernel prompt, balaji . ramalingam |
| Previous by Thread: | Re: PATCH: io.h remove detrimental do {...} whiles, add sequence points, add const modifiers, Jim Paris |
| Next by Thread: | Re: PATCH: io.h remove detrimental do {...} whiles, add sequence points, add const modifiers, Jim Paris |
| Indexes: | [Date] [Thread] [Top] [All Lists] |