NULL returned by fopen - where is a list of what's causing the error?

[ferrad]

I am trying to open a file for appending. ie. if the file exists, open
it for appending, if not, create it. I am getting back a NULL pointer,
and do not know why. Here is my code:

FILE *pFile;
char *cFileName;
cFileName=argv[++i];
pFile = fopen(cFileName,"a+");

cFileName has a valid filename ('apm.dbg'), and I have full write
permissions in the directory. I can step into fopen and when the file
is opened, I can see in another window that the file is created with
zero bytes. However pFile is returned as NULL.

Is there a function call I can make to tell what the error actually is?

[Vladimir S. Oka]

ferrad wrote:

I am trying to open a file for appending. ie. if the file exists, open
it for appending, if not, create it. I am getting back a NULL pointer,
and do not know why. Here is my code:

FILE *pFile;
char *cFileName;
cFileName=argv[++i];
pFile = fopen(cFileName,"a+");
Your code is not compilable/runnable. E.g. what is 'i'?

cFileName has a valid filename ('apm.dbg'), and I have full write
permissions in the directory. I can step into fopen and when the file
is opened, I can see in another window that the file is created with
zero bytes. However pFile is returned as NULL.

Is there a function call I can make to tell what the error actually is?

AFAIK, the standard only specifies that fopen() returns NULL
when it fails for whatever reason:

7.19.5.3.8
The fopen function returns a pointer to the object controlling
the stream. If the open operation fails, fopen returns a null
pointer.

Cheers

Vladimir
--
My e-mail address is real, and I read it.

[Mike Wahler]

"ferrad" <ac***@hotmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

I am trying to open a file for appending. ie. if the file exists, open
it for appending, if not, create it. I am getting back a NULL pointer,
and do not know why. Here is my code:

FILE *pFile;
char *cFileName;
cFileName=argv[++i];
pFile = fopen(cFileName,"a+");

cFileName has a valid filename ('apm.dbg'), and I have full write
permissions in the directory. I can step into fopen and when the file
is opened, I can see in another window that the file is created with
zero bytes. However pFile is returned as NULL.

Is there a function call I can make to tell what the error actually is?

The only thing standard C says about the return value of
'fopen()' is that it will be NULL if the opening of the
file failed, and non-NULL if it succeeded.

Any particular reasons for failure will be platform-dependent.
You should consult your compiler and/or platform documentation
(e.g. for a list of 'error codes' which would give more
specific information). Many implementations provide extensions
for this very purpose.
-Mike

[Nelu]

ferrad wrote:

I am trying to open a file for appending. ie. if the file exists, open
it for appending, if not, create it. I am getting back a NULL pointer,
and do not know why. Here is my code:

FILE *pFile;
char *cFileName;
cFileName=argv[++i];
pFile = fopen(cFileName,"a+");

cFileName has a valid filename ('apm.dbg'), and I have full write
permissions in the directory. I can step into fopen and when the file
is opened, I can see in another window that the file is created with
zero bytes. However pFile is returned as NULL.

Is there a function call I can make to tell what the error actually is?

If you include string.h and errno.h you could use strerror(errno) to obtain
a string explaining the error.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[Richard Tobin]

In article <11*********************@g14g2000cwa.googlegroups. com>,
ferrad <ac***@hotmail.com> wrote:

Is there a function call I can make to tell what the error actually is?

On many systems the function perror will give you a useful error
message when fopen fails.

-- Richard

[Eric Sosman]

ferrad wrote On 01/20/06 11:35,:

I am trying to open a file for appending. ie. if the file exists, open
it for appending, if not, create it. I am getting back a NULL pointer,
and do not know why. Here is my code:

FILE *pFile;
char *cFileName;
cFileName=argv[++i];
pFile = fopen(cFileName,"a+");

cFileName has a valid filename ('apm.dbg'), and I have full write
permissions in the directory. I can step into fopen and when the file
is opened, I can see in another window that the file is created with
zero bytes. However pFile is returned as NULL.

Is there a function call I can make to tell what the error actually is?

On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like

pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);
die_or_maybe_proceed_to_next_file();
}

However, the C Standard doesn't promise that fopen()
will set `errno' on a failure, nor that the `errno'
value will be meaningful. On a system that doesn't
use `errno' for such things, you may get a misleading
message like "apm.dbg: socket type not supported" or
"apm.dbg: font not found," so consider what perror()
tells you but treat it with some skepticism.

Beyond that, the reasons fopen() might fail are
system-specific and not really "C reasons" at all.
You'll need to go snooping in your system's documentation
to see if there's a list of reasons for failure, and
even then it's quite possible the list is incomplete.
Good luck!

--
Er*********@sun.com

[ferrad]

Thanks for all the replies. Yes I know it's not compilable, it's just
an code excerpt.
I have now got the error description:
- when the file does not exist, I get ERROR_NEGATIVE_SEEK returned
- when the file does exist, I get ERROR_ALREADY_EXISTS returned

In both cases a NULL is returned in pFile. The platform is Microsoft
VS7 .NET

Adrian

[ferrad]

A Google search gives:
- when the file does not exist:
ERROR_NEGATIVE_SEEK
// An attempt was made to move a file pointer before the beginning of
the file.

- when the file does exist:
ERROR_ALREADY_EXISTS
// The system cannot create a file when it already exists.

Seems strange to me sine "a+" meand append is it exists, create it if
it doesn't.
Adrian

[Vladimir S. Oka]

ferrad wrote:

A Google search gives:
- when the file does not exist:
ERROR_NEGATIVE_SEEK
// An attempt was made to move a file pointer before the beginning of
the file.

- when the file does exist:
ERROR_ALREADY_EXISTS
// The system cannot create a file when it already exists.

Seems strange to me sine "a+" meand append is it exists, create it if
it doesn't.
Adrian

Please quote what you're replying to (even yourself).

What you found is system specific (and may not even apply to
/your/ system). Also see Eric's post elsethread which explains
it better that I could right now.

Cheers

Vladimir
--
My e-mail address is real, and I read it.

[ferrad]

The problem is actually caused by C / Fortran file format differences.
The text file is actually created, written to and closed in Fortran
first, then opened for appending in C as above. It appears that
something to do with the structure of the file in the two languages is
incompatible.
If anyone has some information on why C and Fortran can't write to the
same file, or what I have to do in C to get it to recognize the Fortran
text file, that would be appreciated.
Adrian

[Walter Roberson]

In article <11*********************@g14g2000cwa.googlegroups. com>,
ferrad <ac***@hotmail.com> wrote:

The problem is actually caused by C / Fortran file format differences.
The text file is actually created, written to and closed in Fortran
first, then opened for appending in C as above. It appears that
something to do with the structure of the file in the two languages is
incompatible.
Plausible.
If anyone has some information on why C and Fortran can't write to the
same file, or what I have to do in C to get it to recognize the Fortran
text file, that would be appreciated.

You mentioned earlier that you are using Windows. If I recall correctly,
the standard end of line marker used by Windows for a text file is
carriage return followed by linefeed. But when you create the file
in Fortran, are you telling FORTRAN that you are creating a text file?
If not, then it might be writing it using some internal FORTRAN binary
format that doesn't happen to use CR/LF .

In order to handle the file within C, you should open it in binary
mode (add "b" to the mode string, as in "rb" instead of "r"), and
then do whatever you need to do in order to decode the FORTRAN
line format.
--
Prototypes are supertypes of their clones. -- maplesoft

[ferrad]

> You mentioned earlier that you are using Windows. If I recall correctly,

the standard end of line marker used by Windows for a text file is
carriage return followed by linefeed. But when you create the file
in Fortran, are you telling FORTRAN that you are creating a text file?
If not, then it might be writing it using some internal FORTRAN binary
format that doesn't happen to use CR/LF .
Fortran writes a CR/LF at the end of each line.
In order to handle the file within C, you should open it in binary
mode (add "b" to the mode string, as in "rb" instead of "r"), and
then do whatever you need to do in order to decode the FORTRAN
line format.

I tried "ab" (append / binary), but still get the ERROR_ALREADY_EXISTS
error.

Adrian

PS. both Fortran and C DLLs are only trying to write to the file (no
reads).

[ferrad]

More investigation reveals that it doesn't matter where the text file
comes from (even written by C itself, so I think the Fortran bit above
is a red herring), the append mode of fopen does not appear to work.
Is this a non-standard C feature?
Adrian

[ferrad]

Actually, this whole thing is a VS.NET debugger aberration. The fopen
apparently returns a NULL pointer (and GetLastError() also is
non-zero), however when I execute fprintf on the pointer, the file
pointer becomes non-zero, and I write quite happily to the file.
Adrian

[Emmanuel Delahaye]

ferrad a écrit :

I am trying to open a file for appending. ie. if the file exists, open it for appending, if not, create it.
Why "a+" ? What's wrong with "a" ?
I am getting back a NULL pointer,
and do not know why. Here is my code:

FILE *pFile;
char *cFileName;
cFileName=argv[++i];
pFile = fopen(cFileName,"a+");

cFileName has a valid filename ('apm.dbg'), and I have full write
permissions in the directory. I can step into fopen and when the file
is opened, I can see in another window that the file is created with
zero bytes. However pFile is returned as NULL.

Is there a function call I can make to tell what the error actually is?

perror (cFileName);

--
A+

Emmanuel Delahaye

[RSoIsCaIrLiIoA]

On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

ferrad wrote On 01/20/06 11:35,: On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like
errno=0;
pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName); if(errno) perror(cFileName)
die_or_maybe_proceed_to_next_file();
}

[Eric Sosman]

RSoIsCaIrLiIoA wrote:

On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

ferrad wrote On 01/20/06 11:35,:

On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like

errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);

if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

--
Eric Sosman
es*****@acm-dot-org.invalid

[RSoIsCaIrLiIoA]

On Tue, 31 Jan 2006 07:54:20 -0500, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:

RSoIsCaIrLiIoA wrote:

On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

ferrad wrote On 01/20/06 11:35,:
On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like

errno=0;
This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.
pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);

if(errno) perror(cFileName)

^;
i say "if(errno) perror(cFileName);" at place of "perror(cFileName)"
This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

where is the nonsense, is it because i don't print the file name in
case fopen fail? i don't have "faq" list

[Eric Sosman]

RSoIsCaIrLiIoA wrote On 01/31/06 17:34,:

On Tue, 31 Jan 2006 07:54:20 -0500, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:

RSoIsCaIrLiIoA wrote:

On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

ferrad wrote On 01/20/06 11:35,:
On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like
errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);

if(errno) perror(cFileName)
^;
i say "if(errno) perror(cFileName);" at place of "perror(cFileName)"

Aha! I thought you intended to replace all of
`if (pFile == NULL) { perror(...); ...}' with
`if (errno) perror(...);'. (It's hard to make such
things clear simply by using indentation levels,
especially given the "> " quotation indicators.)
I retract my "nonsense" remark.
This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

where is the nonsense, is it because i don't print the file name in
case fopen fail? i don't have "faq" list

No longer "nonsense," but still unreliable for the
reasons explained in the FAQ. You may not have that
estimable document ready to hand, but I assume you're
able to cut-and-paste a URL into a browser.

--
Er*********@sun.com

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalid> writes:

RSoIsCaIrLiIoA wrote:

On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

ferrad wrote On 01/20/06 11:35,:

On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like

errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

Yes.

pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);

if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0. In that
case, the original code is likely to print something like:

foo.txt: No error

(I wonder why the standard doesn't require fopen() to set errno.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

RSoIsCaIrLiIoA <zz@zz.z> writes:

On Tue, 31 Jan 2006 07:54:20 -0500, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:

[...]

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

where is the nonsense, is it because i don't print the file name in
case fopen fail? i don't have "faq" list

If you have a web browser and an Internet connection, you can see the
FAQ at

<http://www.c-faq.com>

It works well even with a text-based browser such as Lynx.

If you can do ftp but not http, a gzipped plain ASCII copy is
available at

<ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz>

If you can't handle either of those, contact me directly with a valid
e-mail address and I'll be glad to send you a plain text copy by
e-mail. Let me know whether you want plain ASCII text or gzipped
text, and whether you can handle e-mail attachments (if not, I'll
include the plain text version in-line in the message). Since you use
a fake e-mail address, I promise not to divulge your e-mail address to
anyone unless truly extraordinary and unlikely circumstances require
me to do so.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark B]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Eric Sosman <es*****@acm-dot-org.invalid> writes:

RSoIsCaIrLiIoA wrote:

On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

ferrad wrote On 01/20/06 11:35,:

On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like
errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

Yes.

pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);
if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually succeeded.

7.5 #3 (draft)
.... 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.

Seems the only a library function can NOT do is explicitly set it to 0.

Mark

[Default User]

Keith Thompson wrote:

RSoIsCaIrLiIoA <zz@zz.z> writes:

where is the nonsense, is it because i don't print the file name in
case fopen fail? i don't have "faq" list

If you have a web browser and an Internet connection, you can see the
FAQ at

This clown (RSoIsCaIrLiIoA, not Keith) shows every now and then to
troll the group. I'd recommend a swift killfile from all.

Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Keith Thompson]

"Mark B" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Eric Sosman <es*****@acm-dot-org.invalid> writes:

RSoIsCaIrLiIoA wrote:
On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:

>ferrad wrote On 01/20/06 11:35,:

> On many systems, the `errno' pseudo-variable may
>give additional information about a failure. Try
>something like
errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

Yes.

> pFile = fopen(cFileName, "a+");
> if (pFile == NULL) {
> perror (cFileName);
if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark B]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Mark B" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Eric Sosman <es*****@acm-dot-org.invalid> writes:
RSoIsCaIrLiIoA wrote:
> On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:
>
>>ferrad wrote On 01/20/06 11:35,:
>
>> On many systems, the `errno' pseudo-variable may
>>give additional information about a failure. Try
>>something like
> errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

Yes.

>> pFile = fopen(cFileName, "a+");
>> if (pFile == NULL) {
>> perror (cFileName);
> if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually
succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

The code also assumes that if errno is set after failure that the
value will be meaningful... that is not guaranteed by the standard.
The only guarantee is that fopen() will not set errno = 0;

[Keith Thompson]

"Mark B" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Mark B" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Eric Sosman <es*****@acm-dot-org.invalid> writes:
> RSoIsCaIrLiIoA wrote:
>> On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:
>>
>>>ferrad wrote On 01/20/06 11:35,:
>>
>>> On many systems, the `errno' pseudo-variable may
>>>give additional information about a failure. Try
>>>something like
>> errno=0;
>
> This is a possible improvement in that it might help
> avoid nonsense messages from implementations that don't
> set errno when fopen() fails.

Yes.

>>> pFile = fopen(cFileName, "a+");
>>> if (pFile == NULL) {
>>> perror (cFileName);
>> if(errno) perror(cFileName)
>
> This, however, is nonsense. See Question 20.4 in
> the comp.lang.c Frequently Asked Questions (FAQ) list
> at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually
succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

The code also assumes that if errno is set after failure that the
value will be meaningful... that is not guaranteed by the standard.
The only guarantee is that fopen() will not set errno = 0;

In my opinion, it only assumes that if errno is set to a non-zero
value after failure, then that value is worth showing to the user.
(I have no idea what the author might have assumed.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Wright]

Keith Thompson wrote:

"Mark B" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Mark B" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

>Eric Sosman <es*****@acm-dot-org.invalid> writes:
>
>>RSoIsCaIrLiIoA wrote:
>>
>>>On Fri, 20 Jan 2006 -0500, Eric Sosman <er*********@sun.com> wrote:
>>>
>>>
>>>>ferrad wrote On 01/20/06 11:35,:
>>>
>>>> On many systems, the `errno' pseudo-variable may
>>>>give additional information about a failure. Try
>>>>something like
>>>
>>> errno=0;
>>
>> This is a possible improvement in that it might help
>>avoid nonsense messages from implementations that don't
>>set errno when fopen() fails.
>
>Yes.
>
>
>>>>pFile = fopen(cFileName, "a+");
>>>>if (pFile == NULL) {
>>>> perror (cFileName);
>>>
>>> if(errno) perror(cFileName)
>>
>> This, however, is nonsense. See Question 20.4 in
>>the comp.lang.c Frequently Asked Questions (FAQ) list
>>at http://c-faq.com/ .
>
>Not necessarily. The standard doesn't say that fopen() sets errno, so
>it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually
succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

The code also assumes that if errno is set after failure that the
value will be meaningful... that is not guaranteed by the standard.
The only guarantee is that fopen() will not set errno = 0;

In my opinion, it only assumes that if errno is set to a non-zero
value after failure, then that value is worth showing to the user.
(I have no idea what the author might have assumed.)

Don't you love it. The library can't set errno to 0. I can be set to any
positive number so long as the setting is not described in the Standard.
So puts() can set errno to 9 if it likes, as long as it doesn't tell
anybody. If you would document that, you can't do it.

Careful, reading the Standard too hard can make your head hurt.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Jordan Abel]

On 2006-02-02, Joe Wright <jo********@comcast.net> wrote:

Don't you love it. The library can't set errno to 0. I can be set to any
positive number so long as the setting is not described in the Standard.
So puts() can set errno to 9 if it likes, as long as it doesn't tell
anybody. If you would document that, you can't do it.
Eh? Your documentation isn't the standard - therefore you documenting it
doesn't make it "described in the standard" - the text you're referring
to just means that you can't do it if the standard specifically tells
you not to, or specifically says what it's set to.
Careful, reading the Standard too hard can make your head hurt.

[Joe Wright]

Jordan Abel wrote:

On 2006-02-02, Joe Wright <jo********@comcast.net> wrote:

Don't you love it. The library can't set errno to 0. I can be set to any
positive number so long as the setting is not described in the Standard.
So puts() can set errno to 9 if it likes, as long as it doesn't tell
anybody. If you would document that, you can't do it.

Eh? Your documentation isn't the standard - therefore you documenting it
doesn't make it "described in the standard" - the text you're referring
to just means that you can't do it if the standard specifically tells
you not to, or specifically says what it's set to.

Careful, reading the Standard too hard can make your head hurt.

[#3] The value of errno is zero at program startup, but is
never set to zero by any library function.159) 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.

Ok, I see it now. Thanks.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[RSoIsCaIrLiIoA]

On 01 Feb 2006 01:02:38 GMT, Keith Thompson <ks***@mib.org> wrote:

RSoIsCaIrLiIoA <zz@zz.z> writes:

On Tue, 31 Jan 2006 07:54:20 -0500, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:

[...]

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

where is the nonsense, is it because i don't print the file name in
case fopen fail? i don't have "faq" list

If you have a web browser and an Internet connection, you can see the
FAQ at

<http://www.c-faq.com>

It works well even with a text-based browser such as Lynx.

If you can do ftp but not http, a gzipped plain ASCII copy is
available at

<ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz>

If you can't handle either of those, contact me directly with a valid
e-mail address and I'll be glad to send you a plain text copy by
e-mail. Let me know whether you want plain ASCII text or gzipped
text, and whether you can handle e-mail attachments (if not, I'll
include the plain text version in-line in the message). Since you use
a fake e-mail address, I promise not to divulge your e-mail address to
anyone unless truly extraordinary and unlikely circumstances require
me to do so.

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

[Vladimir S. Oka]

RSoIsCaIrLiIoA wrote:

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

Actually, no. You'd really want at least K&R2 (i.e. Second Edition), but
getting C standard itself is even better. I don't have URLs to it right
now (you can get last public draft of C90 and current public draft of
C99 for free; searching this group for links may help).

Keith also pointed you to www.c-faq.com where you can find 20.4 as well.
For your convenience, here's the direct link to 20.4:

http://www.c-faq.com/misc/errno.html

Cheers

Vladimir
--
What I tell you three times is true.

[Keith Thompson]

RSoIsCaIrLiIoA <zz@zz.z> writes:
[...]

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

According to groups.google.com, the full FAQ list has not been posted
to comp.lang.c since Nov 1, 2004. An abridged FAQ list was posted on
Nov 1, 2005 and again on Feb 1, 2006; the abridged list doesn't
include question 20.4. The most recently posted full version doesn't
include question 20.4 either.

I've tended to ignore the posted FAQ, since the web version is so much
easier (for me) to access; perhaps that's why Steve hasn't been
posting it as regularly. It was also updated recently, and question
20.4 was part of the update.

Here's question 20.4 from the current web version:

Q: What's the right way to use errno?

A: In general, you should detect errors by checking return values,
and use errno only to distinguish among the various causes of an
error, such as ``File not found'' or ``Permission
denied''. (Typically, you use perror or strerror to print these
discriminating error messages.) It's only necessary to detect
errors with errno when a function does not have a unique,
unambiguous, out-of-band error return (i.e. because all of its
possible return values are valid; one example is atoi). In these
cases (and in these cases only; check the documentation to be sure
whether a function allows this), you can detect errors by setting
errno to 0, calling the function, then testing errno. (Setting
errno to 0 first is important, as no library function ever does
that for you.)

To make error messages useful, they should include all relevant
information. Besides the strerror text derived from errno, it may
also be appropriate to print the name of the program, the
operation which failed (preferably in terms which will be
meaningful to the user), the name of the file for which the
operation failed, and, if some input file (script or source file)
is being read, the name and current line number of that file.

See also question 12.24.

References: ISO Sec. 7.1.4, Sec. 7.9.10.4, Sec. 7.11.6.2
CT&P Sec. 5.4 p. 73
PCS Sec. 11 p. 168, Sec. 14 p. 254

My offer stands: if you're really unable to read the web version, I
can send you a copy. See my previous article for details. If you
have any kind of web access at all, it will be easier for you either
to access the web version directly, or to download another version
yourself from c-faq.com, but I don't know your situation.

I make this offer because I made it before, and I don't want to take
it back. However, you have recently been disrupting this newsgroup by
repeatedly posting huge chunks of assembly language, and you have
continued to do so after being asked to stop. You've engaged in
similar trollish behavior in the past. If you don't stop, this will
be my very last offer to help you. This offer expires permanently in
one week.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Steve Summit]

Keith Thompson wrote:

According to groups.google.com, the full FAQ list has not been posted
to comp.lang.c since Nov 1, 2004...
I've tended to ignore the posted FAQ, since the web version is so much
easier (for me) to access; perhaps that's why Steve hasn't been
posting it as regularly.

No, the script which posts the FAQ list is totally automated and
hasn't changed in so long that I have very little memory of how
it even works. The full FAQ list does indeed get posted every
month, but the fact that it's not showing up on google groups
suggests a propagation problem somewhere. Dang.

It would appear to be getting lost somewhere along the path
eskimo.com -> newsfeeds.com -> newshosting.com -> giganews.com ->
google.com. I'll write to the various postmasters along that
path and see if I can get any of them to look into it.

[Keith Thompson]

sc*@eskimo.com (Steve Summit) writes:

Keith Thompson wrote:

According to groups.google.com, the full FAQ list has not been posted
to comp.lang.c since Nov 1, 2004...
I've tended to ignore the posted FAQ, since the web version is so much
easier (for me) to access; perhaps that's why Steve hasn't been
posting it as regularly.

No, the script which posts the FAQ list is totally automated and
hasn't changed in so long that I have very little memory of how
it even works. The full FAQ list does indeed get posted every
month, but the fact that it's not showing up on google groups
suggests a propagation problem somewhere. Dang.

It would appear to be getting lost somewhere along the path
eskimo.com -> newsfeeds.com -> newshosting.com -> giganews.com ->
google.com. I'll write to the various postmasters along that
path and see if I can get any of them to look into it.

FWIW, news.ucsd.edu currently has two copies of the full FAQ, dated
2005-08-01 and 2005-10-01, and three copies of the abridged FAQ, dated
2005-08-15, 2005-09-15, and 2005-10-01. (It's not the news server I
usually use, but it has a much longer retention time.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[RSoIsCaIrLiIoA]

On Sun, 05 Feb 2006, Keith Thompson <ks***@mib.org> wrote:

RSoIsCaIrLiIoA <zz@zz.z> writes:
[...]

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

[...]
Here's question 20.4 from the current web version:

Q: What's the right way to use errno?

A: In general, you should detect errors by checking return values,
and use errno only to distinguish among the various causes of an
error, such as ``File not found'' or ``Permission
denied''. (Typically, you use perror or strerror to print these
discriminating error messages.) It's only necessary to detect
errors with errno when a function does not have a unique,
unambiguous, out-of-band error return (i.e. because all of its
possible return values are valid; one example is atoi). In these
cases (and in these cases only; check the documentation to be sure
whether a function allows this), you can detect errors by setting
errno to 0, calling the function, then testing errno. (Setting
errno to 0 first is important, as no library function ever does
that for you.)
so it seems i have right
To make error messages useful, they should include all relevant
information. Besides the strerror text derived from errno, it may
also be appropriate to print the name of the program, the
operation which failed (preferably in terms which will be
meaningful to the user), the name of the file for which the
operation failed, and, if some input file (script or source file)
is being read, the name and current line number of that file.

See also question 12.24.

References: ISO Sec. 7.1.4, Sec. 7.9.10.4, Sec. 7.11.6.2
CT&P Sec. 5.4 p. 73
PCS Sec. 11 p. 168, Sec. 14 p. 254

My offer stands: if you're really unable to read the web version,
i can read and copy a web version; anyway thank you
I
can send you a copy. See my previous article for details. If you
have any kind of web access at all, it will be easier for you either
to access the web version directly, or to download another version
yourself from c-faq.com, but I don't know your situation.

I make this offer because I made it before, and I don't want to take
it back. However, you have recently been disrupting this newsgroup by
repeatedly posting huge chunks of assembly language, and you have
continued to do so after being asked to stop.
if there is a little problem here, in this news-group, it could be the
OT questions that begin the treads; another problem could be that many
people give to NGs more importance than they really have.
i not think i'm a problem for this group because i generally don't
begin the treads nor i like to speak
You've engaged in
similar trollish behavior in the past. If you don't stop, this will
be my very last offer to help you. This offer expires permanently in
one week.

here i can be me
i'm in this way: this is what i'am. you can accept or not

[Mark McIntyre]

On Mon, 06 Feb 2006 08:59:14 +0100, in comp.lang.c , RSoIsCaIrLiIoA
<zz@zz.z> wrote:

On Sun, 05 Feb 2006, Keith Thompson <ks***@mib.org> wrote:

RSoIsCaIrLiIoA <zz@zz.z> writes:
[...]

However, you have recently been disrupting this newsgroup by

repeatedly posting huge chunks of assembly language, and you have
continued to do so after being asked to stop.

i not think i'm a problem for this group because i generally don't
begin the treads nor i like to speak

I don't follow this logic. You didn't start the thread - fine - but
that doesn't mean you can now post offtopic and irrelevant responses.

You've engaged in
similar trollish behavior in the past. If you don't stop, this will
be my very last offer to help you. This offer expires permanently in
one week.

i'm in this way: this is what i'am. you can accept or not

If what you are is a troll, then we accept that, killfile you and move
on.

If on the other hand you want useful help, you will need to fit in
with the group. You have six days.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On Mon, 06 Feb 2006 08:59:14 +0100, in comp.lang.c , RSoIsCaIrLiIoA
<zz@zz.z> wrote:

On Sun, 05 Feb 2006, Keith Thompson <ks***@mib.org> wrote: [snip]

You've engaged in
similar trollish behavior in the past. If you don't stop, this will
be my very last offer to help you. This offer expires permanently in
one week.

i'm in this way: this is what i'am. you can accept or not

If what you are is a troll, then we accept that, killfile you and move
on.

If on the other hand you want useful help, you will need to fit in
with the group. You have six days.

To be clear, the one-week expiration referred *only* to my offer to
send RSoIsCaIrLiIoA a copy of the FAQ by e-mail. RSoIsCaIrLiIoA
replied: "i can read and copy a web version; anyway thank you", so
that's no longer relevant. At this point, there is no deadline as far
as I'm concerned. I intend to treat RSoIsCaIrLiIoA as a troll (i.e.,
ignore him/her except as necessary to correct any misinformation)
starting immediately; others will do as they see fit.

I see no point in continuing this discussion, but don't let that stop
you if you have something to add.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Default User]

Keith Thompson wrote:

I intend to treat RSoIsCaIrLiIoA as a troll (i.e.,
ignore him/her except as necessary to correct any misinformation)
starting immediately; others will do as they see fit.

I see no point in continuing this discussion, but don't let that stop
you if you have something to add.

I'm not even sure why this is a matter for discussion. This isn't the
first time he's trolled the group, I plonked him long ago.

Brian

[Mark McIntyre]

On Mon, 06 Feb 2006 23:31:27 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

If on the other hand you want useful help, you will need to fit in
with the group. You have six days.

To be clear, the one-week expiration referred *only* to my offer to
send RSoIsCaIrLiIoA a copy of the FAQ by e-mail.

My misunderstanding. Apologies.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 7 Feb 2006 00:37:30 GMT, in comp.lang.c , "Default User"
<de***********@yahoo.com> wrote:

Keith Thompson wrote:

I intend to treat RSoIsCaIrLiIoA as a troll (i.e.,
ignore him/her except as necessary to correct any misinformation)
starting immediately; others will do as they see fit.

I see no point in continuing this discussion, but don't let that stop
you if you have something to add.

I'm not even sure why this is a matter for discussion. This isn't the
first time he's trolled the group, I plonked him long ago.

Same here, though he escaped by changing ISP I think. I was giving him
the benefit of the doubt, I'm not sure I'll bother much longer.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----