| Message ID | 4880a0bea524cc86c079cf356172d0599636f358.1253661009.git.quintela@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
Juan Quintela <quintela@redhat.com> writes: > Why this ever compiled is a mistery to me. > > Signed-off-by: Juan Quintela <quintela@redhat.com> > --- > hw/serial.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/serial.c b/hw/serial.c > index a22770f..6e8c6e1 100644 > --- a/hw/serial.c > +++ b/hw/serial.c > @@ -98,13 +98,13 @@ > #define RECV_FIFO 1 > #define MAX_XMIT_RETRY 4 > > -struct SerialFIFO { > +typedef struct SerialFIFO { > uint8_t data[UART_FIFO_LENGTH]; > uint8_t count; > uint8_t itl; /* Interrupt Trigger Level */ > uint8_t tail; > uint8_t head; > -} typedef SerialFIFO; > +} SerialFIFO; Syntactically, typedef is a storage class specifier just like static or extern, and the entire struct { } block is type specifier like int or float. The order of type specifiers and storage class specifiers is not important. The above construct is thus perfectly valid, albeit unusual, C code. That said, I'm all in favour of changing it to the more common style.
diff --git a/hw/serial.c b/hw/serial.c index a22770f..6e8c6e1 100644 --- a/hw/serial.c +++ b/hw/serial.c @@ -98,13 +98,13 @@ #define RECV_FIFO 1 #define MAX_XMIT_RETRY 4 -struct SerialFIFO { +typedef struct SerialFIFO { uint8_t data[UART_FIFO_LENGTH]; uint8_t count; uint8_t itl; /* Interrupt Trigger Level */ uint8_t tail; uint8_t head; -} typedef SerialFIFO; +} SerialFIFO; struct SerialState { uint16_t divider;
Why this ever compiled is a mistery to me. Signed-off-by: Juan Quintela <quintela@redhat.com> --- hw/serial.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)