and _DEVCTL_DATA(msg->i) is used to get at the data[].
If it were instead defined as:
struct _io_devctl {
_Uint16t type;
_Uint16t combine_len;
_Int32t dcmd;
_Int32t nbytes;
_Int32t zero;
_Uint8t data[0]; /* data[nbytes] */
};
we would also be able to get at the data with the [arguably] less
cryptic
msg->i.data
and sizeof(struct _io_devctl) wouldn’t change, so it shouldn’t break
anything.
The same is true for _io_devctl_reply, _io_write, etc.
and _DEVCTL_DATA(msg->i) is used to get at the data[].
If it were instead defined as:
struct _io_devctl {
_Uint16t type;
_Uint16t combine_len;
_Int32t dcmd;
_Int32t nbytes;
_Int32t zero;
_Uint8t data[0]; /* data[nbytes] */
};
we would also be able to get at the data with the [arguably] less
cryptic
msg->i.data
and sizeof(struct _io_devctl) wouldn’t change, so it shouldn’t break
anything.
The same is true for _io_devctl_reply, _io_write, etc.
comments?
I thought this was a portability issue with some compilers not supporting
zero length data structures
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
Email my initials at parse dot com.
and _DEVCTL_DATA(msg->i) is used to get at the data[].
If it were instead defined as:
struct _io_devctl {
_Uint16t type;
_Uint16t combine_len;
_Int32t dcmd;
_Int32t nbytes;
_Int32t zero;
_Uint8t data[0]; /* data[nbytes] */
};
we would also be able to get at the data with the [arguably] less
cryptic
msg->i.data
and sizeof(struct _io_devctl) wouldn’t change, so it shouldn’t break
anything.
The same is true for _io_devctl_reply, _io_write, etc.
comments?
I thought this was a portability issue with some compilers not supporting
zero length data structures >
-RK
It is a portability issue. But is it one that can possibly manifest
itself? Will QSSL ever offer a compiler other than GNU gcc? For QNX
6.x? I think it’s safe to say gcc will always support it.
and _DEVCTL_DATA(msg->i) is used to get at the data[].
If it were instead defined as:
struct _io_devctl {
_Uint16t type;
_Uint16t combine_len;
_Int32t dcmd;
_Int32t nbytes;
_Int32t zero;
_Uint8t data[0]; /* data[nbytes] */
};
we would also be able to get at the data with the [arguably] less
cryptic
msg->i.data
and sizeof(struct _io_devctl) wouldn’t change, so it shouldn’t break
anything.
The same is true for _io_devctl_reply, _io_write, etc.
comments?
I thought this was a portability issue with some compilers not supporting
zero length data structures >
-RK
It is a portability issue. But is it one that can possibly manifest
itself? Will QSSL ever offer a compiler other than GNU gcc? For QNX
6.x? I think it’s safe to say gcc will always support it.
I think two better questions are, “Will QNX 6 ever run on something that doesn’t
have a GCC compiler available” – answer: maybe - you never know, and “Will someone
somewhere for whatever reason wish to use a non-gcc compiler” – answer: maybe - you
never know.
I’d rather QSSL not introduce “compiler-of-the-week” hacks into the sourcebase.
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
Email my initials at parse dot com.
and _DEVCTL_DATA(msg->i) is used to get at the data[].
If it were instead defined as:
struct _io_devctl {
_Uint16t type;
_Uint16t combine_len;
_Int32t dcmd;
_Int32t nbytes;
_Int32t zero;
_Uint8t data[0]; /* data[nbytes] */
};
we would also be able to get at the data with the [arguably] less
cryptic
msg->i.data
and sizeof(struct _io_devctl) wouldn’t change, so it shouldn’t break
anything.
The same is true for _io_devctl_reply, _io_write, etc.
comments?
I thought this was a portability issue with some compilers not
supporting
zero length data structures >
-RK
It is a portability issue. But is it one that can possibly manifest
itself? Will QSSL ever offer a compiler other than GNU gcc? For QNX
6.x? I think it’s safe to say gcc will always support it.
I think two better questions are, “Will QNX 6 ever run on something that
doesn’t
have a GCC compiler available” – answer: maybe - you never know, and
“Will someone
somewhere for whatever reason wish to use a non-gcc compiler” – answer:
maybe - you
never know. >
I’d rather QSSL not introduce “compiler-of-the-week” hacks into the
sourcebase.
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at > www.parse.com
Email my initials at parse dot com.
I think two better questions are, “Will QNX 6 ever run on something that
doesn’t
have a GCC compiler available” – answer: maybe - you never know, and
“Will someone
somewhere for whatever reason wish to use a non-gcc compiler” – answer:
maybe - you
never know. >
I’d rather QSSL not introduce “compiler-of-the-week” hacks into the
sourcebase.
Cheers,
-RK
“compiler-of-the-week”! Boy when you put it in quotes of course it sounds
bad.
Well I don’t want a compiler of the week either. But I’m not happy with
gcc. I guess I’m just spioled by Watcom.
I think two better questions are, “Will QNX 6 ever run on something that
doesn’t
have a GCC compiler available” – answer: maybe - you never know, and
“Will someone
somewhere for whatever reason wish to use a non-gcc compiler” – answer:
maybe - you
never know. >
I’d rather QSSL not introduce “compiler-of-the-week” hacks into the
sourcebase.
Cheers,
-RK
“compiler-of-the-week”! Boy when you put it in quotes of course it sounds
bad.
Is it any better without the quotes?
Well I don’t want a compiler of the week either. But I’m not happy with
gcc. I guess I’m just spioled by Watcom.
I’m slowly getting around to “liking” (in quotes ) GCC. There are certain
things that Watcom was a lot better at, but GCC does have its merits. A clean
compile on both Watcom and GCC is definitely something worthwhile…
Cheers,
-RK
\
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
Email my initials at parse dot com.
I thought this was a portability issue with some compilers not supporting
zero length data structures >
-RK
It is a portability issue. But is it one that can possibly manifest
itself? Will QSSL ever offer a compiler other than GNU gcc? For QNX
6.x? I think it’s safe to say gcc will always support it.
I think two better questions are, “Will QNX 6 ever run on something that doesn’t
have a GCC compiler available” – answer: maybe - you never know, and “Will someone
somewhere for whatever reason wish to use a non-gcc compiler” – answer: maybe - you
never know. >
I’d rather QSSL not introduce “compiler-of-the-week” hacks into the sourcebase.
It must have been a really busy week How far should QSSL go to
cater to possible compiler candidates? There are some really good K&R
compilers still around … IMHO, the line should be draw from today and
look to the future.
GCC allows “zero-length data” declared as
data[0]
ISO-C99 standardized “flexible array members” declared as
data[]
There is a minor incompatibility that is easily taken care of with a
macro. Actually data[ZERO_LEN] would be the preferred and standard
approach. In light of a standard C syntax, pointer manipulation becomes
a bit tacky.
Also, if memory serves, the Nto kernel was orignally (still is?) built on
QNX4
with the Watcom compiler that doesn’t support this…
Sure. But that’s only because the Watcom compiler is dead. Sure there
is a revival effort, but they still have a bit of work to do. And when
they succeed, it will have to be supported if Watcom is to be ISO-C99
compliant.
How far should QSSL go to