illegal seek

[smarty]

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,b uf);
perror("READ");
close(fd);
perror("CLOSE") ;
}
}

[CBFalconer]

Joachim Schmitz wrote:

>

.... snip ...

>
close() sets errno if (and only if) it fails, which it indicates
by returning -1.

The following is a legal definition of close:

int close(int parm) {
if (-1 == parm) parm++;
return parm;
}

which doesn't meet your description. The point is that close is
undefined in standard C. In this newsgroup the discussion stops
there.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

** Posted from http://www.teranews.com **

[Richard Heathfield]

CBFalconer said:

Richard Tobin wrote:

>CBFalconer <cb********@mai neline.netwrote :

>>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.

Since it is not written in C,

It sure looks like C to me.

who knows what is wrong with it.

comp.unix.progr ammer knows what's wrong with it.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jack Klein]

On 14 May 2008 12:10:58 GMT, ri*****@cogsci. ed.ac.uk (Richard Tobin)
wrote in comp.lang.c:

In article <79************ *************** *******@a70g200 0hsh.googlegrou ps.com>,
Szabolcs Borsanyi <bo******@thphy s.uni-heidelberg.dewr ote:

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

In that case, the problem is system-specific, and he should take it up
with the Linux developers. It is a QOI issue, at best, since the
standard allows perror() to modify errno so long as it uses the
original value to produce output before modifying it.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Antoninus Twink]

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)."

[Joachim Schmitz]

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

[CBFalconer]

Joachim Schmitz wrote:

Antoninus Twink wrote:

>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():

.... snip posix? definition ...

>
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.

Of course the Twink-troll also snipped my explanation, which
follows below:

>>which doesn't meet your description. The point is that
close is undefined in standard C. In this newsgroup the
discussion stops there.

which is part of the trolls standard mechanism, aiming to disturb
the normal operation of the newsgroup. I see no reason to ever use
open, close and read, when fopen, fclose and fread are available
everywhere, and portable.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Nick Keighley]

On May 16, 7:39*am, "Joachim Schmitz" <nospam.j...@sc hmitz-digital.de>
wrote:

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 .

but not all. Since when was Posix on-topic to comp.lang.c

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.

I'm pretty sure I've created a function called close() that
didn't match the Posix spec. (I'll not argue it was a
really good idea)

--
Nick Keighley

[Antoninus Twink]

On 16 May 2008 at 18:00, Walter Roberson wrote:

In every extension I can currently think of that supports
the operations listed, open(), close() and read() are unnecessary
for any of the listed operations: those operations work on file
descriptors, and one can determine a FILE's file descriptor using
the fileno() extension upon a file that one has fopen()'d.

Are you saying that to create a file with 640 permissions you would use
fopen+fileno+fc ntl rather than just open()?

[Walter Roberson]

In article <sl************ *******@nospam. invalid>,
Antoninus Twink <no****@nospam. invalidwrote:

>On 16 May 2008 at 18:00, Walter Roberson wrote:

>In every extension I can currently think of that supports
the operations listed, open(), close() and read() are unnecessary
for any of the listed operations: those operations work on file
descriptors, and one can determine a FILE's file descriptor using
the fileno() extension upon a file that one has fopen()'d.

>Are you saying that to create a file with 640 permissions you would use
fopen+fileno+f cntl rather than just open()?

fopen() followed by the fchmod() extension would do fine in situations
where race conditions were not an issue. (Your listed operation
was "work with" permissions, not the more difficult task of
handling files securely.)
--
"Pray do not take the pains / To set me right. /
In vain my faults ye quote; / I wrote as others wrote /
On Sunium's hight." -- Walter Savage Landor

[jacob navia]

Walter Roberson wrote:

In article <sl************ *******@nospam. invalid>,
Antoninus Twink <no****@nospam. invalidwrote:

>On 16 May 2008 at 10:25, CBFalconer wrote:

>>I see no reason to ever use open, close and read, when fopen, fclose
and fread are available everywhere, and portable.

>Here are the first few that spring to mind:

>* to be able to work with file permissions and ownership
* getting file information with fstat (e.g. the size of a file)
* locking files with fcntl or flock
* getting file change notifications with fcntl
* to be able to send ioctls to devices

Those all involve extensions beyond the perview of C itself, and
are best discussed in a newsgroup that deals with the scope of the
extensions required (e.g., POSIX is going to have different behaviours
than Linux or MS Windows.)

In every extension I can currently think of that supports
the operations listed, open(), close() and read() are unnecessary
for any of the listed operations: those operations work on file
descriptors, and one can determine a FILE's file descriptor using
the fileno() extension upon a file that one has fopen()'d.
And if there are OS's that support file descriptors but do not
offer fileno() but still offer the listed operations, then such
OSs would certainly not be operating in any standardized way, which
would make it even more important to discuss the details in
an appropriate newsgroup rather than here.

You snipped one part of the answer of Mr Twink:

You have no interest in any program more
complicated than a solution to one of the exercises in K&R. You have an
arrogant disdain for people who dirty their hands with real-world
programming, when they might come across good reasons to use open, close
and read.

Why would you need to use fileno each time when you just
use open/close etc and be done with it?

You gave no valid reason.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32