I agree with some of what you are proposing, but disagree with much
of it.
Certainly simplifying our header file mess is important, but that's
not going to happen overnight. One particular example of that below.
And using opaque etruct definitions where possible, rather than
void * in
> On Jul 11, 2023, at 2:56 PM, Taylor R Campbell
> wrote:
>
> I agree the keyword is ugly, and it's unfortunate that in order to
> omit it we would have to use C++, but the ugliness gives us practical
> benefits of better type-checking, reduced header file maintenance
> burden, and reduced
> Date: Tue, 11 Jul 2023 15:36:08 -0700
> From: Phil Nelson
>
> I'm working on getting the iwlwifi driver for intel devices into
> the new wifi framework. In going over the files as named I see
> that there are multiple different files "xxx/tx.c" and "yyy/tx.c".
> Those names would both
Hi all,
I'm working on getting the iwlwifi driver for intel devices into
the new wifi framework. In going over the files as named I see
that there are multiple different files "xxx/tx.c" and "yyy/tx.c".
Those names would both compile to tx.o in a kernel compile directory.
I haven't seen any
On Tue, 11 Jul 2023 at 06:17, Taylor R Campbell wrote:
>
> I propose the attached change to KNF style(5) to advise against
> typedefs for structs or unions, or pointers to them.
Perhaps be positive? Add a section encouraging the use of struct,
union and enum forward declarations when the
I'm revising the patch to say `avoid' rather than `do not use'. Style
rules can always be broken if there's a sufficiently compelling reason
to do so. (For example, pthread_t is not going to go away no matter
how much I convince NetBSD's /usr/share/misc/style to hop and scream
at it.)
> Date:
> Date: Tue, 11 Jul 2023 22:00:25 +0100
> From: Robert Swindells
>
> Linux has the kcmp(2) syscall, Mesa makes use of it.
>
> Do we want a version of the syscall?
Can you give any more details?
What is kcmp(2) useful for?
Is kcmp(2) a good design for that goal?
What does Mesa use kcmp(2)
Linux has the kcmp(2) syscall, Mesa makes use of it.
Do we want a version of the syscall?
> On Jul 11, 2023, at 6:43 AM, Johnny Billquist wrote:
>
> typedefs in C don't really create new types. They are all just derivatives.
> Sometimes I even wonder why typedef exists in C. Feels like I could
> accomplish the same with a #define
Because #define generates pollution in unrelated
On 2023-07-11 15:28, Mouse wrote:
I don't get it. Why the "void *" stuff? That is where I think the
real badness lies, and I agree we should not have that.
But defining something like
typedef struct bus_dma_tag *bus_dma_tag_t;
would mean we could easily change what bus_dma_tag_t
On 2023-07-11 15:28, Mouse wrote:
I don't get it. Why the "void *" stuff? That is where I think the
real badness lies, and I agree we should not have that.
But defining something like
typedef struct bus_dma_tag *bus_dma_tag_t;
would mean we could easily change what bus_dma_tag_t
> Sometimes I even wonder why typedef exists in C. Feels like I could
> accomplish the same with a #define
For `typedef struct foo Something', yes, you could (well, except for
their different scopes, and possibly some other corner cases).
For `typedef void (*callback_t)(void *, status_t, int)',
On Tue, Jul 11, 2023 at 05:56:27 -0700, Jason Thorpe wrote:
> > On Jul 11, 2023, at 3:17 AM, Taylor R Campbell wrote:
> >
> > If we used `struct bus_dma_tag *' instead, the forward declaration
> > could be `struct bus_dma_tag;' instead of having to pull in all of
> > sys/bus.h, _and_ the C
> I don't get it. Why the "void *" stuff? That is where I think the
> real badness lies, and I agree we should not have that.
> But defining something like
> typedef struct bus_dma_tag *bus_dma_tag_t;
> would mean we could easily change what bus_dma_tag_t actually is,
> keeping it opaque,
On 2023-07-11 12:17, Taylor R Campbell wrote:
I propose the attached change to KNF style(5) to advise against
typedefs for structs or unions, or pointers to them.
Passing around pointers to structs and unions doesn't require the
definition, only a forward declaration:
struct vnode;
int
[riastradh@]
> I propose the attached change to KNF style(5) to advise against
> typedefs for structs or unions, or pointers to them.
Pointers to them, I agree. I don't like typedefs for pointers to
structs, except possibly for a few special cases. I think it should be
pellucid from the
> On Jul 11, 2023, at 3:17 AM, Taylor R Campbell wrote:
>
> If we used `struct bus_dma_tag *' instead, the forward declaration
> could be `struct bus_dma_tag;' instead of having to pull in all of
> sys/bus.h, _and_ the C compiler would actually check types.
In the original design, it’s not
Objections?
No objections here, just concurrences.
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer |
On Tue, Jul 11, 2023 at 10:17:24 +, Taylor R Campbell wrote:
> I propose the attached change to KNF style(5) to advise against
> typedefs for structs or unions, or pointers to them.
[...]
> (Typedefs for integer, function, and function pointer types are not
> covered by this advice.)
Yes,
On Tue, Jul 11, 2023 at 10:17:24AM +, Taylor R Campbell wrote:
> Objections?
This is a very good change.
Martin
I propose the attached change to KNF style(5) to advise against
typedefs for structs or unions, or pointers to them.
Passing around pointers to structs and unions doesn't require the
definition, only a forward declaration:
struct vnode;
int frobnitz(struct vnode *);
This can dramatically cut
21 matches
Mail list logo
