public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bazsi at balabit dot hu" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/4328] New: struct stat is bogus when __USE_FILE_OFFSET64 is defined Date: Fri, 06 Apr 2007 08:41:00 -0000 [thread overview] Message-ID: <20070406094051.4328.bazsi@balabit.hu> (raw) when __USE_FILE_OFFSET64 is defined fstat() should behave the same as fstat64(), and struct stat should be compatible with struct stat64. This is not the case on my ubuntu edgy system with glibc 2.4-1ubuntu12, but the same seems to be true for glibc 2.5 as well. The problem is best described with this gdb session snippet: (gdb) p (char *)&st.st_size - (char *) &st $11 = 48 (gdb) p (char *)&st64.st_size - (char *) &st64 $12 = 44 As you can guess, the st_size field contains a bogus value. I'm using this set of CPPFLAGS: -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 The problem is that bits/stat.h contains short int sized padN fields while struct stat64 contains int sized padding fields: struct stat { __dev_t st_dev; /* Device. */ unsigned short int __pad1; ... } struct stat64 { __dev_t st_dev; /* Device. */ unsigned int __pad1; } -- Summary: struct stat is bogus when __USE_FILE_OFFSET64 is defined Product: glibc Version: 2.4 Status: NEW Severity: critical Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: bazsi at balabit dot hu CC: glibc-bugs at sources dot redhat dot com GCC host triplet: i686-pc-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=4328 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
next reply other threads:[~2007-04-06 8:41 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-04-06 8:41 bazsi at balabit dot hu [this message] 2007-04-06 8:52 ` [Bug libc/4328] " jakub at redhat dot com 2007-04-06 9:38 ` bazsi at balabit dot hu 2007-04-06 9:54 ` bazsi at balabit dot hu
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=20070406094051.4328.bazsi@balabit.hu \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).