Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/sys/unix: C->Go type converter does not take integer field sign into account #44794

Open
anatol opened this issue Mar 4, 2021 · 1 comment
Open

x/sys/unix: C->Go type converter does not take integer field sign into account #44794

anatol opened this issue Mar 4, 2021 · 1 comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unreleased

Comments

@anatol
Copy link

anatol commented Mar 4, 2021

I am looking at Linux statfs structure that is defined in Linux UAPI as

/*
 * Most 64-bit platforms use 'long', while most 32-bit platforms use '__u32'.
 * Yes, they differ in signedness as well as size.
 * Special cases can override it for themselves -- except for S390x, which
 * is just a little too special for us. And MIPS, which I'm not touching
 * with a 10' pole.
 */
#ifndef __statfs_word
#if __BITS_PER_LONG == 64
#define __statfs_word __kernel_long_t
#else
#define __statfs_word __u32
#endif
#endif

struct statfs {
	__statfs_word f_type;
	__statfs_word f_bsize;
	__statfs_word f_blocks;
	__statfs_word f_bfree;
	__statfs_word f_bavail;
	__statfs_word f_files;
	__statfs_word f_ffree;
	__kernel_fsid_t f_fsid;
	__statfs_word f_namelen;
	__statfs_word f_frsize;
	__statfs_word f_flags;
	__statfs_word f_spare[4];
};

__statfs_word is marked as unsigned 32bit at 32bit platforms.

Now let's look at the generated code for a 32bit platform e.g. arm (unix/ztypes_linux_arm.go):

type Statfs_t struct {
        Type    int32
        Bsize   int32
        Blocks  uint64
        Bfree   uint64
        Bavail  uint64
        Files   uint64
        Ffree   uint64
        Fsid    Fsid
        Namelen int32
        Frsize  int32
        Flags   int32
        Spare   [4]int32
        _       [4]byte
}

Here Type field is signed int that differs from the UAPI intention.

This causes issues with a compiled code, like this for example:

if statfs.Type != unix.RAMFS_MAGIC {
  // foo bar
}

This code fails to compile for arm because unix.RAMFS_MAGIC is 0x858458f6 and does not match int32 at the left side.

statfs.Type should really be a uint32 type.
@gopherbot gopherbot added this to the Unreleased milestone Mar 4, 2021
@dmitshur dmitshur changed the title x/sys: C->Go type converter does not take integer field sign into account x/sys/unix: C->Go type converter does not take integer field sign into account Mar 6, 2021
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 8, 2021
@dmitshur
Copy link
Contributor

dmitshur commented Mar 8, 2021

CC @ianlancetaylor, @bradfitz, @tklauser via owners.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Unreleased
Development

No branches or pull requests
3 participants
@anatol @dmitshur @gopherbot