469,366 Members | 2,236 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,366 developers. It's quick & easy.

Qry : Behaviour of fgets -- ?


Machine 1 :
bash-3.00$ uname -a
SunOS <hostname5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-280R

bash-3.00$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/
specs
gcc version 2.95.3 20010315 (release)
Machine 2:
bash-2.05b$ uname -a
Linux <hostname2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686
i386 GNU/Linux

bash-2.05b$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-
redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

bash-2.05b$ cat fgets_fail_test.c
#include<stdio.h>
#include <string.h>
#include<stdlib.h>

/* Demo fgets failed by Raxit Sheth & Gaurav Gupta */

int main()
{
char spcontent[100],sendrepfile[100];
FILE *spfp=NULL;
memset(sendrepfile,0,100);
strcpy(sendrepfile,"/tmp/filenotexists");
if ((spfp = fopen(sendrepfile, "r")) == (FILE *)NULL)
{
printf("error in opening file %s",sendrepfile);fflush(stdout);
}
memset(spcontent, 0, sizeof(spcontent));

while (fgets(spcontent,40, spfp)!=NULL)
{
printf("The value of spcontent is
[%s]",spcontent);fflush(stdout);;
}
return 0;
}
<simillar core dump occurs on both the system>
bash-2.05b$ gcc -Wall fgets_fail_test.c -o test
bash-2.05b$ ./test
error in opening file /tmp/filenotexistsSegmentation fault (core
dumped)
bash-2.05b$ gdb ./test ./core.27887
GNU gdb Red Hat Linux (5.3.90-0.20030710.40rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging
symbols found)...Using host libthread_db library "/lib/tls/
libthread_db.so.1".

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
(gdb) where
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
#1 0x0804854b in main ()
(gdb) frame 0
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
(gdb) print errno
Cannot access memory at address 0xb74a7008
char *fgets(char *s, int n, FILE *stream)
Qry : What is the Behaviour if stream is NULL. ?

As per our understanding fgets should return NULL < and internally
gets should put check on stream, if it is not NULL then only should do
additional access of stream.

please ignore if it is known and would be great if you can point out
in the implementation detail.
--Gaurav Gupta & Raxit Sheth
http://www.barcamp.org/BarCampMumbaiOct2007 <----BarCampMumbaiOct2007

Sep 6 '07
285 7860
Bart van Ingen Schenau wrote:
Please not that the DS9K does not always obey the laws of physics,
Either the DS9K obeys the laws of physics, or you don't have a DS9K. Choose
one.
Sep 10 '07 #101
"Douglas A. Gwyn" wrote:
"Army1987" <ar******@NOSPAM.itwrote...
>Douglas A. Gwyn wrote:
>>#include <stdio.h// just for FILE
extern char *myfgets(char *, int, FILE *);
#undef fgets // in case <stdio.hdefined it
#define fgets myfgets

You're not allowed to do that.

Not allowed by whom? The program may not be strictly conforming,
but it should still work. If you want to get really fussy about
it, make "mystdio.h" define FILE without including <stdio.h>
(which requires some implementation-dependent kludgery); then the
fgets-redefining macro is "allowed".
Not allowed by the C standard. Just because it will work on _some_
systems doesn't make it viable. Undefined behaviour includes doing
what you think is right.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Sep 10 '07 #102
Charlie Gordon wrote:
"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
>Here's the declaration of fgets:

char *fgets(char * restrict s, int n, FILE * restrict stream);

This has probably been discussed before, but I couldn't find a
relevant reference. Why do we have restrict keywords on s and
stream in this function prototype? They seem to convey no useful
information here. Can anyone explain ?
They certainly do convey useful information. They advise the
compiler of the fgets software that using *stream will not affect
*s, and vice-versa. This enables more extensive optimization, and
thus faster code.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Sep 10 '07 #103
Harald van D?k said:
Bart van Ingen Schenau wrote:
>Please not that the DS9K does not always obey the laws of physics,

Either the DS9K obeys the laws of physics, or you don't have a DS9K.
Choose one.
There ain't no such animal as "the laws of physics". They are myths,
make-believe, mere models made by mankind to satisfy his need for
labelling things. Reality does not have "obeys all laws of physics as
discovered (so far) by Sol III's scientists" written on the box lid.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 10 '07 #104
Richard Heathfield wrote:
kuyper said:
....
I'm not sure I follow the "misplaced zeal' comment. Do you really want
the standard to say that fgets() must behave as described, even if s
happens to alias stream? The purpose for which 'restrict' was invented
was to convey the fact that such situations are to be avoided.

I'm just trying to imagine what kind of bozo would alias a data buffer
with a stream pointer.

Um, yeah, okay, maybe it's not so hard to imagine. Sturgeon and all
that. I retract the "misplaced".
I agree that Sturgeon's law is the most reason why such code might be
written; and I believe that alone is sufficient reason to apply the
qualifiers.

However, Sturgeon's law is not the only way this issue could come up..
I can easily imagine legitimate, though non--portable, reasons why
someone might do something like that. If they understood the
implementation-specific details about how a FILE structure is layed
out and used by the implementation, I could imagine wanting to save
that information to a strean (which might be the same stream) for
later examination. By that same token, of course, if they understood
enough to want to do that, they should also understand enough to know
why it's unsafe to do it that way; the best that can be done is to
save a copy of the FILE structure, rather than the one in actual use.
Therefore, Sturgeon's Law remains the most likely cause of such code.

Sep 10 '07 #105
Richard Heathfield wrote:
Harald van D?k said:
>Bart van Ingen Schenau wrote:
>>Please not that the DS9K does not always obey the laws of physics,

Either the DS9K obeys the laws of physics, or you don't have a DS9K.
Choose one.

There ain't no such animal as "the laws of physics". They are myths,
make-believe, mere models made by mankind to satisfy his need for
labelling things. Reality does not have "obeys all laws of physics as
discovered (so far) by Sol III's scientists" written on the box lid.
I didn't say "the laws of physics as discovered (so far)", I copied Bart van
Ingen Schenau's unqualified "the laws of physics", which do exist even if
we don't fully know them yet. And regardless of whether you want to make
that distinction, I doubt you honestly believe anyone's neighbour turned
into a piano. Some more context:

"The standard does indeed not require that UB causes my next door
neighbour to turn into a piano, but that appears to be exactly the
behaviour of my DeathStation 9000.
Are you claiming that this behaviour is not correct?" - Bart v Ingen Schenau
Sep 10 '07 #106
CBFalconer wrote:
"Douglas A. Gwyn" wrote:
Not allowed by whom? The program may not be strictly conforming,
but it should still work. If you want to get really fussy about
it, make "mystdio.h" define FILE without including <stdio.h>
(which requires some implementation-dependent kludgery); then the
fgets-redefining macro is "allowed".
Not allowed by the C standard. Just because it will work on _some_
systems doesn't make it viable. Undefined behaviour includes doing
what you think is right.
It will in fact work on any actual platform. If that isn't
good enough for the fellow, then what would be?
Sep 10 '07 #107
Douglas A. Gwyn wrote:
CBFalconer wrote:
>"Douglas A. Gwyn" wrote:
Not allowed by whom? The program may not be strictly conforming,
but it should still work. If you want to get really fussy about
it, make "mystdio.h" define FILE without including <stdio.h>
(which requires some implementation-dependent kludgery); then the
fgets-redefining macro is "allowed".
Not allowed by the C standard. Just because it will work on _some_
systems doesn't make it viable. Undefined behaviour includes doing
what you think is right.

It will in fact work on any actual platform. If that isn't
good enough for the fellow, then what would be?
That's a bold claim. With fgets, it would work on my implementation. With
strlen for example, it would not, because <string.h>'s macro definition of
strcpy refers to it by name. Are you sure no implementation does anything
similar with fgets?
Sep 10 '07 #108
"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
Charlie Gordon wrote:
>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
>>Here's the declaration of fgets:

char *fgets(char * restrict s, int n, FILE * restrict stream);

This has probably been discussed before, but I couldn't find a
relevant reference. Why do we have restrict keywords on s and
stream in this function prototype? They seem to convey no useful
information here. Can anyone explain ?

They certainly do convey useful information. They advise the
compiler of the fgets software that using *stream will not affect
*s, and vice-versa. This enables more extensive optimization, and
thus faster code.
No. In a function *definition*, they do what you said. When an implementor
writes their C library in C, adding restrict qualifiers to the function
definitions might indeed enable some optimizations.

In a function *declaration*, these qualifiers are meaningless to the
compiler. Since adding or removing qualifiers to the type of a parameter
doesn't affect the compatibility of function types, the presence or absence
of the qualifiers in a function *declaration* does not affect the
assumptions that the compiler is allowed to make about the definition.

Sep 10 '07 #109
On Mon, 10 Sep 2007 19:12:44 GMT, in comp.lang.c , "Douglas A. Gwyn"
<DA****@null.netwrote:
>Not allowed by the C standard. Just because it will work on _some_
systems doesn't make it viable. Undefined behaviour includes doing
what you think is right.

It will in fact work on any actual platform.
I'd be interested to see proof that it works on "any actual platform"
- presumably including platforms no longer manufactured. Do we get to
include platforms still being built, and yet to be invented?
If that isn't good enough for the fellow, then what would be?
Personally I prefer not to rely on purely empirical evidence. After
all if we did that, we'd still be sticking straws into pingpong balls
and calling it a model of a solid, quantum computers would be
impossible and Schroedinger's cat would be well and truly dead.

--
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
Sep 10 '07 #110
Harald van D?k wrote:
Douglas A. Gwyn wrote:
CBFalconer wrote:
"Douglas A. Gwyn" wrote:
Not allowed by whom? The program may not be strictly conforming,
but it should still work. If you want to get really fussy about
it, make "mystdio.h" define FILE without including <stdio.h>
(which requires some implementation-dependent kludgery); then the
fgets-redefining macro is "allowed".
Not allowed by the C standard. Just because it will work on _some_
systems doesn't make it viable. Undefined behaviour includes doing
what you think is right.
It will in fact work on any actual platform. If that isn't
good enough for the fellow, then what would be?
That's a bold claim. With fgets, it would work on my implementation. With
strlen for example, it would not, because <string.h>'s macro definition of
strcpy refers to it by name. Are you sure no implementation does anything
similar with fgets?
I think you missed the fact that <stdio.his *not* #included in
the context in which the "fgets" layering macro is defined and used.
<mystdio.his #included, as a *replacement* for i#ncluding <stdio.h>,
but it does not itself #include <stdio.h>, and no other header used
by the application should #include <stdio.heither. (The other
standard headers won't, and they also won't define fgets.) The
identifier "fgets" is therefore reserved only if used to refer to
external linkage, which it doesn't (being a macro).

This kind of "layering" of standard functions is fairly common,
especially for adding debugging checks like the original requestor
wanted.
Sep 11 '07 #111
Mark McIntyre wrote:
I'd be interested to see proof that it works on "any actual platform"
- presumably including platforms no longer manufactured. Do we get to
include platforms still being built, and yet to be invented?
Well, they have to be standard conforming.
Sep 11 '07 #112
Wojtek Lerch wrote:
In a function *declaration*, these qualifiers are meaningless to the
compiler. Since adding or removing qualifiers to the type of a parameter
doesn't affect the compatibility of function types, the presence or absence
of the qualifiers in a function *declaration* does not affect the
assumptions that the compiler is allowed to make about the definition.
However, it certainly affects the assumptions that the programmer
should make.
Sep 11 '07 #113
Richard Bos wrote:
Rainer Weikusat <rw*******@mssgmbh.comwrote:
>Keith Thompson <ks***@mib.orgwrites:
>>We don't claim (except jokingly) that executing those statements
*will* cause demons to fly out of your nose. The claim is merely
that nasal demons are one of the infinitely many behaviors
permitted by the standard.

It is one of the infinitely many things humans make up because
something like an inbred horror vacui compels them to fill any
void with something. But any example of "behaviour" is
necessarily defined and not undefined.

You have obviously never read much about quantum physics. And yes,
when the Standard does not define what a piece of code does but
leaves it up to the compiler, and when that compiler does not care
to make sure that that code does something specific but leaves it
up to the accidents of microprocessor behaviour (which both could
very well do, and with good reason), then quantum physics really
can toss the coin about how that code behaves, on that day, on
that computer.
My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Sep 11 '07 #114
Rainer Weikusat wrote:
Kenneth Brody <ke******@spamcop.netwrites:
>>
.... snip ...
>>
You've never run on a CPU which can perform more than one
instruction at a time, have you?

Would you please stop bombarding me with this trash? I am not
trying to argue for the standpoint you would like to impose onto
me and if you haven't understood that by now, the chances that
you ever will are slim.
All he is doing is helpfully trying to point out some of the
possibilities of invoking undefined behaviour. He isn't imposing
anything on you. I suggest waking up and recognizing reality.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Sep 11 '07 #115
"Douglas A. Gwyn" <DA****@null.netwrote in message
news:46***************@null.net...
Wojtek Lerch wrote:
>In a function *declaration*, these qualifiers are meaningless to the
compiler. Since adding or removing qualifiers to the type of a parameter
doesn't affect the compatibility of function types, the presence or
absence
of the qualifiers in a function *declaration* does not affect the
assumptions that the compiler is allowed to make about the definition.

However, it certainly affects the assumptions that the programmer
should make.
That would be clearer if the normative text actually said that the Synopsis
of each library function is meant to specify the exact type the function
must be defined with, rather than just be a declaration suitable for copying
into a program or a standard header.

Or was it meant to be something in between? I don't see why the standard
would want to forbid implementors to define putchar() as

int putchar( int const ch ) {
return putc( ch, stdout );
}
Sep 11 '07 #116
Harald van D?k said:
Richard Heathfield wrote:
>Harald van D?k said:
>>Bart van Ingen Schenau wrote:
Please not that the DS9K does not always obey the laws of physics,

Either the DS9K obeys the laws of physics, or you don't have a DS9K.
Choose one.

There ain't no such animal as "the laws of physics". They are myths,
make-believe, mere models made by mankind to satisfy his need for
labelling things. Reality does not have "obeys all laws of physics as
discovered (so far) by Sol III's scientists" written on the box lid.

I didn't say "the laws of physics as discovered (so far)", I copied
Bart van Ingen Schenau's unqualified "the laws of physics", which do
exist even if we don't fully know them yet.
No, they don't. Nature has no laws. Nature has behaviour. We observe
that behaviour, and formulate "laws" which explain it. Nature, however,
is under no obligation to observe those "laws" (and indeed frequently
breaks them). For example, the vast majority of gases don't observe the
gas laws.
And regardless of whether
you want to make that distinction, I doubt you honestly believe
anyone's neighbour turned into a piano.
I don't know for sure that they didn't. :-)
Some more context:

"The standard does indeed not require that UB causes my next door
neighbour to turn into a piano, but that appears to be exactly the
behaviour of my DeathStation 9000.
Are you claiming that this behaviour is not correct?" - Bart v Ingen
Schenau
It's not incorrect, as far as the Standard is concerned.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 11 '07 #117
"Flash Gordon" <sp**@flash-gordon.me.uka écrit dans le message de news:
6i************@news.flash-gordon.me.uk...
Richard Heathfield wrote, On 10/09/07 17:58:
>Charlie Gordon said:

<snip>
>>is the Rationale available for download ?

Yes - if you search for C99 Rationale, it will probably be the top hit.

If you go to http://clc-wiki.net/wiki/c_standard there is definitely a
link to it.
C99RationaleV5.10 seems to be the "latest" version.
Here is the URL for those interested
http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf

Thank you.

--
Chqrlie.
Sep 11 '07 #118
"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
4K******************************@bt.com...
Charlie Gordon said:

<snip>
>is the Rationale available for download ?

Yes - if you search for C99 Rationale, it will probably be the top hit.
As a matter of fact, the top hit is an old version (n897.pdf)
A more recent version is
http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf

--
Chqrlie.
Sep 11 '07 #119
"Douglas A. Gwyn" <DA****@null.netwrote:
Charlie Gordon wrote:
Specifying restrict on arguments in function prototypes gives no indication
to the compiler, and only a vague hint to the programmer, quite insufficient
to avoid undefined behaviour or to generate appropriate warnings.

It did allow us to not put in all those extra chunks of wording
saying that the pointed-to objects shall not overlap.
On strcpy(), yes, but on fgets()? A char * and a FILE * can only overlap
if a. you're invoking UB anyway, by scribbling wildly into the FILE
object through a mispointed char *, or b. you're invoking UB anyway, by
scribbling neatly into the FILE object using undefined and unportable
assumptions about the layout of the FILE.

Richard
Sep 11 '07 #120
Rainer Weikusat wrote:
Chris Dollin <ch**********@hp.comwrites:
>Rainer Weikusat wrote:
>>It is one of the infinitely many things humans make up because
something like an inbred horror vacui compels them to fill any void
with something. But any example of "behaviour" is necessarily
defined and not undefined.

(a) There are many instances of behaviour not defined /by the C
standard/,
which is the backdrop to our usage here.

Put straight into context: There are many instance of beahviour not
defined by the C standard, and since you are claiming to discuss the
C-standard, you spend an enourmous amount of typing to publish wild
speculations about things not defined by the C-standard?
Nobody's "publishing wild speculation". In particular, no-one is
/seriously/ claiming that implementations /will/ do specific
unlikely things. They're saying that the implementation is not
constrained by the standard /in any way/ at various points,
and using humerous exaggeration to do so.

Odd that you didn't answer my evil twin's point (b).
Does that sound a little contradictory?
No.
What's YOUR problem with accepting that what isn't there
simply isn't there?
I don't have a problem in that regard.
And could you perhaps discuss this with a professional?
Being obnoxious does not improve your argument.

--
Far-Fetched Hedgehog
Meaning precedes definition.

Sep 11 '07 #121
"Richard Bos" <rl*@hoekstra-uitgeverij.nla écrit dans le message de news:
46****************@news.xs4all.nl...
"Douglas A. Gwyn" <DA****@null.netwrote:
>Charlie Gordon wrote:
Specifying restrict on arguments in function prototypes gives no
indication
to the compiler, and only a vague hint to the programmer, quite
insufficient
to avoid undefined behaviour or to generate appropriate warnings.

It did allow us to not put in all those extra chunks of wording
saying that the pointed-to objects shall not overlap.

On strcpy(), yes, but on fgets()? A char * and a FILE * can only overlap
if a. you're invoking UB anyway, by scribbling wildly into the FILE
object through a mispointed char *, or b. you're invoking UB anyway, by
scribbling neatly into the FILE object using undefined and unportable
assumptions about the layout of the FILE.
FILE may even be an incomplete type, there is no guarantee that a FILE *
properly cast to a char * can be safely dereferenced at all.

--
Chqrlie.
Sep 11 '07 #122
"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Richard Bos" <rl*@hoekstra-uitgeverij.nla écrit dans le message de news:
46****************@news.xs4all.nl...
[...]
>On strcpy(), yes, but on fgets()? A char * and a FILE * can only overlap
if a. you're invoking UB anyway, by scribbling wildly into the FILE
object through a mispointed char *, or b. you're invoking UB anyway, by
scribbling neatly into the FILE object using undefined and unportable
assumptions about the layout of the FILE.

FILE may even be an incomplete type, there is no guarantee that a FILE *
properly cast to a char * can be safely dereferenced at all.
No, FILE cannot be an incomplete type. C99 7.19.1p2:

FILE

which is an object type capable of recording all the information
needed to control a stream [...]

I don't think think this requirement is necessary (i.e., the standard
could just as easily have allowed, or even required, FILE to be an
incomplete type without breaking any reasonable code), but there it
is.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #123
Keith Thompson wrote:
>
I don't think think this requirement is necessary (i.e., the standard
could just as easily have allowed, or even required, FILE to be an
incomplete type without breaking any reasonable code), but there it
is.
I think the rationale was that there exists code that does:

FILE x;
int main(void) {
/* now &x is guaranteed to be unequal to any FILE* returned by fopen,
and thus can be used as a "special value" indicating some sort of
condition */
return 0;
}

--
You can contact me at <ta*****************@yahoDELETETHATo.fr>
Sep 11 '07 #124
Keith Thompson <ks***@mib.orgwrites:
>No, FILE cannot be an incomplete type. C99 7.19.1p2:
FILE
which is an object type capable of recording all the information
needed to control a stream [...]
>I don't think think this requirement is necessary (i.e., the standard
could just as easily have allowed, or even required, FILE to be an
incomplete type without breaking any reasonable code), but there it
is.
Yep, when the 64 bit ABI for Solaris was defined our hopes to make
FILE completely opaque were quickly dashed by some standards
tests. (Now it's an opaque blob of memory of fixed size)

The hoops we have to jump through in 32 bit space to add additional
data are not pretty.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Sep 11 '07 #125
"Casper H.S. Dik" <Ca********@Sun.COMa écrit dans le message de news:
46*********************@news.xs4all.nl...
Keith Thompson <ks***@mib.orgwrites:
>>No, FILE cannot be an incomplete type. C99 7.19.1p2:
> FILE
> which is an object type capable of recording all the information
needed to control a stream [...]
>>I don't think think this requirement is necessary (i.e., the standard
could just as easily have allowed, or even required, FILE to be an
incomplete type without breaking any reasonable code), but there it
is.

Yep, when the 64 bit ABI for Solaris was defined our hopes to make
FILE completely opaque were quickly dashed by some standards
tests. (Now it's an opaque blob of memory of fixed size)

The hoops we have to jump through in 32 bit space to add additional
data are not pretty.
So it cannot be an incomplete type, but 7.19.3p6 clarifies that the contents
of the FILE object can be meaningless ("The address of the FILE object used
to control a stream may be significant; a copy of a
FILE object need not serve in place of the original.") It should be even
more restrictive and invoke undefined behaviour if the contents of the FILE
object are saved to a copy and then restored to the original object.

Programs with actual FILE objects are asking for trouble.
Bending the Standard to accomodate them is debatable, I would argue against
it.

--
Chqrlie.
Sep 11 '07 #126
"André Gillibert" <ta*****************@yahodeletethato.fra écrit dans le
message de news: op.tyhdvueq7pu1mk@andre...
Keith Thompson wrote:
>>
I don't think think this requirement is necessary (i.e., the standard
could just as easily have allowed, or even required, FILE to be an
incomplete type without breaking any reasonable code), but there it
is.

I think the rationale was that there exists code that does:

FILE x;
int main(void) {
/* now &x is guaranteed to be unequal to any FILE* returned by fopen,
and thus can be used as a "special value" indicating some sort of
condition */
return 0;
}
I am curious how much code does this in real life. As a code reviewer, I
would forbid using actual FILE structures for this or any purpose.

Note that the same effet can be achieved without an actual FILE structure,
using a pointer instead of the address as the "special value":

static char dummy_file_object[1] = "";
FILE *dummy_file_pointer = (FILE *)&dummy_file_object;
dummy_file_pointer is guaranteed to be unequal to any FILE * returned by
fopen.

--
Chqrlie.
Sep 11 '07 #127
CBFalconer <cb********@yahoo.comwrites:
Richard Bos wrote:
>Rainer Weikusat <rw*******@mssgmbh.comwrote:
>>Keith Thompson <ks***@mib.orgwrites:

We don't claim (except jokingly) that executing those statements
*will* cause demons to fly out of your nose. The claim is merely
that nasal demons are one of the infinitely many behaviors
permitted by the standard.

It is one of the infinitely many things humans make up because
something like an inbred horror vacui compels them to fill any
void with something. But any example of "behaviour" is
necessarily defined and not undefined.

You have obviously never read much about quantum physics. And yes,
when the Standard does not define what a piece of code does but
leaves it up to the compiler, and when that compiler does not care
to make sure that that code does something specific but leaves it
up to the accidents of microprocessor behaviour (which both could
very well do, and with good reason), then quantum physics really
can toss the coin about how that code behaves, on that day, on
that computer.

My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.
No they don't. They either leave it as is or increments/decrements.
Sep 11 '07 #128
Charlie Gordon wrote:
"André Gillibert" <ta*****************@yahodeletethato.fra écrit dans
le
message de news: op.tyhdvueq7pu1mk@andre...
>>
I think the rationale was that there exists code that does:

FILE x;
int main(void) {
/* now &x is guaranteed to be unequal to any FILE* returned by fopen,
and thus can be used as a "special value" indicating some sort of
condition */
return 0;
}

I am curious how much code does this in real life. As a code reviewer, I
would forbid using actual FILE structures for this or any purpose.
I think very little code.
>
Note that the same effet can be achieved without an actual FILE
structure,
using a pointer instead of the address as the "special value":

static char dummy_file_object[1] = "";
FILE *dummy_file_pointer = (FILE *)&dummy_file_object;
dummy_file_pointer is guaranteed to be unequal to any FILE * returned by
fopen.
This seems much worse than the very ugly code I posted.
There may be alignment requirements issue. That looks like UB to me.

6.3.2.3p7 contains:
| A pointer to an object or incomplete type may be converted
| to a pointer to a different object or incomplete type.
| If the resulting pointer is not correctly aligned 57) for the
| pointed-to type, the behavior is undefined.

struct {int x;} dummy_file_object;

Has more chance to work, since 6.2.5p26 contains:
| All pointers to structure types shall have the same
| representation and alignment requirements as each other.

--
You can contact me at <ta*****************@yahoDELETETHATo.fr>
Sep 11 '07 #129
Keith Thompson wrote:
"Charlie Gordon" <ne**@chqrlie.orgwrites:
.... snip ...
>
>FILE may even be an incomplete type, there is no guarantee that a
FILE * properly cast to a char * can be safely dereferenced at all.

No, FILE cannot be an incomplete type. C99 7.19.1p2:

FILE

which is an object type capable of recording all the information
needed to control a stream [...]

I don't think think this requirement is necessary (i.e., the
standard could just as easily have allowed, or even required, FILE
to be an incomplete type without breaking any reasonable code),
but there it is.
However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type. However it
is the height of foolishness to use this description, which would
be available in stdio.h.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Sep 11 '07 #130
"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:46***********************@news.free.fr...
Note that the same effet can be achieved without an actual FILE structure,
using a pointer instead of the address as the "special value":

static char dummy_file_object[1] = "";
FILE *dummy_file_pointer = (FILE *)&dummy_file_object;
dummy_file_pointer is guaranteed to be unequal to any FILE * returned by
fopen.
That doesn't work if FILE has non-trivial alignment requirements.

Sep 11 '07 #131
"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type.
Couldn't the macros cast their FILE* argument to a pointer to another,
complete type?

Sep 11 '07 #132
CBFalconer <cb********@yahoo.comwrote:
Keith Thompson wrote:
"Charlie Gordon" <ne**@chqrlie.orgwrites:
FILE may even be an incomplete type, there is no guarantee that a
FILE * properly cast to a char * can be safely dereferenced at all.
No, FILE cannot be an incomplete type. C99 7.19.1p2:

FILE

which is an object type capable of recording all the information
needed to control a stream [...]

I don't think think this requirement is necessary (i.e., the
standard could just as easily have allowed, or even required, FILE
to be an incomplete type without breaking any reasonable code),
but there it is.

However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type. However it
is the height of foolishness to use this description, which would
be available in stdio.h.
Not necessarily. getc() and so on can use unsigned char * hackery in a
way which is legal and reasonable for the implementation, but not for
the user-programmer.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Richard
Sep 11 '07 #133
In article <46****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type. However it
is the height of foolishness to use this description, which would
be available in stdio.h.
>Not necessarily. getc() and so on can use unsigned char * hackery in a
way which is legal and reasonable for the implementation, but not for
the user-programmer.
What "unsigned char *" hackery is needed? If FILE is an incomplete
type, getc() can just cast its argument to (say) _FILE *.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 11 '07 #134
ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <46****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type. However it
is the height of foolishness to use this description, which would
be available in stdio.h.
Not necessarily. getc() and so on can use unsigned char * hackery in a
way which is legal and reasonable for the implementation, but not for
the user-programmer.

What "unsigned char *" hackery is needed?
Not necessary, but sufficient.
If FILE is an incomplete type, getc() can just cast its argument to
(say) _FILE *.
True, but in that case you might as well make FILE a complete type.

Richard
Sep 11 '07 #135
"Charlie Gordon" <ne**@chqrlie.orgwrites:
>So it cannot be an incomplete type, but 7.19.3p6 clarifies that the contents
of the FILE object can be meaningless ("The address of the FILE object used
to control a stream may be significant; a copy of a
FILE object need not serve in place of the original.") It should be even
more restrictive and invoke undefined behaviour if the contents of the FILE
object are saved to a copy and then restored to the original object.
Yes. But that is all well and good but we have to deal with
existing application binaries which need to continue to work
while we also try to lift some limits for new applications.

A large part of the actual trouble for exissting binaries stems
from *get* macros, the fileno() macro, etc.

Macros are really evil if you want to have future binary compatibility
and lack sufficiently effective crystal balls.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Sep 11 '07 #136
"Casper H.S. Dik" <Ca********@Sun.COMa écrit dans le message de news:
46*********************@news.xs4all.nl...
"Charlie Gordon" <ne**@chqrlie.orgwrites:
>>So it cannot be an incomplete type, but 7.19.3p6 clarifies that the
contents
of the FILE object can be meaningless ("The address of the FILE object
used
to control a stream may be significant; a copy of a
FILE object need not serve in place of the original.") It should be even
more restrictive and invoke undefined behaviour if the contents of the
FILE
object are saved to a copy and then restored to the original object.

Yes. But that is all well and good but we have to deal with
existing application binaries which need to continue to work
while we also try to lift some limits for new applications.

A large part of the actual trouble for exissting binaries stems
from *get* macros, the fileno() macro, etc.

Macros are really evil if you want to have future binary compatibility
and lack sufficiently effective crystal balls.
Binary compatibility is a separate issue.

Maintaining binary compatibility was the main cause for inventing shadow
structures to extend FILE objects without changing their size, structure or
location, all fixed because of getc/putc and stdin/stdout... macros.

macros or inline functions for getc/putc used to be key for program
efficiency. This is less true today, because processors are so much faster
and cpu time waste so ubiquitous.

Making FILE an incomplete type only impacts source code compatibility in
very remote cases where FILE objects are instantiated explicitly. An oddity
found only in C library test suites and not worth preserving IMHO.

Making FILE an incomplete type and not resorting to casting FILE* to some
other type to achieve inline expansion would effectively support future
binary compatibility, but the current wording of the Standard prevents that.

--
Chqrlie.
Sep 11 '07 #137
On 2007-09-09 23:28, Charlie Gordon <ne**@chqrlie.orgwrote:
"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
>Chris Dollin <ch**********@hp.comwrites:
>>jacob navia wrote:
[...]
>>>In the case of fgets this implies:
[...]
>>o Testing that the non-null stream points to a legal C object
Only the char * pointer would be hard to verify, the stream pointer should
be easy to check against open streams handled by the library, as any
conforming library needs to account for at least those open for write and
update:

7.19.5.2p3 If stream is a null pointer, the fflush function performs this
flushing action on all
streams for which the behavior is defined above.

C libraries used to allocate FILE structures from a static array: checking
for valid FILE pointers was pretty easy then. I would be surprised if
current implementations could no longer do this efficiently.
On many modern system there is no fixed limit on the number of open
files, so a static array isn't feasible. And once you start allocating
them individually, you either have to check all of them (which is not
efficient) or use a more complicated structure (like a binary tree) only
this check.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Sep 11 '07 #138
CBFalconer <cb********@yahoo.comwrites:
>Keith Thompson wrote:
>No, FILE cannot be an incomplete type. C99 7.19.1p2:

FILE

which is an object type capable of recording all the information
needed to control a stream [...]

I don't think think this requirement is necessary (i.e., the
standard could just as easily have allowed, or even required, FILE
to be an incomplete type without breaking any reasonable code),
but there it is.
>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type.
If they are macros, if they are in C and if they access the structure
members directly. Although those are traditional (and, if they are C
macros, it's hard to see the point if they do not access the structure
directly), none of them is required.

The implementor can use knowledge of the structure, while hiding it
from the user.

--
dhs sp*****@panix.com
Sep 11 '07 #139
Charlie Gordon wrote:

Making FILE an incomplete type and not resorting to casting FILE* to some
other type to achieve inline expansion would effectively support future
binary compatibility, but the current wording of the Standard prevents
that.
But the standard permits FILE to be completely opaque and safe to binary
changes.

typedef struct FILE {char dummy;} FILE;

Is permitted by the standard.

Now, as an implementor, you can have your own opaque _FILE structure, and
internally typecast FILE* to _FILE*.

It's even possible in macros.

Even though the requirement of the standard may sound stupid, I see no
good reason for violating the standard at this place.

--
You can contact me at <ta*****************@yahoDELETETHATo.fr>
Sep 11 '07 #140
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-09 23:28, Charlie Gordon <ne**@chqrlie.orgwrote:
>"Keith Thompson" <ks***@mib.orga crit dans le message de news:
ln************@nuthaus.mib.org...
>>Chris Dollin <ch**********@hp.comwrites:
jacob navia wrote:
[...]
In the case of fgets this implies:
[...]
>>>o Testing that the non-null stream points to a legal C object
>Only the char * pointer would be hard to verify, the stream pointer
should
be easy to check against open streams handled by the library, as any
conforming library needs to account for at least those open for write and
update:

7.19.5.2p3 If stream is a null pointer, the fflush function performs
this
flushing action on all
streams for which the behavior is defined above.

C libraries used to allocate FILE structures from a static array:
checking
for valid FILE pointers was pretty easy then. I would be surprised if
current implementations could no longer do this efficiently.

On many modern system there is no fixed limit on the number of open
files, so a static array isn't feasible. And once you start allocating
them individually, you either have to check all of them (which is not
efficient) or use a more complicated structure (like a binary tree) only
this check.
Instead of allocating them individually, you can allocate them in chunks of
increasing sizes, keeping the complexity of the test in logN, which is still
quite efficient.

--
Chqrlie.
Sep 11 '07 #141
Richard wrote:
CBFalconer <cb********@yahoo.comwrites:
My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.
No they don't. They either leave it as is or increments/decrements.
While CBFalconer was exaggerating, it is also not the case that
any given C compiler will "either leave it as is or increment/
decrement". Because the behavior is undefined, the compiler
can generate code that is efficient in the well-defined case
but which happens to "misbehave" in the undefined case. That
misbehavior often is deterministic, but might not be either of
the behaviors you stated.
Sep 11 '07 #142
Richard Bos wrote:
On strcpy(), yes, but on fgets()? A char * and a FILE * can only overlap
if a. you're invoking UB anyway, by scribbling wildly into the FILE
object through a mispointed char *, or b. you're invoking UB anyway, by
scribbling neatly into the FILE object using undefined and unportable
assumptions about the layout of the FILE.
Um, no, consider fgets((char *)(void *)fp, (int)sizeof(FILE), fp);
while it may be a stupid thing to do, if no further use is made
of the associated stream it would have been allowed, and the
implementation would have to make it work, which means making
a copy of the FILE structure before starting the transfer.
By prohibiting overlap of the pointed-to objects, we assure
the implementor that he doesn't have to worry about that.
Sep 11 '07 #143
On Tue, 11 Sep 2007 00:12:03 +0000, Douglas A. Gwyn wrote:
Harald van D?k wrote:
>Douglas A. Gwyn wrote:
CBFalconer wrote:
"Douglas A. Gwyn" wrote:
Not allowed by whom? The program may not be strictly conforming,
but it should still work. If you want to get really fussy about
it, make "mystdio.h" define FILE without including <stdio.h>
(which requires some implementation-dependent kludgery); then the
fgets-redefining macro is "allowed".
Not allowed by the C standard. Just because it will work on _some_
systems doesn't make it viable. Undefined behaviour includes doing
what you think is right.
It will in fact work on any actual platform. If that isn't good
enough for the fellow, then what would be?
That's a bold claim. With fgets, it would work on my implementation.
With strlen for example, it would not, because <string.h>'s macro
definition of strcpy refers to it by name. Are you sure no
implementation does anything similar with fgets?

I think you missed the fact that <stdio.his *not* #included in the
context in which the "fgets" layering macro is defined and used.
This started with:

"Army1987" <ar******@NOSPAM.itwrote...
On Fri, 07 Sep 2007 17:38:50 +0000, Douglas A. Gwyn wrote:
/* mystdio.h */
#include <stdio.h// just for FILE
extern char *myfgets(char *, int, FILE *);
#undef fgets // in case <stdio.hdefined it
#define fgets myfgets
You're not allowed to do that.
where you did include <stdio.hbefore defining fgets. When /not/
including <stdio.hyou noted that FILE must be defined, and that the way
it must be defined depends on the implementation, so exactly what is it
that "will in fact work on any actual platform"?

(My apologies if you end up reading this more than once. I'm having
problems with my newsreader.)
Sep 11 '07 #144
"Douglas A. Gwyn" <DA****@null.neta écrit dans le message de news:
46***************@null.net...
Richard Bos wrote:
>On strcpy(), yes, but on fgets()? A char * and a FILE * can only overlap
if a. you're invoking UB anyway, by scribbling wildly into the FILE
object through a mispointed char *, or b. you're invoking UB anyway, by
scribbling neatly into the FILE object using undefined and unportable
assumptions about the layout of the FILE.

Um, no, consider fgets((char *)(void *)fp, (int)sizeof(FILE), fp);
while it may be a stupid thing to do, if no further use is made
of the associated stream it would have been allowed, and the
implementation would have to make it work, which means making
a copy of the FILE structure before starting the transfer.
By prohibiting overlap of the pointed-to objects, we assure
the implementor that he doesn't have to worry about that.
nonsense!

and of course fread(fp, sizeof FILE, 1, fp) invokes UB as well, no need to
sprinkle prototypes with useless keywords to spell the obvious.

If this is the kind of issue on which the commitee focusses between releases
of the Standard, the situation is hopeless.

--
Chqrlie.
Sep 11 '07 #145
Wojtek Lerch wrote:
>
"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:46***********************@news.free.fr...
Note that the same effet can be achieved without an actual FILE structure,
using a pointer instead of the address as the "special value":

static char dummy_file_object[1] = "";
FILE *dummy_file_pointer = (FILE *)&dummy_file_object;
dummy_file_pointer is guaranteed to be unequal to any FILE * returned by
fopen.

That doesn't work if FILE has non-trivial alignment requirements.
Does alignment matter if the pointer is never dereferenced? From
context, I assume its sole purpose is as a value to be stored and
compared against. You know that the address is valid, so it can't
be a trap representation.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 11 '07 #146
"Casper H.S. Dik" wrote:
>
Keith Thompson <ks***@mib.orgwrites:
No, FILE cannot be an incomplete type. C99 7.19.1p2:
FILE
which is an object type capable of recording all the information
needed to control a stream [...]
I don't think think this requirement is necessary (i.e., the standard
could just as easily have allowed, or even required, FILE to be an
incomplete type without breaking any reasonable code), but there it
is.

Yep, when the 64 bit ABI for Solaris was defined our hopes to make
FILE completely opaque were quickly dashed by some standards
tests. (Now it's an opaque blob of memory of fixed size)

The hoops we have to jump through in 32 bit space to add additional
data are not pretty.
Is this a valid FILE definition?

typedef struct
{
struct _OPAQUE_FILE *private;
}
FILE;

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 11 '07 #147
Charlie Gordon wrote:
>
"Peter J. Holzer" <hj*********@hjp.ata écrit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-09 23:28, Charlie Gordon <ne**@chqrlie.orgwrote:
[...]
C libraries used to allocate FILE structures from a static array:
checking
for valid FILE pointers was pretty easy then. I would be surprised if
current implementations could no longer do this efficiently.
On many modern system there is no fixed limit on the number of open
files, so a static array isn't feasible. And once you start allocating
them individually, you either have to check all of them (which is not
efficient) or use a more complicated structure (like a binary tree) only
this check.

Instead of allocating them individually, you can allocate them in chunks of
increasing sizes, keeping the complexity of the test in logN, which is still
quite efficient.
Well, you can't realloc() the array, as that would invalidate all
existing FILE* values. (Unless it returned the same address, which
is certainly not guaranteed, or even very likely in most scenarios.)

You can, however, allocate chunks of fixed-sized arrays which are then
put on a linked list. Not as efficient as a single array, but a lot
more efficient than individual allocations.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 11 '07 #148
Richard wrote:
>
CBFalconer <cb********@yahoo.comwrites:
[...]
My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.

No they don't. They either leave it as is or increments/decrements.
Are you 100% certain? There is no possibility that it will do
something other than (1) leave it as is or (2) increment/decrement
it?

While I don't have a DS9000 (I can't afford the upgrade from my
older DS6000), I understand that CBFalconer's description is
pretty accurate for the DS9000. And, as he says, it is standard
conforming.

FYI - the DS6000 gets stuck in a bus conflict exception loop on the
execution of "i = i++;". (Assuming i is an integer type.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 11 '07 #149
"Douglas A. Gwyn" <DA****@null.netwrote in message
news:46***************@null.net...
Um, no, consider fgets((char *)(void *)fp, (int)sizeof(FILE), fp);
while it may be a stupid thing to do, if no further use is made
of the associated stream it would have been allowed, and the
implementation would have to make it work, which means making
a copy of the FILE structure before starting the transfer.
Are you implying that

memset(stdin,6,sizeof(FILE));

is allowed, as long as no further use is made of stdin by the program? Or
would I also need to make sure that the program terminates by calling
abort() and that abort() doesn't attempt to flush or close streams on my
implementation?

Does this also mean that it's wrong for an implementation to keep track of
all the open streams by using a linked list of all the FILE objects, because
my memset() call may break the list and cause trouble when an unrelated
stream is opened or closed?

Sep 11 '07 #150

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Krumble Bunk | last post: by
27 posts views Thread by =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.