osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/29/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Fri, 29 Mar 85 Volume 4 : Issue 21
Today's Topics:
const
routines for seeking
----------------------------------------------------------------------
Date: Fri, 29 Mar 85 01:10:56 est
From: hcr!lsuc!msb
Subject: const
To: hcr!cbosgd!std-c
I have just learned that I never understood the way the new extension
"const" is defined. (I'm going to go into a bit of detail about assumptions
here because this posting has been preceded by a couple of rounds of mail.)
I had figured that since read-only-ness is usually implemented (when
possible) as a property of memory areas, const would naturally be a
storage class. Not so. Henry Spencer (utzoo!henry) recently explained in
net.lang.c:
> Here's how [const] works:
>
> const char *pcc; /* ptr to const char */
> char *const cpc; /* const ptr to char */
>
> It is agreed that the syntax is a bit ugly, but then C declaration
> syntax has never been beautiful.
What this means is that const is not a storage class but a type modifier.
I find the syntax and the notion counterintuitive. And I think that
declaring in the type of a pointer whether it points to constant storage
or not isn't likely to be very useful; I don't think we need "const char *".
Now, "const char" and "char * const" are clearly useful, of course. But it
seemed to me that const could be made a storage class, the above "const char *"
dropped, and "char * const" renamed "const char *", as I expected originally.
I proposed this to Henry, and asked why they didn't make const a storage
class to start with. He replied by mail (quoted with permission):
> Three reasons, I think. First, it's orthogonal to the other storage
> classes, and would have to be a "storage class modifier" or something
> like that. ("static const foo" makes perfect sense, for example.)
> Second, the reason for "const char *" (ptr to const char) is so that
> the compiler can tell whether "*ptr = 'x';" is legal or not, which it
> isn't when ptr is a pointer to a const area. Third, having it as a
> type modifier opens up several other uses, such as using it to mark
> function parameters which the function doesn't modify.
The first point is obviously correct, so my remarks above should be amended
to say "storage class modifier".
The second point isn't as good as it sounds. You want to be able to make
regular char *'s point at both constant and non-constant chars, of course:
char *p, buf[BUFLEN];
if (q>0) { sprintf (buf, "Q was %d", q); p = buf; }
else p = "Q was zero";
I hope nobody is suggesting that THAT is illegitimate. But then the compiler
CAN'T tell whether "*p = 'x';" is legal or not. So the type "pointer to const
char" doesn't give you sufficient protection, and does modify the type
concepts in an unwieldy way.
The third point is interesting, but again doesn't seem worth the complexity.
I want const to be a storage class modifier. Henry sort of agrees:
> Personally, I think the major need could be met just fine with const
> as a storage class modifier. But somebody got enthusiastic...
Just like with case ranges, and now they've gone. (In case I never said so
publicly, Larry Rosler convinced me by mail that they should not be added.)
> (Don't blame the ANSI committee ... the enthusiastic folks
> were at AT&T somewhat before the ANSI effort got started.)
Does this mean that it's too late to fix it?
{ allegra | decvax | duke | ihnp4 | linus | watmath | ... } !utzoo!lsuc!msb
also via { hplabs | amd | twg | ... } !pesnta!lsuc!msb
Mark Brader and uw-beaver!utcsri!lsuc!msb
------------------------------
Date: Tue, 26 Mar 85 22:52:21 est
From: decvax!minow (Martin Minow)
Subject: routines for seeking
To: std-c@cbosgd.ATT.UUCP
I was just about to post some suggestions for the fseek problem
when Kevin Martin (ihnp4!watmath!kpmartin) beat me to it. Here
are a few notes/comments/additions:
frepostion(fd, position, offset)
repositions the file. position is a magic cookie returned by
ftell().
All systems should be able to reposition forward (offset >= 0).
Some will not reposition backward.
Perhaps the "right" solution would be to leave fseek/ftell alone
for backwards compatibility and add new routines that return/accept
a reposition struction. fseek/ftell would then be redefined in
terms of those routines.
(A routine that converted a ftell value to a position and v.v. would
also be needed.)
Martin Minow
decvax!minow
------------------------------
End of mod.std.c Digest - Fri, 29 Mar 85 12:35:31 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.