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