Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Fopen to create a file in a sub-folder (such as "Mygoal").

Reply
Thread Tools

Fopen to create a file in a sub-folder (such as "Mygoal").

 
 
user923005
Guest
Posts: n/a
 
      01-29-2008
On Jan 29, 1:32*pm, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <(E-Mail Removed)>,
>
> user923005 *<(E-Mail Removed)> wrote:
> >Sure, people do stupid things that follow the standard exactly all the
> >time.
> >For instance, I know of one compiler vendor who coded to exactly the
> >standard limits.
> >(e.g. nest levels, line lengths, etc.).
> >Now, it was no difficulty whatsoever to allow longer lines and deeper
> >limits.
> >But because the standard says it must be _at least_ x, all values were
> >set to x.

>
> Could be a useful compiler for testing conformance with the
> minimums permitted by the standard. Not necessarily a design flaw
> at all.


It's only a problem when the minimuns are inadequate. In such a case,
it is truly a design flaw, because the design (aka the C Standard) did
not state an adequate miniumum. This can really be a problem, because
the C Standard is designed so that a C compiler can be written for
some itty-bitty microcontroller. The minimums for something like that
do not make sense on a 500 million dollar mainframe.
 
Reply With Quote
 
 
 
 
Kenneth Brody
Guest
Posts: n/a
 
      01-29-2008
user923005 wrote:
[...]
> There are not any compilers that I know of that do not set the errno
> value on fopen() failure.
> But the fact that you are allowed to leave errno unchanged is clearly
> a gaffe.


The fact that neither you nor I know of any systems which do not
set errno does not mean that there aren't any. I can imagine a
"security" system which would prohibit access to some files, but
for security reasons, refuse to tell you why. (ie: there is no
way to distinguish between "the file doesn't exist" and "the file
does exist, but you didn't give the correct encryption key".)

However, if I were on the committee, I would have suggested making
something like a generic EUNKNOWN error code, which could be used
on systems where a failure could occur, but for which the C runtime
could not determine the "true" cause. (Perhaps the O/S simply
returns a "failed" condition?) At least, you could then trust that
errno was set, even if you can't guarantee that it was set to a
"known" error code. For all I know, the suggestion was made, but
reject for some reason.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>

 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      01-29-2008
On Jan 29, 1:52*pm, Kenneth Brody <(E-Mail Removed)> wrote:
> user923005 wrote:
>
> [...]
>
> > There are not any compilers that I know of that do not set the errno
> > value on fopen() failure.
> > But the fact that you are allowed to leave errno unchanged is clearly
> > a gaffe.

>
> The fact that neither you nor I know of any systems which do not
> set errno does not mean that there aren't any. *I can imagine a
> "security" system which would prohibit access to some files, but
> for security reasons, refuse to tell you why. *(ie: there is no
> way to distinguish between "the file doesn't exist" and "the file
> does exist, but you didn't give the correct encryption key".)


I'm sorry, but EACCES is the logical return here, and not telling me
why serves no purpose.

> However, if I were on the committee, I would have suggested making
> something like a generic EUNKNOWN error code, which could be used
> on systems where a failure could occur, but for which the C runtime
> could not determine the "true" cause. *(Perhaps the O/S simply
> returns a "failed" condition?) *At least, you could then trust that
> errno was set, even if you can't guarantee that it was set to a
> "known" error code. *For all I know, the suggestion was made, but
> reject for some reason.


I'm not buying it. It was a lazy and stupid decision.
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      01-29-2008
user923005 wrote:
> Can you please describe for me a scenario where opening a file fails
> and it is not possible to diagnose why?


Depends what you mean by "why". There may be an underlying 'why' which
was not determinable by the requester.

Consider that in some circumstances, knowing that a file exists is
useful information for a hacker. Your OS might therefore refuse to
confirm both the existence and nonexistence of the file.

Sorta like asking MI5 the name of their operative in New york. Their
answer might well be "we neither confirm nor deny that we even have
operatives"

> This is a lazy result for the standards committee. Quite frankly,
> it's a black eye on the C language.


Not so sure. Unless you restrict the errono value to "success" and
"failure" ther are too many reasons for failure to usefully codify.

E-NOTFOUND
E-ACCESS-DENIED
E-DISK-REMOVED
E-FILE-DELETED-BY-OTHER-PROCESS
E-FILE-LOCKED-BY-OTHER-USER
E-FILE-LOCKED-BY-YOU-ALREADY
E-TAPE-MISSING
E-TAPE-NEEDS-REWOUND
E-ITS-MONDAY
.....


--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-29-2008
In article <(E-Mail Removed)>,
Kaz Kylheku <(E-Mail Removed)> wrote:

>> This is a lazy result for the standards committee. *Quite frankly,
>> it's a black eye on the C language.

>
>Can you describe a situation in which a C implementor would duck out
>of setting errno in fopen, just because the standard allows it?
>
>An implementation can conform, yet demonstrate poor quality in a
>myriad other ways than this.
>
>For instance, suppose that your compiler only emits the message ``this
>translation unit requires a diagnostic''. No filename, no line number,
>no information.


And yet the standard *does* require a diagnostic, even if it's a
useless one. Why doesn't it do the same for fopen(), requiring
errno to be set, even if to a useless value?

>You know you can test whether or not fopen set errno. Assign zero to
>errno before calling fopen. If fopen fails, and errno is found to be
>nonzero, then take advantage of the value.


And what's the advantage of requiring the user to do this test?

-- Richard
--
:wq
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      01-29-2008
user923005 wrote:
> Jack Klein <(E-Mail Removed)> wrote:
>

.... snip ...
>>
>> Why lookup errno? fopen() is not required to set it.

>
> Too bad. It works on all the platforms that I care about (POSIX,
> Windows, OpenVMS, MVS), but it is still tragic that a place where
> it would obviously be helpful is left in the cold. I would be
> curious as to why such an obviously helpful diagnostic was deemed
> unnecessary. I mean, even if I am opening a port in a toaster IC,
> I would not see any reason why a hint as to what went wrong would
> not be in order.


Reminds me of the elegant Microsoft error returns from their
interface software. A routine with about umpty-ump parameters
always returned a code (which had to be laboriously looked up)
which translated to "parameter error". It didn't even identify the
parameter. Untangling that took about two days.

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      01-29-2008
user923005 wrote:
> Kaz Kylheku <(E-Mail Removed)> wrote:
>

.... snip ...
>>
>> You know you can test whether or not fopen set errno. Assign zero
>> to errno before calling fopen. If fopen fails, and errno is found
>> to be nonzero, then take advantage of the value.

>
> There are not any compilers that I know of that do not set the
> errno value on fopen() failure. But the fact that you are allowed
> to leave errno unchanged is clearly a gaffe.


Not so. For example, it allows a very tight system to be generated
that will fit into a chip/memory combination. If testing/debugging
that lack may be a nuisance, but it is not a gaffe.

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      01-30-2008
user923005 wrote:

> On Jan 29, 12:28*am, santosh <(E-Mail Removed)> wrote:
>> user923005 wrote:
>> > On Jan 28, 7:35*pm, Jack Klein <(E-Mail Removed)> wrote:

>>
>> <snip>
>>
>> >> Why lookup errno? *fopen() is not required to set it.

>>
>> > Too bad. *It works on all the platforms that I care about (POSIX,
>> > Windows, OpenVMS, MVS), but it is still tragic that a place where
>> > it would obviously be helpful is left in the cold. *I would be
>> > curious as to why such an obviously helpful diagnostic was deemed
>> > unnecessary. *I mean, even if I am opening a port in a toaster IC,
>> > I would not see any reason why a hint as to what went wrong would
>> > not be in order.

>>
>> That's exactly the current situation isn't it? In practise errno is
>> set to something meaningful if the system can do so, but since not
>> all systems may have that capability the Standard declined from
>> mandating that errno shall be set by fopen() after a failure.

>
> Can you please describe for me a scenario where opening a file fails
> and it is not possible to diagnose why?


Personally no. The best I can think of is that some primitive or
otherwised brain-damaged systems failed to provide a proper diagnostic
for some file open failures to fopen(), which means that fopen() could
not sensibly set errno for all instances of failure.

As Chris Hills put it, C goes out of it's way to accommodate itself to
the hardware unlike some other languages. If some systems somewhere
were damaged in this way I suppose the Committee would have preffered
to have fopen() adapt for them than insist that it return sensible
error messages and force the system software manufacturers to put out
patches.

> This is a lazy result for the standards committee. Quite frankly,
> it's a black eye on the C language.


 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      01-30-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Tobin) wrote:

> Kaz Kylheku <(E-Mail Removed)> wrote:
>
> >Can you describe a situation in which a C implementor would duck out
> >of setting errno in fopen, just because the standard allows it?


> >For instance, suppose that your compiler only emits the message ``this
> >translation unit requires a diagnostic''. No filename, no line number,
> >no information.

>
> And yet the standard *does* require a diagnostic, even if it's a
> useless one. Why doesn't it do the same for fopen(), requiring
> errno to be set, even if to a useless value?


Because it adds nothing of importance to that fopen() call. If all you
want to know is _whether_ the call succeeded, and you either don't care
or aren't allowed to know _why_, you don't need errno, you can just
check whether fopen() returned a null pointer.
Granted, this ignores the scenario where you string several function
calls together, one of which is an fopen(), and you want to check
afterwards if any of them set errno. That is a reason to make fopen()
set errno, but I posit that, in the case of fopen(), it is not as likely
a scenario as in the case of, e.g., a string of floating point
computations.

Richard
 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      01-30-2008
CBFalconer wrote:
[...]
> Reminds me of the elegant Microsoft error returns from their
> interface software. A routine with about umpty-ump parameters
> always returned a code (which had to be laboriously looked up)
> which translated to "parameter error". It didn't even identify the
> parameter. Untangling that took about two days.


And let's not forget the XP SP2 upgrade, which has a tendency to
give, 25 minutes into the install, the message "Access Denied", and
then spend another 25 minutes undoing what it had done up to that
point. (Yes, that's the entire text of the error message.)

However, your example does relate back to the original "why doesn't
the Standard require fopen() to set errno" question. If the
Standard were to require errno to be set, wouldn't it also need to
define all of the possible error values? Would it make sense for
the Standard to say "errno must be set to an implementation-defined
value"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
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
fopen() with full path affecting subsequent fopen calls Michel Rouzic C Programming 4 04-28-2008 04:48 PM
What is up with fopen??? FOpen and local directories Nonee HTML 2 10-25-2005 09:18 PM
Re: why fopen( ) can't open a big data file? (single file, as big as 29G) dominiconnor@gmail.com C++ 2 06-21-2005 06:24 PM
How to create folder at fopen? Jens.Toerring@physik.fu-berlin.de C Programming 15 09-03-2004 05:02 PM
Usoing fopen etc is there a way to find file size Angus Comber C Programming 6 02-10-2004 01:41 AM



Advertisments