Bug 52843

Summary: do not use off_t in header - largefile sensitivity bugs
Product: [Unmaintained] kdelibs Reporter: Guido Draheim <guidod-2003->
Component: generalAssignee: Stephan Kulow <coolo>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Guido Draheim 2003-01-10 13:20:20 UTC 
Version:            (using KDE Devel)
Installed from:    Compiled sources

Through a discussion on alt.os.linux.mandrake, I had to notice
that every library has a risk of being broken when using the
system off_t type in its exported interfaces, including
structures and function synopsis.

The point comes from the fact that systems like linux and
solaris are "largefile sensitive" - a -D_LARGEFILE_SOURCE
will shift the "off_t" type from being a 32bit entity into
a 64bit entity. This will make for a nice and pretty
callframe mismatch.

Grepping a bit through header files installed on my system
it occurs to me that "kio/jobclasses.h" uses off_t and uses
functions and structures with it. More worrying, I had to 
notice that the kde plugins are sometimes compiled as 
largefile (referring to some fopen64) while others are not 
(importing the fopen symbol instead).

A autoconf'ed lib 'centric treatment of the topic is given in:
http://article.gmane.org/gmane.comp.sysutils.autoconf.general/1893

Given the platform independence layer of kde, it should be
easy to ensure that no exported call of any kdelibs uses
off_t - with c++ namemangling it is atleast improbable to 
end up in a callframe-mismatch but class size difference
might propagate into plugins.

Furthermore, it might be good to ask for a general policy
of compiling as largefile - every unix98 compatible system
must have largefile support and linux 2.4 / glibc 2.2 should
have no more bugs in this respect.

cheers,
-- guido                                 http://ac-archive.sf.net
Comment 1 Guido Draheim 2003-01-13 01:10:17 UTC 
http://ac-archive.sf.net/largefile

With a perl script that shows where off_t-mismatches are.
Comment 2 Stephan Kulow 2003-03-23 18:39:18 UTC 
I guess this needs to be fixed asap
Comment 3 Guido Draheim 2003-03-24 16:19:31 UTC 
I've updated the "off_t in headers" description. 
  http://ac-archive.sf.net/largefile/off_t_headers.html
The last (fine-print) paragraph does say this:

One thing that I do not want to announce all too loud: if you find an improper
usage of off_t in an older project, then you can add a quick hack by 
redefining those functions/structures to use int64_t instead of off_t. This 
will make structure-mismatch and callframe-mismatch problems to go away - but 
the seek problems will still exist and they might even hit you harder later 
since you've covered the usage of seek-offsets in a generic type instead of its
dedicated off_t type, and basically forgot about to fix the problem for real. 
Therefore, if you did not add proper ifdefs to defend against improper usage in
largefile-sensitive systems then better make a library typedef like `typedef 
int64_t mylib_off_t`. A later generation of that software may add proper check 
routines around this symbol.
(remember: UNIX98 systems are _required_ to provide 64bit LFS).
Comment 4 Waldo Bastian 2003-04-24 19:23:19 UTC 
Fixed for KDE 3.2