Re: Banks and economy
- From: s_dubrovich@xxxxxxxxx
- Date: Wed, 22 Oct 2008 09:53:01 -0700 (PDT)
On Oct 21, 9:58 am, Phil Carmody <thefatphil_demun...@xxxxxxxxxxx>
wrote:
s_dubrov...@xxxxxxxxx writes:I'm not changing my argument, that quote is what I replied to Rod.
On Oct 19, 11:15 am, Phil Carmody <thefatphil_demun...@xxxxxxxxxxx>
wrote:
s_dubrov...@xxxxxxxxx writes:
Is OW saying it makes 1
byte pointers? YES!
If they implicitly did cptr[1], then there is no space allocation for the
pointer type - which I think is correct for "arrays", and the cptr pointer
would just be the address of the cptr label, and the 1 byte would be the
implicit allocation of a byte. Perhaps? Maybe? :-)
char cptr[]; is a pointer
Just plain wrong.
Just a minute, pay attention...
K&R C,
What is indicated is...
"As formal parameters in a function definition;
What you posted was nothing to do with formal parameters in a
function definition. Don't change your argument. It was to
do with static allocation.
You are jumping into the middle of my argument, and are jumping on the
one half, the syntax in the static allocation part. The other part is
the syntax in the formal parameter part.
To recap..
Since, as a formal parameter, char cptr[]; is a pointer, I was
expecting
the same treatment of char cptr[] as a pointer in the static
allocation. You both point out that I'm wrong, I accept that.
However, the notion of 'incomplete type' isn't explicit in K&R C.
In terms of file scope, it seems reasonable _to me_ to treat it as a
pointer to the 'completing' declaration, in an implementation. _To
me_ the compiler implementation needs to resolve to the completing
declaration, or flag an error.
But no, the standard allows generating a array of 1 member of char,
fine.
You posted, in response to Rod:I don't deny my misunderstandings of C, for sure. Why didn't you
"""> Let's see what DJGPP (GCC) and Openwatcom do with this:
char cptr[];
int *mydata;
errtest()
{
return 0;
}
On that code as 32-bits (not 16-bits), Openwatcom allocated space of 1 byte
for "cptr" and 4 bytes for "mydata".
ROFL, OW shows it is brain dead! Space allocation is supposed to be
of PointerType, not of what it points to!! Is OW saying it makes 1
byte pointers? YES!
"""
No formal parameters there. Plenty of misunderstanding of C though.
quote the previous part I said?
"
As you note below;
" I understand that "char cptr[]" is "char *cptr". "
These are both Declarations of pointers to char. In this case they
are declared outside a block, so they are treated as 'static storage
class', by these vintage compilers, that means held in the data
segment. see. K&R 2.4 Declarations. "External and static variables
are initialized to zero by default,..."
Presumeably, the declaration shows intent to use the pointers, which
will be assigned some valid pointer, so pointer space in the data
segment needs to be allocated statically at compile time, at least
that's what these vintage compilers did. 'TIMES 0 dw 0' doesn't
allocate pointer space, or _any_ space, it is like a union label to
the following data object, but is should've been like the other
pointer syntax; *cptr. -- at least the 'fix' treats them both the
same
way.
"
This shows my other part, expecting the static declaration of char
cptr[]; to be a pointer. So I'm wrong to the standard, (shrug), I
didn't write the thing.
No doubt, I'm proof.
It is an incomplete type of type array of char. It has no size
at all. And that doesn't mean it has zero size, it means that
one may not say anything about its size. Without a later
declaration, there will be an implicit initialisation of one
element (that is, one char), to zero.
-For modern C-
-I agree with you on your first 3 sentences, and have issue with the
fourth.-
"Without a later declaration, there will be an implicit initialisation
of one
element (that is, one char), to zero."
-Without a later declaration, this should be an error, because...-
INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:TC3 n1256.pdf
§6.2.5 Language pg. 35
"20 Any number of derived types can be constructed from the object,
function, and
incomplete types, as follows:
— An array type describes a contiguously allocated nonempty set of
objects with a
particular member object type, called the element type.(36) Array
types are characterized by their element type and by the number of
elements in the array. An array type is said to be derived from its
element type, and if its element type is T, the array type is
sometimes called ‘‘array of T’’. The construction of an array type
from an element type is called ‘‘array type derivation’’."
"(36) Since object types do not include incomplete types, an array of
incomplete type cannot be constructed."
-However with a later declaration which completes the type, then the
object can be constructed and initialized.-
I little knowledge can be a dangerous thing.
You're missing:
"""
6.9.2 External object definitions
Semantics
[...]
2 A declaration of an identifier for an object that has file scope without an initializer, and
without a storage-class specifier or with the storage-class specifier static, constitutes a
tentative definition. If a translation unit contains one or more tentative definitions for an
identifier, and the translation unit contains no external definition for that identifier, then
the behavior is exactly as if the translation unit contains a file scope declaration of that
identifier, with the composite type as of the end of the translation unit, with an initializer
equal to 0.
[...]
5 EXAMPLE 2 If at the end of the translation unit containing
int i[];
the array i still has incomplete type, the implicit initializer causes it to have one element, which is set to
zero on program startup.
"""
Yes, I had missed that. I didn't go looking for it there as I
expected cptr to be a static allocation of a _pointer_, not an
incomplete type of array
There's no explicit notions of 'tentative definitions', 'incomplete
I.e. in the context you had it,
char cptr[];
is exactly equivalent to
char cptr[1]={0};
Which makes cptr (wow, what a curious name to give that variable)
clearly have size 1.
As formal parameters in a function definition;
char *cptr,
char cptr[];
are exactly equivalent,
And exactly irrelevant. The context your above statement
is not that of formal parameters to functions.
The K&R C context should be clear from a couple of messages back.
This is nothing to do with K&R vs. ISO C. This is to do with
tentative definitions of objects of incomplete type vs.
formal parameters to functions, which are completely different
things.
types', that I can find in K&R C, Phil, we're talking circa 1978
here.
Take this to comp.lang.c if you don't believe me. Follow-ups set.No thanks, I rather believe you :-)
Steve
Phil.
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
-- George Bernard Shaw (1856-1950), Preface to Androcles and the Lion- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
- Follow-Ups:
- Re: Banks and economy
- From: aku ankka
- Re: Banks and economy
- References:
- [OT] Banks and economy
- From: rio
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Rod Pemberton
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Rod Pemberton
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Rod Pemberton
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Rod Pemberton
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Rod Pemberton
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Rod Pemberton
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Phil Carmody
- Re: Banks and economy
- From: s_dubrovich
- Re: Banks and economy
- From: Phil Carmody
- [OT] Banks and economy
- Prev by Date: Re: X86 Opcode and Instruction Reference 1.00: Massive update
- Next by Date: Re: Banks and economy
- Previous by thread: Re: Banks and economy
- Next by thread: Re: Banks and economy
- Index(es):
Relevant Pages
|