>
> Sorry, there aren't actually two extra padding bytes, even though the
> struct is two bytes longer in length. Don't know what I was thinking.
> Time for a coffee.
>
The problem with this kind of things is they depend too much
of the implementations, because you can have the padding or
not, s
> Non-maintainers like us can't push to the repository. Mailing list only.
The idea is to use the mailing list as a peer review mechanism. I am
one of the maintainer of st and I also send the patches first to the
mailing list to see the opinion of another hackers.
Regards,
On Mon, Apr 27, 2015 at 06:56:59AM -0700, suigin wrote:
> What's the general process and ettiquete for submitting patches, do we
> submit them to solely to this mailing list, or should they also be
> pushed via git for review?
Non-maintainers like us can't push to the repository. Mailing list only
On Mon, Apr 27, 2015 at 07:34:01AM -0700, suigin wrote:
> As you can see, it's actually 2 bytes less. This is because a struct
> is usually aligned to the maximum alignment of all fields. A 16-bit
> ushort has a 2-byte alignment on x86_64, so this forces the struct
> to also have an alignment of 2-
On Mon, Apr 27, 2015 at 10:31:38AM +0200, koneu wrote:
> Add to that, non-int bit fields are a GNU extension.
You're right. It works because uint_least32_t happens to be a
typedef of unsigned int for x86_64. Changing it so that it reads:
>typedef struct {
> uint_least32_t u;
> unsigne
On Mon, Apr 27, 2015 at 10:29:25AM +0200, Roberto E. Vargas Caballero wrote:
> > typedef struct {
> > uint_least32_t u;
> > uint_least32_t mode:12;
> > uint_least32_t fg:10;
> > uint_least32_t bg:10;
> > } Glyph;
>
> The size of this struct is only one byte less than if the
> same
On Mon, Apr 27, 2015 at 10:09:20AM +0200, Roberto E. Vargas Caballero wrote:
> I have applied a version of this patch with short size.
Okay, thanks!
> Please, be careful with your commits, because this patch and the other
> you sent have a lot of white spaces changes that are not needed.
Okay, I
On April 27, 2015 10:29:25 AM CEST, "Roberto E. Vargas Caballero"
wrote:
>> typedef struct {
>> uint_least32_t u;
>> uint_least32_t mode:12;
>> uint_least32_t fg:10;
>> uint_least32_t bg:10;
>> } Glyph;
>
>The size of this struct is only one byte less than if the
>same of the
> typedef struct {
> uint_least32_t u;
> uint_least32_t mode:12;
> uint_least32_t fg:10;
> uint_least32_t bg:10;
> } Glyph;
The size of this struct is only one byte less than if the
same of the struct using shorts. You can test it if you
want.
Regards,
I have applied a version of this patch with short size.
> typedef struct {
> char c[UTF_SIZ]; /* character code */
> - ushort mode; /* attribute flags */
> - uint32_t fg; /* foreground */
> - uint32_t bg; /* background */
> + ushort mode; /* attribute fl
On Wed, Apr 22, 2015 at 05:26:37AM -0700, suigin wrote:
> > Another solution would be to allow people to typedef the color index
> > type used by Glyph in config.h, and move the definitions for Glyph,
> > TCursor and Term below where config.h is included in st.c?
> >
> > That way, it makes it easy
> Another solution would be to allow people to typedef the color index
> type used by Glyph in config.h, and move the definitions for Glyph,
> TCursor and Term below where config.h is included in st.c?
>
> That way, it makes it easy to customize it for a low memory profile.
Here's another patch t
On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote:
Sorry, I didn't realize it was possible to use colors above 256,
neglected to see it in config.def.h. My bad.
> Maybe, a solution can be modify colorname to:
>
> 63 static const char *colorname[256] = {
>
> and fo
At least we can safely reduce to uint16_t now.
On Tue, Apr 21, 2015 at 10:32:26AM -0700, Eric Pruitt wrote:
> On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote:
> > The problem here is that st was designed in this way, and to change it
> > is going to generate segfault in all the users that update the st
> > version wi
On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote:
> Guys, are you using colors upper 256?
I use it for my background and cursor colours.
On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote:
> The problem here is that st was designed in this way, and to change it
> is going to generate segfault in all the users that update the st
> version without changing the config file.
Is that really a concern? My st buil
Hi,
> Hello, I noticed that the Glyph struct was using more memory than was
> needed. Considering that the fg and bg colors have values that are
> always in the range of [0, 255], there is no need to use a uint32_t
> for them. A single byte each would suffice. Furthermore, assuming
This is a good
Hello, I noticed that the Glyph struct was using more memory than was
needed. Considering that the fg and bg colors have values that are
always in the range of [0, 255], there is no need to use a uint32_t
for them. A single byte each would suffice. Furthermore, assuming
default alignment and packin
19 matches
Mail list logo
