about __llseek

[keuntae.shin]

I have some question.

i study about a _llseek function

Definitely, Man page on linux show me that below
--------------------------------------------------------------
int _llseek(unsigned int fd, unsigned long offset_high,
unsigned
long offset_low, loff_t *result, unsigned int whence);
------------------------------------------------------------------

Of course , this function has five parameters!!

But if i get code by strace!
----------------------------------------------------------
_llseek(3, 0, [0], SEEK_SET) = 0
-----------------------------------------------------------

why this function has four parameters?

what's meanning four parameters?


thank you in advance

 

[Ian Collins]

I have some question.

i study about a _llseek function

That's a very much a Linux specific function, so you'd best ask on a
Linux programming group.

 

[Martin Ambuhl]

I have some question.

i study about a _llseek function

If you have a function called '_llseek', then it is specific to your
implementation. The leading underscore is a clue to this (although not
as solid a clue as it was before C99). Another clue which you had but
snipped from your quotation from the man page is the necessity to use a
non-standard header, commonly <unistd.h> for _llseek or llseek on
implementations that have them. Questions about such
implementation-specific functions are best asked in newsgroups, mailing
lists, or technical support for those implementations. The
implementation-specific experts hang out (surprise!) in the
implementation-specific newsgroups.

Neither _llseek nor llseek are standard in either POSIX or standard C.
I will offer some off-topic advice however.
Notice that this advise is off-topic, and is as reliable as information
on automobile transmissions answered by your local shoe salesmen, so
check your documentation or go to a Linux newsgroup to be sure it is
correct.
[Standard C (topical)]
The standard C functions are fseek and fsetpos. fseek takes a long
argument for the offset, while fsetpos takes a fpos_t argument for the
position. It is possible that an fpos_t is a unsigned long long on your
implementation and suffices for your purposes: you will need to check
your documentation. It is possible that even the long offset of fseek
will suffice. If not

[llseek (offtopic)]
Many Linux implementations provide an llseek function (no leading
underscore-. It typically takes a single offset_t (a non-standard type,
usually an unsigned long long or the same type as a size_t) rather than
a pair of unsigned longs as your _llseek does. Further, it usually
returns an offset_t rather than an int. It will usually be a better choice.

Definitely, Man page on linux show me that below
--------------------------------------------------------------
int _llseek(unsigned int fd, unsigned long offset_high,
unsigned
long offset_low, loff_t *result, unsigned int whence);
------------------------------------------------------------------

Of course , this function has five parameters!!

But if i get code by strace!

This is one reason to avoid non-standard functions. It appears that the
non-standard _llseek used in the code you are examining is defined in a
different way from the non-standard _llseek used by your implementation.
This is not a surprise: non-standard functions have no standard
definition, for goodness' sake. What is surprising is those square
braces on the third argument ('[0]'). This makes it suspect whether
this code is in C at all.

what's meanning four parameters?

Heaven knows. Ask the people who wrote the code for their
implementation of the non-standard _llseek. Better, use the more common
Linux-implementation provided function llseek. And even better, if
possible, use the the standard function, either fsetpos or fseek if
applicable.

 

[Richard]

I have some question.

i study about a _llseek function

If you have a function called '_llseek', then it is specific to your
implementation. The leading underscore is a clue to this (although
not as solid a clue as it was before C99). Another clue which you had
but snipped from your quotation from the man page is the necessity to
use a non-standard header, commonly <unistd.h> for _llseek or llseek
on implementations that have them. Questions about such
implementation-specific functions are best asked in newsgroups,
mailing lists, or technical support for those implementations. The
implementation-specific experts hang out (surprise!) in the
implementation-specific newsgroups.

Neither _llseek nor llseek are standard in either POSIX or standard
C. I will offer some off-topic advice however.
Notice that this advise is off-topic, and is as reliable as
information on automobile transmissions answered by your local shoe
salesmen, so check your documentation or go to a Linux newsgroup to be
sure it is correct.
[Standard C (topical)]

I would further add - also check with your local "shoe salesman" if the
information IS on topic as advice on ISO C is frequently incorrect too.

 

[Richard]

That's a very much a Linux specific function, so you'd best ask on a
Linux programming group.

It is a function used in C on Linux. Is there a C specific Linux group
which is active?

And you use Linux...

 

[Richard]

The leading underscore is a clue to this (although not
as solid a clue as it was before C99).

To the OP, Martin Ambuhl is incorrect here. Presumably Ambuhl is referring
to C89/C90's possible case insensitivity with external identifiers that
made both _[A-Z] and _[a-z] problematic. However, the latter is still
problematic in C99, as a quick glance at 7.1.3{1} will reveal:

All identifiers that begin with an underscore are always reserved
for use as identifiers with file scope in both the ordinary and
tag name spaces.

So I have no idea what "not as solid a clue" is supposed to mean
for the "leading underscore" function.

[llseek (offtopic)]
Many Linux implementations provide an llseek function (no leading
underscore-. It typically takes a single offset_t (a non-standard type,
usually an unsigned long long or the same type as a size_t) rather than
off_t.

a pair of unsigned longs as your _llseek does. Further, it usually
returns an offset_t rather than an int. It will usually be a better choice.

off_t.

To the OP: Don't use the llseek() function. See my reply to you for
the reason. Use lseek64() if you must.

This is one reason to avoid non-standard functions. It appears that the
non-standard _llseek used in the code you are examining is defined in a
different way from the non-standard _llseek used by your implementation.

Yes, I'm starting to see why the clique limits itself to ISO C.

This is not a surprise: non-standard functions have no standard
definition, for goodness' sake. What is surprising is those square
braces on the third argument ('[0]'). This makes it suspect whether
this code is in C at all.

It's typical strace notation, familiar to many real-world C programmers.
Not surprising at all.

Heaven knows. Ask the people who wrote the code for their
implementation of the non-standard _llseek. Better, use the more common
Linux-implementation provided function llseek. And even better, if
possible, use the the standard function, either fsetpos or fseek if
applicable.

Again, don't use llseek().

I missed the reason for that, Why not use llseek?

 

[Ben Bacarisse]

Definitely, Man page on linux show me that below
--------------------------------------------------------------
int _llseek(unsigned int fd, unsigned long offset_high,
unsigned
long offset_low, loff_t *result, unsigned int whence);
------------------------------------------------------------------

Of course , this function has five parameters!!

But if i get code by strace!

Even by the weakest topicality rules this is nothing to do with C. It
seems to be about how strace reports system calls.
comp.unix.programmer is the place to ask about what strace is doing.

what's meanning four parameters?

If I had to guess, since _llseek is a raw system call, strace knows
the parameters 2 and 3 are really one 64-bit integer so it reports
them combined as one parameter.

 

[Richard]

Even by the weakest topicality rules this is nothing to do with C. It
seems to be about how strace reports system calls.
comp.unix.programmer is the place to ask about what strace is doing.

Maybe he does not know this and THINKS it is C. Hell, it looks like C
code to me.

Hang on:


,----
| LLSEEK(2) -- 2007-06-01 -- Linux -- Linux Programmer's Manual
|
| NAME
| _llseek - reposition read/write file offset
|
| SYNOPSIS
| #include <sys/types.h>
| #include <unistd.h>
|
| int _llseek(unsigned int fd, unsigned long offset_high,
| unsigned long offset_low, loff_t *result,
| unsigned int whence);
|
| DESCRIPTION
| The _llseek() function repositions the offset of the open
| file associated with the file descriptor fd to
| (offset_high<<32) | offset_low bytes relative to the
| beginning of the file, the current position in the file, or
| the end of the file, depending on whether whence is
| SEEK_SET, SEEK_CUR, or SEEK_END, respectively. It returns
| the resulting file position in the argument result.
|
| RETURN VALUE
| Upon successful completion, _llseek() returns 0. Otherwise,
| a value of -1 is returned and errno is set to indicate the
| error.
`----

No, It is C.

If I had to guess, since _llseek is a raw system call, strace knows
the parameters 2 and 3 are really one 64-bit integer so it reports
them combined as one parameter.

Why guess? If you don't know ask or Google the API.

 

[Stephen Sprunk]

Definitely, Man page on linux show me that below
--------------------------------------------------------------
int _llseek(unsigned int fd, unsigned long offset_high,
unsigned
long offset_low, loff_t *result, unsigned int whence);
------------------------------------------------------------------

Of course , this function has five parameters!!

But if i get code by strace!

...
What is surprising is those square braces on the third argument
('[0]'). This makes it suspect whether this code is in C at all.

strace's output is not pure C. "[0]" is the syntax strace uses to show
that the argument points to the value zero, which is far more useful (in
the context of strace) than giving some pointer's value. It also has
its own syntax for arrays, structs, etc.

Heaven knows. Ask the people who wrote the code for their
implementation of the non-standard _llseek. Better, use the more common
Linux-implementation provided function llseek.

llseek() and _llseek() are deprecated precisely because of problems like
this. lseek64() or even lseek(), with the appropriate #defines, are
strongly preferred.

And even better, if possible, use the the standard function, either
fsetpos or fseek if applicable.

Those functions operate on FILE*s, not fds, so they are not drop-in
replacements.

S

 

[Ben Bacarisse]

Maybe he does not know this and THINKS it is C. Hell, it looks like C
code to me.

I knew he thought that. I, unlike you, was being helpful by
explaining that, despite appearances, his problem is not related to C
but how strace produces its output. Of course, because this groups is
not really the right place, I may be wrong and there may be no one who
know enough about strace and _llseek to correct me.

Hang on:

No, It is C.

The interface is, the problem is not. If you know otherwise and the
problem is a C one, please help the OP rather complaining about my
answer.

Why guess? If you don't know ask or Google the API.

I did. I did not find an answer so I guessed. You, presumably, have
either not taken your own advice or you too have not found an answer
by searching since I don't yet see your solution to the OP's problem.

 

[Antoninus Twink]

/* llseek doesn't have a prototype. Since the second parameter is a
64bit type, this results in wrong behaviour if no prototype is
provided. */

Which raises the question... why don't the gcc folks just provide a
prototype for it?

 

[Antoninus Twink]

I did. I did not find an answer so I guessed. You, presumably, have
either not taken your own advice or you too have not found an answer
by searching since I don't yet see your solution to the OP's problem.

Ben was exactly correct in his guess.

Here's the function from the strace source code that deals with printing
information for _llseek calls:

int
sys_llseek (tcp)
struct tcb *tcp;
{
if (entering(tcp)) {
/*
* This one call takes explicitly two 32-bit arguments hi, lo,
* rather than one 64-bit argument for which LONG_LONG works
* appropriate for the native byte order.
*/
if (tcp->u_arg[4] == SEEK_SET)
tprintf("%ld, %llu, ", tcp->u_arg[0],
(((long long int) tcp->u_arg[1]) << 32
| (unsigned long long) (unsigned) tcp->u_arg[2]));
else
tprintf("%ld, %lld, ", tcp->u_arg[0],
(((long long int) tcp->u_arg[1]) << 32
| (unsigned long long) (unsigned) tcp->u_arg[2]));
}
else {
long long int off;
if (syserror(tcp) || umove(tcp, tcp->u_arg[3], &off) < 0)
tprintf("%#lx, ", tcp->u_arg[3]);
else
tprintf("[%llu], ", off);
printxval(whence, tcp->u_arg[4], "SEEK_???");
}
return 0;
}

 

[Stephen Sprunk]

Which raises the question... why don't the gcc folks just provide a
prototype for it?

They used to. However, llseek() is now deprecated and people should use
lseek64() (or a 64-bit capable lseek()) instead.

S

 

[Ian Collins]

It is a function used in C on Linux. Is there a C specific Linux group
which is active?

And you use Linux...

Use maybe (my Sky box runs a version) but develop on, no I don't.

 

[CBFalconer]

I have some question.

i study about a _llseek function

Definitely, Man page on linux show me that below

There is no such function in standard C. I gather you are using
Linux, so your query belongs on some Linux group, or possibly
comp.unix.programmer. It is off-topic here.

 

[Ian Collins]

There is no such function in standard C. I gather you are using
Linux, so your query belongs on some Linux group, or possibly
comp.unix.programmer. It is off-topic here.

Late to the party again?