delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/29/11:43:47

From: dontmailme AT iname DOT com (Steamer)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Weird : Segmentation fault on fwrite :(
Date: Sat, 29 Apr 2000 16:05:06 GMT
Organization: always disorganized
Lines: 60
Message-ID: <390b082d.115387116@news.freeserve.net>
References: <956963090 DOT 719428 AT romulus DOT infonie DOT fr> <957001855 DOT 943830 AT romulus DOT infonie DOT fr> <8eef1d$ai7$1 AT plato DOT wadham DOT ox DOT ac DOT uk> <390adf87 DOT 104978688 AT news DOT freeserve DOT net> <8eesmi$c8g$1 AT plato DOT wadham DOT ox DOT ac DOT uk>
NNTP-Posting-Host: modem-148.domino-damsel.dialup.pol.co.uk
X-Trace: newsg1.svr.pol.co.uk 957024307 17634 62.136.255.148 (29 Apr 2000 16:05:07 GMT)
NNTP-Posting-Date: 29 Apr 2000 16:05:07 GMT
X-Complaints-To: abuse AT theplanet DOT net
X-Newsreader: Forte Free Agent 1.11/32.235
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

J-P wrote:

>Ah. This is the relevant bit from K&R. Appendix A7.3 - Postfix
>Expressions (subsequently "PE"s).
>
>	A7.3.1 Array References
>
>	A PE followed by an E in square brackets { i.e. PE[E] - jps } is a
>	postfix expression denoting a subscripted array reference. One of
>	the two expressions must have type "pointer to T", where T is some
>	type, and the other must have integral type. 
>
>So in my example, "arrayname" /is/ of type "pointer to char". Isn't it?
>According to K&R, at least, there seems no ambiguity.

Well, arrayname will be interpreted as a pointer to char in most
contexts, but really it's something different.  One context where it
is clearly different is when you try to take its address.  Another is
when you apply sizeof to it, getting the size of the array (80 in your
example), rather than the size of a pointer (4 in DJGPP).

In my original reply to you, I referred to this interpretation as
"conversion", but actually that's too strong strong a word, since it
really is considered to _be_ a pointer in most contexts.

I don't think K&R are at all clear about this, and the piece you quote
above is, at the very least, misleading.

>Perhaps the printf family of functions is clever and recognises pointer to
>pointer, and the standard libraries allow gcc to compile equivalent
>executables. Any idea? Have I interpreted K&R wrong, do K&R slip up at
>this point, or is gcc/printf doing something wiley?

This is not special to printf, nor to gcc.  K&R is simply unclear about
this stuff.  Whenever arrayname is the name of an array, then

    &arrayname == arrayname

will evaluate to 1.  (The compiler will, however, give a warning, because
one side is a pointer to an array, while the other side is [interpreted as]
a pointer to a whatever-it's-an-array-of.)  I agree that this is horrible,
and I've never felt the need to use &arrayname, but this is certainly the
way it works.

One thing you might like to look at in K&R is in section 5.11 where it
says (talking about functions passed as parameters):

    Since they are known to be functions, the & operator is not
    necessary, in the same way that it is not needed before an
    array name.

This at least hints at the truth, although again it's misleading.

>If anyone wants to suggest a more relevant newsgroup, I'd happily follow
>this there, trn willing.

I suppose this ought to go in a C language newsgroup, but I dislike the
idea of threads disappearing off into a different newsgroup.

S.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019