Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / Mac Programming / April 2008



Tip: Looking for answers? Try searching our database.

lseek fails from dylib, but not app

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
eric - 15 Apr 2008 21:17 GMT
I have some C code that uses open and lseek (and other functions of
course).  I build the C code using XCode as a dylib, I created the
project using the "BSD Dynamic Library" option.  I then created
another project as a "Cocoa Application".

Inside main.m in the app, I can use open and lseek fine.  However,
when the main.m file calls a function inside the dylib that calls open
and lseek, lseek always fails with EINVAL.  I know the file handle is
valid though -- calls to read() work with that same handle, it is only
lseek that fails.

I'm thinking maybe the file is being opened in a way that seeks are
not possible, like in a mode used for pipes or devices that do not
support seeking.  Maybe the default mode for open() is different for a
Cocoa Application project vs a BSD Dylib project?

Any help is greatly appreciated.  Also, what are the most popular Mac
developer forums/lists, and do I need to pay to access them?  I found
public lists on apple.com, but I think most of the real discussion is
on private lists... wherever those are.

I've got my code down to just this in both projects (same code works
in app, but not in dylib):

int fh;
fh = open("/test/test.dat",O_RDWR);
assert(fh != -1);
assert(lseek(fh,0,SEEK_SET) != -1);
close(fh);

The lseek line fails (returns -1), and I've had other code to check
errno, and it is set to EINVAL.  Again, same code works in app, but
fails in dylib.
eric - 15 Apr 2008 22:20 GMT
> I have some C code that uses open and lseek (and other functions of
> course).  I build the C code using XCode as a dylib, I created the
[quoted text clipped - 6 lines]
> valid though -- calls to read() work with that same handle, it is only
> lseek that fails.

It appears the problem was related to variable types.  I know lseek()
on Mac OSX is uses an off_t variable type, but my code which came over
from Windows uses int types.  I was just thrown off because the code
using "int" worked in one project, just not another, but must have
been differences in project settings or possibly Objective-C vs C.

Anyway, I'll have to make a wrapper for lseek, since I need the same
code to compile for Windows and Mac.
Robert Spykerman - 30 Apr 2008 03:10 GMT
> It appears the problem was related to variable types.  I know lseek()
> on Mac OSX is uses an off_t variable type, but my code which came over
[quoted text clipped - 4 lines]
> Anyway, I'll have to make a wrapper for lseek, since I need the same
> code to compile for Windows and Mac.

Yeah, I ran into the same problem. I was doing a linux -> os x port
and I discovered that off_t is 64 bits in BSD. Unsigned if I believe.
Took me a while to figure that out as I was calling lseek in assembly
and only passing it a 32 bit value. That was fun....

Not sure if you can add a conditional compilation option in the source
to fix most of your code, that possibly may be easier than a wrapper.
I did that, but I did not have very many calls to lseek to fix.

Robert Spykerman
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.