Article View: comp.std.c
Article #2968Re: fwrite+fread of pointer
From: Norman Diamond
Date: Tue, 17 Nov 1992 07:17
Date: Tue, 17 Nov 1992 07:17
53 lines
3667 bytes
3667 bytes
In article <15976@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <1992Nov15.065204.22137@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
>> First, I take it that everyone agrees that the bytes read back from
>> the file have to be the same ones that were written out. The question
>> then is whether the bytes that represent the pointer value &dummy have
>> to always be the same ones, during the life of the variable "dummy".
>That is indeed the question.
Uh, that was my question, and I thought that was your question, but then
you proceed to suggest that your real question was a bit different....
>I have been arguing for a while in comp.lang.c that it would be
>a good thing if C compilers were to warn about fwrite(&x... or fread(&x...
>where x is of a type which can include pointers. I have seen too many
>students get this wrong. It is a particularly easy mistake to make:
> struct Tag { ... char field[20]; ... } x;
> fwrite(&x, sizeof x, 1, f);
>and then the instructor points out that `field' is supposed to hold
>file names and 20 is absurdly small, so the student changes it to
> struct Tag { ... char *field; ... } x;
>and misses a couple of the fwrite()s.
[...some other argue that it might be useful...]
>[...]is it EVER possible for a _portable_ program to write out a pointer
>and usefully read it back?
The ability to write pointers might be useful. As a pedantic example,
an interpreter might create a core dump of a subject program. The ability
to write the bytes and read them back is certainly possible and portable.
However, you have certainly demonstrated that a warning would be useful,
at least for some users in some cases. The standard certainly allows such
warnings, and quality of implementation might suggest an option. It's only
a matter of opinion whether the default have them enabled or disabled.
It seems that this is the question you really wanted to ask, and the
answer seems to be clear enough.
>The question can now be paraphrased: is a pointer like a tensor, or like
>the components of a tensor? I would regard a compacting garbage collector
>as simply changing the co\"ordinate system. I have used hardware and
>software systems where stacks could be moved (in order to "stretch" them)
>while the owning thread was running.
Well, obviously in virtual memory, and less obviously in some other
addressing techniques, it is possible to move objects and keep existing
pointers meaningful without changing them. And the C standard doesn't
talk about tensors or components of tensors; an implementation could make
pointers be even more obscure as long as the results are correct. Now,
how many results have to be guaranteed? That's the same old hard question.
--
Norman Diamond diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Technical Details
Message-ID:
<1992Nov17.071738.17760@nntpd.lkg.dec.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!walter!att-out!pacbell.com!sgiblab!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamondReferences:
<15935@goanna.cs.rmit.oz.au> <1992Nov13.101813.163@nntpd.lkg.dec.com> <1992Nov15.065204.22137@sq.sq.com> <15976@goanna.cs.rmit.oz.au>Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c Path: arc1-ca.pugleaf.net!sparky!uunet!walter!att-out!pacbell.com!sgiblab!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamond From: diamond@jit345.bad.jit.dec.com (Norman Diamond) Subject: Re: fwrite+fread of pointer Message-ID: <1992Nov17.071738.17760@nntpd.lkg.dec.com> Sender: usenet@nntpd.lkg.dec.com (USENET News System) Reply-To: diamond@jit.dec.com (Norman Diamond) Organization: Digital Equipment Corporation Japan , Tokyo References: <15935@goanna.cs.rmit.oz.au> <1992Nov13.101813.163@nntpd.lkg.dec.com> <1992Nov15.065204.22137@sq.sq.com> <15976@goanna.cs.rmit.oz.au> Date: Tue, 17 Nov 1992 07:17:38 GMT Lines: 53