Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > illegal seek

Reply
Thread Tools

illegal seek

 
 
smarty
Guest
Posts: n/a
 
      05-14-2008
this code gives an "illegal seek error" on close() call
what is this error and when does it come?

main()
{
int fd,num;
char buf[150];
fd = open ("123.c",O_RDWR);
if(fd!=-1)
{

printf("a file with fd=%d is opened\n",fd);
num=read(fd,buf,150);
printf("num=%d\nREAD:%s",num,buf);
perror("READ");
close(fd);
perror("CLOSE");
}
}
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      05-14-2008
In article <(E-Mail Removed)>,
smarty <(E-Mail Removed)> wrote:
>this code gives an "illegal seek error" on close() call
>what is this error and when does it come?


Your code contains several errors, notably printing a potentially
unterminated string from buf.

But the particular problem you are asking about seems to be that
Linux's perror() often changes errno. I don't think this is legal,
but I don't have the standard to hand.

-- Richard
--
:wq
 
Reply With Quote
 
 
 
 
Szabolcs Borsanyi
Guest
Posts: n/a
 
      05-14-2008
>
> But the particular problem you are asking about seems to be that
> Linux's perror() often changes errno. I don't think this is legal,
> but I don't have the standard to hand.


Well, a standard library function may set errno to a non-zero
function, unless
the use of errno is documented in the standard (even if there was no
error).
The use of errno in perror() is documented in the standard as using
its
value.

By the way, the read/open/close functions are not standard library
functions.
So nothing is known about them. I don't quite remember the posix
specifications,
but I am not sure if errno can put to a positive value on success.
The return value of these functions might better indicate the error
condition.
The standard fopen/fread/fclose functions might equally well do the
task, I'd think. Then you have ferror, too.
Putting errno=0 before a standard library, that has a documented use
of
errno, and reading errno then seems to me legal, too.

Szabolcs
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      05-14-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Tobin) writes:

> In article <(E-Mail Removed)>,
> smarty <(E-Mail Removed)> wrote:
>>this code gives an "illegal seek error" on close() call
>>what is this error and when does it come?

>
> Your code contains several errors, notably printing a potentially
> unterminated string from buf.
>
> But the particular problem you are asking about seems to be that
> Linux's perror() often changes errno. I don't think this is legal,
> but I don't have the standard to hand.


Hmmm... The standard says:

"The value of errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno is not
documented in the description of the function in this International
Standard."

perror "documents the use of errno" so it seems it is not permitted to
change it. Of course, if the intent of that phrase it to permit
functions to change errno provided they are not documented as
*setting* it in some specific way, then perror *is* allowed to set it
nonzero. But then, why use the obviously broad phrase "use of"?

In practise, it hardly matters. One should only rely on the value
immediately following a function call that has failed in a way that
documents the setting of errno and this is the problem the OP is
having. Even if perror stuck to the letter of the standard, both the
printf and the close call can make it nonzero (even if there is no
error).

--
Ben.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      05-14-2008
In article <(E-Mail Removed)>,
Szabolcs Borsanyi <(E-Mail Removed)-heidelberg.de> wrote:

>By the way, the read/open/close functions are not standard library
>functions.
>So nothing is known about them. I don't quite remember the posix
>specifications,
>but I am not sure if errno can put to a positive value on success.


The use of those functions is irrelevant to the perror() problem.
The following program exhibits the same behavious on Linux:

#include <stdio.h>

int main(void)
{
perror("one");
perror("two");
return 0;
}

When I run it here it prints

one: Success
two: Illegal seek

-- Richard
--
:wq
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      05-14-2008
In article <(E-Mail Removed)>,
CBFalconer <(E-Mail Removed)> wrote:
>Who knows. There are no such functions as 'open', 'read', 'close'
>in standard C.


As it turns out, it's nothing to do with those functions.

-- Richard
--
:wq
 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-14-2008

"smarty" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> this code gives an "illegal seek error" on close() call
> what is this error and when does it come?
>
> main()
> {
> int fd,num;
> char buf[150];
> fd = open ("123.c",O_RDWR);
> if(fd!=-1)
> {
>
> printf("a file with fd=%d is opened\n",fd);
> num=read(fd,buf,150);
> printf("num=%d\nREAD:%s",num,buf);
> perror("READ");
> close(fd);
> perror("CLOSE");
> }
> }

close() sets errno if (and only if) it fails, which it indicates by
returning -1.
printf() returns a negative value on failure.
Only use perror() directly after a failed function call that is documented
to set errno on failure or set errno to 0 prior to calling that function.

Bye, Jojo


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-14-2008
CBFalconer <(E-Mail Removed)> writes:
> smarty wrote:
>>
>> this code gives an "illegal seek error" on close() call
>> what is this error and when does it come?
>>
>> main()
>> {
>> int fd,num;
>> char buf[150];
>> fd = open ("123.c",O_RDWR);
>> if(fd!=-1)
>> {
>>
>> printf("a file with fd=%d is opened\n",fd);
>> num=read(fd,buf,150);
>> printf("num=%d\nREAD:%s",num,buf);
>> perror("READ");
>> close(fd);
>> perror("CLOSE");
>> }
>> }

>
> Who knows. There are no such functions as 'open', 'read', 'close'
> in standard C. Look up, and use, fopen and fclose, and check the
> various standard library calls for means of reading numbers.


Those are POSIX functions. The OP might well have a good reason to
use them instead of the C standard functions fopen, fread, and fclose
(the POSIX functions provide some features that the standard C
functions don't). The quoted program doesn't demonstrate any such
reason, but it's obviously just a sample.

But yes, it's generally better to use the standard C I/O functions
*unless* you have a specific reason to use the POSIX functions and pay
the price of losing some portability.

(Incidentally, the program has nothing to do with reading numbers; num
is the number of bytes read.)

Some incidental advice for the original poster:

Write "int main(void)" rather than "main()".

Adding a blank after each comma, after the "if" keyword, and before
and after each binary operator, aids readability.

Since main returns an int, it should do so: add "return 0;" before the
closing brace. There are circumstances in which this is not necessary
(if you're using a C99 implementation, or if you don't care about the
status returned to the host environment), but it never hurts, and it's
a good habit.

And, of course, you should examine the value of errno only after you
know a function has failed (but check the function's documentation to
find out whether it even sets errno).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      05-15-2008
On 14 May 2008 at 16:39, CBFalconer wrote:
> The following is a legal definition of close:
>
> int close(int parm) {
> if (-1 == parm) parm++;
> return parm;
> }


Wrong. It fails to meet the specification for close():

"The close() function shall deallocate the file descriptor indicated
by fildes. To deallocate means to make the file descriptor available for
return by subsequent calls to open() or other functions that allocate
file descriptors. All outstanding record locks owned by the process on
the file associated with the file descriptor shall be removed (that is,
unlocked)."

 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-16-2008
Antoninus Twink wrote:
> On 14 May 2008 at 16:39, CBFalconer wrote:
>> The following is a legal definition of close:
>>
>> int close(int parm) {
>> if (-1 == parm) parm++;
>> return parm;
>> }

>
> Wrong. It fails to meet the specification for close():
>
> "The close() function shall deallocate the file descriptor indicated
> by fildes. To deallocate means to make the file descriptor available
> for return by subsequent calls to open() or other functions that
> allocate file descriptors. All outstanding record locks owned by the
> process on the file associated with the file descriptor shall be
> removed (that is, unlocked)."

Guess you missed his point: close() is not in the C-Standard, hence there is
no specification.
Chuck simply ignores that close() exists in POSIX and is available to the
vast majority of implementations. He also ignored the fact that the OP did
use close() and that the most likely reason is that this is because it is
provided by his implementation.

Bye, Jojo


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Illegal seek with os.popen pruebauno@latinmail.com Python 4 06-04-2009 09:28 PM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net 2 07-29-2008 09:50 AM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net Building Controls 0 07-29-2008 01:37 AM
Illegal Seek - Any Hints codefixer@gmail.com Perl Misc 3 04-04-2005 05:02 PM
illegal seek Dave Saville Perl Misc 21 09-17-2003 04:00 PM



Advertisments