From: Greg Banks <gnb@melbourne.sgi.com>
To: markgw@sgi.com
Cc: Eric Sandeen <sandeen@sandeen.net>, Timothy Shimmin <tes@sgi.com>,
Richard Scobie <richard@sauce.co.nz>,
xfs@oss.sgi.com
Subject: Re: Filestreams (and 64bit inodes)
Date: Fri, 13 Jun 2008 13:40:29 +1000 [thread overview]
Message-ID: <4851EC2D.6010504@melbourne.sgi.com> (raw)
In-Reply-To: <4851E774.2070401@sgi.com>
Mark Goodwin wrote:
>
>
> Greg Banks wrote:
>> Eric Sandeen wrote:
>>> 4070 29.1% are scripts (shell, perl, whatever)
>>> 6598 47.2% don't use any stat() family calls at all
>>> 1829 13.1% use 32-bit stat() family interfaces only
>>> 1312 9.4% use 64-bit stat64() family interfaces only
>>> 180 1.3% use both 32-bit and 64-bit stat() family interfaces
>>>
>> Ouch. That's over two thousand executables to patch, rebuild, and ship.
>>> list of packages, sorted by the semi-lame "number of files in package
>>> which call a 32-bit stat variant" metric:
>>>
>>> http://sandeen.fedorapeople.org/stat32-ers
>
> struct dirent has an embedded ino_t too, so for completeness we should
> also
> be looking for readdir(), readdir64(), getdirentries(),
> getdirentries64(), etc.
Good point. Looking in the code, it seems the getdents common code in
glibc will fail with EOVERFLOW if the inode number gets truncated during
64b-32b translation, just like the stat() family. I'll need to improve
the scanning tool :-)
>
>>> I'm going to see if I can't leverage Fedora to clean some of this up.
>>>
>>> -Eric
>>>
>> Good luck with that.
>
> Yes good luck :)
> (and the plan for statically linked apps? ...)
Perhaps Fedora could enable the glibc magic for issuing warnings at link
time when those symbols are used, like what happens today if you use the
old unsafe gets() function:
gnb@inara 1058> gcc -o fmeh x.c
/tmp/ccQhxIIo.o: In function `main':
x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used.
--
Greg Banks, P.Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.
next prev parent reply other threads:[~2008-06-13 3:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-07 23:11 Filestreams Richard Scobie
2008-06-09 3:31 ` Filestreams Eric Sandeen
2008-06-10 1:49 ` Filestreams Timothy Shimmin
2008-06-10 2:14 ` Filestreams Richard Scobie
2008-06-10 23:09 ` Filestreams (and 64bit inodes) Richard Scobie
2008-06-11 1:39 ` Timothy Shimmin
2008-06-11 2:47 ` Richard Scobie
2008-06-11 3:23 ` Eric Sandeen
2008-06-12 13:52 ` Eric Sandeen
2008-06-13 1:28 ` Greg Banks
2008-06-13 3:06 ` Eric Sandeen
2008-06-13 3:24 ` Greg Banks
2008-06-13 3:20 ` Mark Goodwin
2008-06-13 3:40 ` Greg Banks [this message]
2008-06-13 3:46 ` Eric Sandeen
2008-06-13 3:57 ` Greg Banks
2008-06-13 5:35 ` Greg Banks
2008-06-13 13:28 ` Eric Sandeen
2008-06-13 3:45 ` Eric Sandeen
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=4851EC2D.6010504@melbourne.sgi.com \
--to=gnb@melbourne.sgi.com \
--cc=markgw@sgi.com \
--cc=richard@sauce.co.nz \
--cc=sandeen@sandeen.net \
--cc=tes@sgi.com \
--cc=xfs@oss.sgi.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox