mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Ivan Kanakarakis <ivan.kanak@gmail.com>
To: musl@lists.openwall.com
Subject: Re: Fix for fields in utmp
Date: Fri, 12 Apr 2013 14:23:18 +0300	[thread overview]
Message-ID: <CAJnvVWVG8EtGgKHGc3biF+9kLJdMQ1ce+MAZs22CWdBOY-L+0A@mail.gmail.com> (raw)
In-Reply-To: <20130304220610.GQ20323@brightrain.aerifal.cx>


[-- Attachment #1.1: Type: text/plain, Size: 4881 bytes --]

I update musl-git and rerun nsz's test, here are the current results
in case you see something to be fixed before the release..

--- data/glibc.sizeof 2013-04-12 14:01:35.768425683 +0300
+++ data/musl.sizeof 2013-04-12 14:01:35.771759052 +0300
@@ -112,4 +112,4 @@
 int8_t 1
-int_fast16_t 8
-int_fast32_t 8
+int_fast16_t 4
+int_fast32_t 4
 int_fast64_t 8
@@ -122,3 +122,3 @@
 intptr_t 8
-jmp_buf 200
+jmp_buf 64
 key_t 4
@@ -183,4 +183,4 @@
 register_t 8
-regmatch_t 8
-regoff_t 4
+regmatch_t 16
+regoff_t 8
 res_state 8
@@ -222,3 +222,3 @@
 struct cmsghdr 16
-struct crypt_data 131232
+struct crypt_data 260
 struct dirent 280
@@ -282,3 +282,3 @@
 struct itimerval 32
-struct lastlog 292
+struct lastlog 296
 struct lconv 96
@@ -312,3 +312,3 @@
 struct ns_tsig_key 2072
-struct ntptimeval 72
+struct ntptimeval 32
 struct option 32
@@ -326,4 +326,4 @@
 struct rtentry 120
-struct rusage 144
-struct sched_param 4
+struct rusage 272
+struct sched_param 48
 struct sembuf 6
@@ -361,3 +361,3 @@
 struct strrecvfd 20
-struct sysinfo 112
+struct sysinfo 368
 struct termios 60
@@ -376,3 +376,3 @@
 struct utimbuf 16
-struct utmpx 384
+struct utmpx 400
 struct utsname 390
@@ -399,4 +399,4 @@
 uint8_t 1
-uint_fast16_t 8
-uint_fast32_t 8
+uint_fast16_t 4
+uint_fast32_t 4
 uint_fast64_t 8


also attached the diff



On 5 March 2013 00:06, Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Mar 03, 2013 at 12:29:57AM +0100, Szabolcs Nagy wrote:
> > > > > -int_fast16_t 8
> > > > > -int_fast32_t 8
> > > > > +int_fast16_t 4
> > > > > +int_fast32_t 4
> > > >
> > > > these diffs may cause problems
> > >
> > > These are actually omitted from the ABI documents if I remember
> >
> > ok then keep it as is
>
> This still should be checked. It _could_ be changed if it matters..
>
> > > > > -regex_t 64
> > > > > +regex_t 56
> > >
> > > I think this should be fixed to match.
> >
> > glibc's definition is something like:
> >
> > typedef struct {
> >       char *__x1;
> >       long __x2;
> >       long __x3;
> >       long __x4;
> >       char *__x5;
> >       char *__x6;
> >       size_t re_nsub;
> >       char __x7;
> > } regex_t;
> >
> > musl's definition (only re_nsub and __opaque are used):
> >
> > typedef struct {
> >       size_t re_nsub;
> >       void *__opaque, *__padding[4];
> >       size_t __nsub2;
> > } regex_t;
>
> Fixed, even though it doesn't matter with the other ABI
> incompatibility issues.
>
> > > > > -regmatch_t 8
> > > > > -regoff_t 4
> > > > > +regmatch_t 16
> > > > > +regoff_t 8
> > >
> > > These are a bug in glibc; their types do not conform to the
> > > requirements imposed on regex.h and regexec().
> >
> > so regex abi wont be compatible
>
> Yes, this will need some special dynamic linker glue if we want to be
> able to run glibc libs/bins using regex. But it's likely they might
> not work anyway without glibc extensions...
>
> > > > > -siginfo_t 128
> > > > > +siginfo_t 136
> > >
> > > This is probably a mistake, maybe in the padding..?
> >
> > yes, the si_fields union is 8byte aligned
>
> Fixed.
>
> > > > > -struct arpd_request 40
> > > > > +struct arpd_request 28
> > >
> > > No idea.
> >
> > i think this is not used anymore
>
> Fixed anyway.
>
> > > > > -struct lastlog 292
> > > > > +struct lastlog 296
> > >
> > > Probably needs to be checked.
> >
> > glibc's definition:
> > (using the same hack for time_t as in utmpx)
>
> This can probably be ignored. The files will be incompatible, but it's
> intended that they not be used anyway..
>
> > > > > -struct ntptimeval 72
> > > > > +struct ntptimeval 32
> > >
> > > Should we change this? Probably.
> >
> > musl does not have ntp_gettime so it probably
> > should not define this struct
>
> You're probably right, but I'm holding off a bit on removing it in
> case others have input..
>
> > > > > -struct rusage 144
> > > > > -struct sched_param 4
> > > > > +struct rusage 272
> > > > > +struct sched_param 48
> > >
> > > Not sure about rusage. For sched_param, we support the extra fields
> > > for the sporadic server option even though we don't support it (and
> > > Linux probably never will).
> >
> > musl's rusage (the difference is the __reserved part):
>
> Should we change it or keep the extra reserved space?
>
> > > > > -struct sockaddr_storage 128
> > > > > +struct sockaddr_storage 136
> > >
> > > Probably wrong.
> >
> > wrong padding
>
> Fixed.
>
> > > > > -wctrans_t 8
> > > > > -wctype_t 8
> > > > > +wctrans_t 4
> > > > > +wctype_t 4
> > > >
> > > > it seems wctype_t is unconditionally long in glibc
> > >
> > > As it should be. This is a bug in musl. Being an opaque type that
> > > could (and often should) be implemented as a pointer, wctype_t should
> > > always be pointer-sized.
> >
> > then this should be fixed
>
> I will fix this, but as a separate commit since it actually has
> nontrivial effects.
>
> Rich
>



-- 
*Ivan c00kiemon5ter Kanakarakis*  >:3

[-- Attachment #1.2: Type: text/html, Size: 14380 bytes --]

[-- Attachment #2: sizeof.diff --]
[-- Type: application/octet-stream, Size: 1154 bytes --]

--- data/glibc.sizeof	2013-04-12 14:01:35.768425683 +0300
+++ data/musl.sizeof	2013-04-12 14:01:35.771759052 +0300
@@ -112,4 +112,4 @@
 int8_t	1
-int_fast16_t	8
-int_fast32_t	8
+int_fast16_t	4
+int_fast32_t	4
 int_fast64_t	8
@@ -122,3 +122,3 @@
 intptr_t	8
-jmp_buf	200
+jmp_buf	64
 key_t	4
@@ -183,4 +183,4 @@
 register_t	8
-regmatch_t	8
-regoff_t	4
+regmatch_t	16
+regoff_t	8
 res_state	8
@@ -222,3 +222,3 @@
 struct cmsghdr	16
-struct crypt_data	131232
+struct crypt_data	260
 struct dirent	280
@@ -282,3 +282,3 @@
 struct itimerval	32
-struct lastlog	292
+struct lastlog	296
 struct lconv	96
@@ -312,3 +312,3 @@
 struct ns_tsig_key	2072
-struct ntptimeval	72
+struct ntptimeval	32
 struct option	32
@@ -326,4 +326,4 @@
 struct rtentry	120
-struct rusage	144
-struct sched_param	4
+struct rusage	272
+struct sched_param	48
 struct sembuf	6
@@ -361,3 +361,3 @@
 struct strrecvfd	20
-struct sysinfo	112
+struct sysinfo	368
 struct termios	60
@@ -376,3 +376,3 @@
 struct utimbuf	16
-struct utmpx	384
+struct utmpx	400
 struct utsname	390
@@ -399,4 +399,4 @@
 uint8_t	1
-uint_fast16_t	8
-uint_fast32_t	8
+uint_fast16_t	4
+uint_fast32_t	4
 uint_fast64_t	8

      reply	other threads:[~2013-04-12 11:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 18:23 Chris Spiegel
2013-02-20 18:49 ` Szabolcs Nagy
2013-02-21  0:56   ` Rich Felker
2013-02-26  6:49     ` Rich Felker
2013-02-26  9:22       ` Szabolcs Nagy
2013-02-26 10:34         ` Ivan Kanakarakis
2013-02-26 20:21           ` Szabolcs Nagy
2013-02-26 23:33             ` Rich Felker
2013-03-02 23:29               ` Szabolcs Nagy
2013-03-04 22:06                 ` Rich Felker
2013-04-12 11:23                   ` Ivan Kanakarakis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJnvVWVG8EtGgKHGc3biF+9kLJdMQ1ce+MAZs22CWdBOY-L+0A@mail.gmail.com \
    --to=ivan.kanak@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).