On Wed, Jan 01, 2025 at 10:11:24PM +0100, Samuel Thibault wrote:
> Diego Nieto Cid, le mer. 01 janv. 2025 20:07:04 +, a ecrit:
> > On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > > /* Structure used for storage of ancillary data object information.
> > > > */
> > >
Diego Nieto Cid, le mer. 01 janv. 2025 21:03:23 +, a ecrit:
> On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> > On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > >
> > > > /* Structure used for storage of ancillary data object information.
> > > >
Diego Nieto Cid, le mer. 01 janv. 2025 20:07:04 +, a ecrit:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghdr
> > > {
> > > socklen_t cmsg_len;
On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > >
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghdr
> > > {
> > > socklen_t cmsg_len
On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> >
> > /* Structure used for storage of ancillary data object information. */
> > struct cmsghdr
> > {
> > socklen_t cmsg_len; /* Length of data in cmsg_data plus
> > length
> >
Diego Nieto Cid, le mar. 31 déc. 2024 20:48:08 +, a ecrit:
> On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
> >
> > Adding the following line to the program:
> >
> > printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
> >
> > shows 12 on Hurd and 16 on Linux. I think I'm
On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
>
> Adding the following line to the program:
>
> printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
>
> shows 12 on Hurd and 16 on Linux. I think I'm closer :)
The only difference in the structure definition is the cmsg_len f
On Tue, Dec 31, 2024 at 08:25:00PM +, Diego Nieto Cid wrote:
> On Tue, Dec 31, 2024 at 04:01:08PM +, Diego Nieto Cid wrote:
> >
> > Ok, I'll have a look in both OSes behaviour.
>
> There's something wrong with our CMSG_DATA macro. It produces the wrong
> output (or at least different fro
On Tue, Dec 31, 2024 at 04:01:08PM +, Diego Nieto Cid wrote:
>
> Ok, I'll have a look in both OSes behaviour.
There's something wrong with our CMSG_DATA macro. It produces the wrong
output (or at least different from Linux).
The attached program prints:
cmsg: 0x101040a90; data: 0x10104
Hi,
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
>
> You should probably check precisely the difference between Linux and
> Hurd on these alignment questions at the various stages.
>
I placed a `g_message` call in `g_unix_credentials_message_deserialize` and
on Linux it does
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le mar. 31 déc. 2024 14:36:02 +0100, a ecrit:
> > > I'm not sure how to fix it. Should the expectations of GLib be updated
> > > to be aligned? Like below:
> > >
> > > - if (size != G_CREDENTIALS_NATIVE_SIZE)
> > >
Samuel Thibault, le mar. 31 déc. 2024 14:36:02 +0100, a ecrit:
> > I'm not sure how to fix it. Should the expectations of GLib be updated
> > to be aligned? Like below:
> >
> > - if (size != G_CREDENTIALS_NATIVE_SIZE)
> > + if (size != CMSG_ALIGN(G_CREDENTIALS_NATIVE_SIZE))
> >
> > Or should the
Diego Nieto Cid, le mar. 31 déc. 2024 02:47:35 +, a ecrit:
> On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
> >
> > Here are the results for `hurd-amd64`:
> >
> > $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> > -pthread cred_size.c -lgi
On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
>
> Here are the results for `hurd-amd64`:
>
> $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> -pthread cred_size.c -lgio-2.0 -lgobject-2.0 -lglib-2.0 \
> -o cred_size
>
> $ ./cred_s
On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
>
> See the error test, it's about G_CREDENTIALS_NATIVE_SIZE, see its
> definition:
>
> #define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct cmsgcred))
>
> And the definition of struct cmsgcred in bits/socket.h
>
I wrote a little tes
Hello,
Sergey Bugaev, le lun. 30 déc. 2024 16:44:24 +0300, a ecrit:
> This feels like an opportunity to remind everyone that the SCM_CREDS
> implementation, which is shipped as a Debian downstream patch, doesn't
> actually verify the credentials. I have posted a more detailed
> description [0] bac
Hello,
On Mon, Dec 30, 2024 at 3:36 AM Diego Nieto Cid wrote:
>
> On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Diego Nieto Cid, le dim. 29 déc. 2024 22:14:40 +, a ecrit:
> > > (ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a
> > >
On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
> Hello,
>
> Diego Nieto Cid, le dim. 29 déc. 2024 22:14:40 +, a ecrit:
> > (ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a
> > credentials
> > struct of 84 bytes but got 88 bytes of data
> >
> > whic
Hello,
Diego Nieto Cid, le dim. 29 déc. 2024 22:14:40 +, a ecrit:
> (ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a
> credentials
> struct of 84 bytes but got 88 bytes of data
>
> which I traced to the GIO function g_unix_credentials_message_deserialize
> (which
>
Hello,
I'm trying to build the ibus source package and the tests fail with the
following error:
(ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a
credentials
struct of 84 bytes but got 88 bytes of data
which I traced to the GIO function g_unix_credentials_message_deser
20 matches
Mail list logo
