conforming implementation?

[vippstar@gmail.com]

If the concept of file streams is not possible to be implemented, can
all FILE related functions be "disabled"?
For example:

size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE
*stream) {
errno = something;
return 0;
}

Perhaps to generalize the question: When the behavior (or return
value) of a function is unspecified by the standard, can an
implementation always choose one behavior?

All replies appreciated.

[pete]

Re: conforming implementation?

vippstar@gmail. com wrote:

When the behavior (or return value)
of a function is unspecified by the standard,
can an implementation always choose one behavior?

It's allowed.

void *malloc(size_t size)
{
return NULL;
}

--
pete

[Jack Klein]

Re: conforming implementation?

On Sun, 18 May 2008 02:21:05 -0700 (PDT), vippstar@gmail. com wrote in
comp.lang.c:

If the concept of file streams is not possible to be implemented, can
all FILE related functions be "disabled"?

Define a situation where it is "not possible" to implement these
streams.

For example:
>
size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE
*stream) {
errno = something;
return 0;
}
>
Perhaps to generalize the question: When the behavior (or return
value) of a function is unspecified by the standard, can an
implementation always choose one behavior?
>
All replies appreciated.

There are two types of possible conforming implementations , hosted and
free standing. A hosted environment must begin execution of a
program with three FILE streams already open, which can be referred to
by the macros stdin, stdout, and stderr. All the appropriate FILE
functions must be available on these streams.

A free standing environment, on the other hand, is not even required
to provide <stdio.hor file streams at all.

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

[Keith Thompson]

Re: conforming implementation?

Jack Klein <jackklein@spam cop.netwrites:
[...]

There are two types of possible conforming implementations , hosted and
free standing. A hosted environment must begin execution of a
program with three FILE streams already open, which can be referred to
by the macros stdin, stdout, and stderr. All the appropriate FILE
functions must be available on these streams.

Yes, but those functions aren't necessarily required to succeed. For
example (using Unix shell syntax), given:

./my_program < /dev/null \

/this_disk_is_fu ll/out \

2/this_disk_is_fu ll/err

any attempt to read from stdin or write to stdout or stderr will fail.
I'm not convinced that a hosted implementation in which stdin, stdout,
and stderr are *always* unusable would be non-conforming.

The standard is written to allow for conforming implementations on a
wide variety of systems. One consequence of this is that it doesn't
require a conforming implementation to be *useful* (how could it?).

A free standing environment, on the other hand, is not even required
to provide <stdio.hor file streams at all.

Right.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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"

[Peter Nilsson]

Re: conforming implementation?

Keith Thompson wrote:

Jack Klein <jackklein@spam cop.netwrites:
[...]

There are two types of possible conforming implementations ,
hosted and free standing. A hosted environment must begin
execution of a program with three FILE streams already open,
which can be referred to by the macros stdin, stdout, and
stderr. All the appropriate FILE functions must be
available on these streams.

>
Yes, but those functions aren't necessarily required to
succeed. For example (using Unix shell syntax), given:
>
./my_program < /dev/null \

/this_disk_is_fu ll/out \

2/this_disk_is_fu ll/err
>
any attempt to read from stdin or write to stdout or stderr
will fail. I'm not convinced that a hosted implementation in
which stdin, stdout, and stderr are *always* unusable would
be non-conforming.

I would argue that the user who typed the command has
chosen to run the program on a non-conforming implementation.

--
Peter

[robertwessel2@yahoo.com]

Re: conforming implementation?

On May 18, 4:21 am, vipps...@gmail. com wrote:

If the concept of file streams is not possible to be implemented, can
all FILE related functions be "disabled"?

I suspect it would be confirming, although not all that useful, if a
hosted implementation failed all fopens, immediately returned EOF for
stdin, and bit-bucketed any writes to stdout and strerr.

[Keith Thompson]

Re: conforming implementation?

Peter Nilsson <airia@acay.com .auwrites:

Keith Thompson wrote:

>Jack Klein <jackklein@spam cop.netwrites:
>[...]

There are two types of possible conforming implementations ,
hosted and free standing. A hosted environment must begin
execution of a program with three FILE streams already open,
which can be referred to by the macros stdin, stdout, and
stderr. All the appropriate FILE functions must be
available on these streams.

>>
>Yes, but those functions aren't necessarily required to
>succeed. For example (using Unix shell syntax), given:
>>
> ./my_program < /dev/null \

> /this_disk_is_fu ll/out \

> 2/this_disk_is_fu ll/err
>>
>any attempt to read from stdin or write to stdout or stderr
>will fail. I'm not convinced that a hosted implementation in
>which stdin, stdout, and stderr are *always* unusable would
>be non-conforming.

>
I would argue that the user who typed the command has
chosen to run the program on a non-conforming implementation.

An interesting thought, but I disagree. After all, the various I/O
functions are designed to detect errors for a reason.

If I write to stdout and the disk fills up after I've written a
gigabyte of data, and the implementation correctly tells me about the
error, that's not non-conforming. Same thing if it fills up after I
write a megabyte of data. Or a kilobyte. Or none.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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"

[Pietro Cerutti]

Re: conforming implementation?

Keith Thompson wrote:

Jack Klein <jackklein@spam cop.netwrites:
[...]

>There are two types of possible conforming implementations , hosted and
>free standing. A hosted environment must begin execution of a
>program with three FILE streams already open, which can be referred to
>by the macros stdin, stdout, and stderr. All the appropriate FILE
>functions must be available on these streams.

>
Yes, but those functions aren't necessarily required to succeed. For
example (using Unix shell syntax), given:
>
./my_program < /dev/null \

/this_disk_is_fu ll/out \

2/this_disk_is_fu ll/err
>
any attempt to read from stdin or write to stdout or stderr will fail.
I'm not convinced that a hosted implementation in which stdin, stdout,
and stderr are *always* unusable would be non-conforming.

I don't agree. A read from /dev/null doesn't /*fail*/, but rather
returns EOF:

cat readnull.c

#include <stdio.h>

int main(void)
{
char buf[80];

if(!fgets(buf, sizeof(buf), stdin)){
if(feof(stdin))
printf("EOF\n") ;
else if(ferror(stdin ))
printf("ERROR\n ");
else
printf("?\n");

}

return (0);
}

./readnull < /dev/null

EOF

--
Pietro Cerutti

[Keith Thompson]

Re: conforming implementation?

Pietro Cerutti <gahr@gahr.chwr ites:

Keith Thompson wrote:

>Jack Klein <jackklein@spam cop.netwrites:
>[...]

>>There are two types of possible conforming implementations , hosted and
>>free standing. A hosted environment must begin execution of a
>>program with three FILE streams already open, which can be referred to
>>by the macros stdin, stdout, and stderr. All the appropriate FILE
>>functions must be available on these streams.

>Yes, but those functions aren't necessarily required to succeed. For
>example (using Unix shell syntax), given:
> ./my_program < /dev/null \

> /this_disk_is_fu ll/out \

> 2/this_disk_is_fu ll/err
>any attempt to read from stdin or write to stdout or stderr will
>fail.
>I'm not convinced that a hosted implementation in which stdin, stdout,
>and stderr are *always* unusable would be non-conforming.

>
I don't agree. A read from /dev/null doesn't /*fail*/, but rather
returns EOF:

[snip]

Good point.

It's difficult to construct a good example of what I'm trying to do,
since if the file is unreadable the error will generally be caught by
the shell before the program is invoked. (Again, I'm using a
Unix-specific example to illustrate a more general point.)

Replace /dev/null with some file or device that can be opened for
reading but on which any read attempts will actually fail and set the
error flag for the stream. I'm still not convinced that this would be
non-conforming. To demonstrate that it *is* non-conforming, you'd
have to find wording in the standard that says it must be possible to
read from stdin without error. It may be ambiguous, but I don't think
there's a clear statement to that effect.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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"

[Pietro Cerutti]

Re: conforming implementation?

Keith Thompson wrote:

Pietro Cerutti <gahr@gahr.chwr ites:

>Keith Thompson wrote:

>>Jack Klein <jackklein@spam cop.netwrites:
>>[...]
>>>There are two types of possible conforming implementations , hosted and
>>>free standing. A hosted environment must begin execution of a
>>>program with three FILE streams already open, which can be referred to
>>>by the macros stdin, stdout, and stderr. All the appropriate FILE
>>>functions must be available on these streams.
>>Yes, but those functions aren't necessarily required to succeed. For
>>example (using Unix shell syntax), given:
>> ./my_program < /dev/null \
>> /this_disk_is_fu ll/out \
>> 2/this_disk_is_fu ll/err
>>any attempt to read from stdin or write to stdout or stderr will
>>fail.
>>I'm not convinced that a hosted implementation in which stdin, stdout,
>>and stderr are *always* unusable would be non-conforming.

>I don't agree. A read from /dev/null doesn't /*fail*/, but rather
>returns EOF:

[snip]
>
Good point.
>
It's difficult to construct a good example of what I'm trying to do,
since if the file is unreadable the error will generally be caught by
the shell before the program is invoked. (Again, I'm using a
Unix-specific example to illustrate a more general point.)
>
Replace /dev/null with some file or device that can be opened for
reading but on which any read attempts will actually fail and set the
error flag for the stream. I'm still not convinced that this would be
non-conforming. To demonstrate that it *is* non-conforming, you'd
have to find wording in the standard that says it must be possible to
read from stdin without error. It may be ambiguous, but I don't think
there's a clear statement to that effect.

The standard doesn't say much about std[in|out|err]...
Thus, I would argue that the lake of explicit requisites on these three
FILE*s guarantees an implementation not providing successful I/O to be
still conforming.

--
Pietro Cerutti