On Mon, May 18, 2020 at 07:49:11AM -, Miod Vallat wrote:
>
> > For instance, in the wsdisplay_emulops structure, there are:
> >
> > int (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> > void(*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
> >
> > And at
> For instance, in the wsdisplay_emulops structure, there are:
>
> int (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> void (*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
>
> And at the end of the structure is this comment, showing that at
> least someone
On Sun, May 17, 2020 at 02:20:08PM +1000, Jonathan Gray wrote:
> On Sat, May 16, 2020 at 12:13:37PM -0700, jo...@armadilloaerospace.com wrote:
> > (Not sure if this belongs in tech@ or misc@)
>
> I think tech@ is fine for discussion of code.
>
> >
> > What is the thinking around non-functional
On Sat, May 16, 2020 at 12:13:37PM -0700, jo...@armadilloaerospace.com wrote:
> (Not sure if this belongs in tech@ or misc@)
I think tech@ is fine for discussion of code.
>
> What is the thinking around non-functional code changes that just
> improve clarity without functionality changes? I
(Not sure if this belongs in tech@ or misc@)
What is the thinking around non-functional code changes that just
improve clarity without functionality changes? I can imagine bad
experiences with that, but there is certainly room for improvement.
For instance, in the wsdisplay_emulops structure,
