Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: Banks and economy (http://www.velocityreviews.com/forums/t640929-re-banks-and-economy.html)

s_dubrovich@yahoo.com 10-21-2008 11:06 PM

Re: Banks and economy
 
On Oct 21, 9:58 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> s_dubrov...@yahoo.com writes:
> > On Oct 19, 11:15 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > wrote:
> >> s_dubrov...@yahoo.com 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.
>

I'm not changing my argument, that quote is what I replied to Rod.
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:
> """> 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.
>

I don't deny my misunderstandings of C, for sure. Why didn't you
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.

>
> >> 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.
>

No doubt, I'm proof.

> 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.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.
>

There's no explicit notions of 'tentative definitions', 'incomplete
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, hmm :-)

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



Nick Keighley 10-22-2008 07:28 AM

on topic to clc [Was: Banks and economy]
 
the original title may have confused other clc
readers. This *is* actually about C.

[I haven't made any useful response]


On 22 Oct, 00:06, s_dubrov...@yahoo.com wrote:
> On Oct 21, 9:58 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> wrote:
> > s_dubrov...@yahoo.com writes:
> > > On Oct 19, 11:15 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > > wrote:
> > >> s_dubrov...@yahoo.com 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.

>
> I'm not changing my argument, that quote is what I replied to Rod.
> 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:
> > """> 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.

>
> I don't deny my misunderstandings of C, for sure. *Why didn't you
> 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.
>
>
>
>
>
>
>
> > >> 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.

>
> No doubt, I'm proof.
>
>
>
>
>
> > 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.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.

>
> There's no explicit notions of 'tentative definitions', 'incomplete
> 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, hmm :-)


James Kuyper 10-22-2008 11:09 AM

Re: Banks and economy
 
s_dubrovich@yahoo.com wrote:
[An awful lot of badly trimmed and confusing discussion]

If you want a comp.lang.c answer, you'll need to clarify what the issues
being discussed actually are. It would help if you had told us what
forum this thread was transferred from, so that we could trace the
history of the earlier discussion.

First of all, and most importantly, the issue seems to be at least
partly about K&R C, prior to it's first standardization. I think it's
pretty pointless to ask any questions at this level of detail about K&R
C. Prior to standardization, C was not a single coherent language, it
was many different languages, each with it's own subtle (and in some
cases, major) differences from the others. Questions about what it meant
should be of purely historical interest - unless, of course, you're
trying to cope with some legacy code written prior to standardization.
In that case, I can give you my most profound sympathy, but no useful
advice.

If the context of this discussion were at least advanced to C90, it
would become feasible to meaningfully discuss the issues. Unfortunately,
I could not address those issue in any detail, because I don't have a
copy of the C90 standard; it was too expensive when I needed it, and I
was more interested in C99 than C90 by the time the price dropped (and
my salary rose) to the point where I could afford to buy a copy of C90.

Secondly, this seems to be about the difference between

char *cptr;

and

char cptr[];

Thirdly, this seems to be about the difference in meaning of those
declarations when they appear in the parameter list of a non-prototyped
function definition, and when they appear at file scope. I'm assuming
that it's a non-prototyped function, because otherwise the ';' wouldn't
be allowed. I'm assuming that it's at file scope, because otherwise the
array declaration wouldn't be allowed.

I can give you C99 answers that I think are not significantly different
from those in C90, but I can't be at all sure they are the same as would
apply to pre-standard C.

Without having any declared size, the array declaration of cptr has an
incomplete type.

This would seem to be a problem, because 6.7p7 and 6.7.5.3p4 both
require such declarations to be complete. However, 6.7.5.3p7 says "A
declaration of a parameter as ‘‘array of type’’ shall be adjusted to
‘‘qualified pointer to type’’ ...", which is a complete type, and 6.7p7
and 6.7.5.3p4 both explicitly say that the requirement for completeness
applies only after such adjustment. Thus, in a parameter list both
declarations are equivalent. They're also equivalent to char cptr[255];,
a fact which can be confusing if you're expecting sizeof(cptr) to be 255
rather than sizeof(char*).

Section 6.7.5.3p4 applies only to parameter lists in function
definitions, and 6.7p7 doesn't apply to file scope declarations because
they always have linkage. Therefore, the incomplete array declaration is
a potential problem, but a solvable one.

Since it has file scope, no initializer, and no storage-class
specifier, it counts as a tentative definition (6.9.2p2). In some cases,
a tentative definition with no corresponding external definition ends up
being treated as the actual definition, with an implicit initializer of
0. However, that's not possible for a tentative definition of an object
with an incomplete type; the compiler doesn't have enough information to
know how much space to set aside for it. Therefore, an incomplete
tentative definition must be followed by another declaration of the same
identifier, which has at least one of the following features:

a) it defines the identifier as having a compatible complete type:

char cptr[255];

b) it declares the identifier to be 'extern', indicating that the actual
definition of the identifier, which must have a compatible complete
type, might be found in some other translation unit:

extern char cptr[];

Regardless of which approach you use, at file scope

char cptr[];

tentatively defines cptr as an array of char, with the actual definition
of that array to be provided elsewhere, while

char *cptr;

defines cptr to be a pointer to char.

David Thompson 11-03-2008 07:12 AM

Re: Banks and economy
 
On Wed, 22 Oct 2008 11:09:33 GMT, James Kuyper
<jameskuyper@verizon.net> wrote:

> s_dubrovich@yahoo.com wrote:
> [An awful lot of badly trimmed and confusing discussion]

<snip: about: char cptr []; >
> I can give you C99 answers that I think are not significantly different
> from those in C90, but I can't be at all sure they are the same as would
> apply to pre-standard C.
>
> Without having any declared size, the array declaration of cptr has an
> incomplete type.
>
> This would seem to be a problem, because 6.7p7 and 6.7.5.3p4 both
> require such declarations to be complete [after adjustment to pointer
> for parameter] and 6.7p7 doesn't apply to file scope declarations because
> they always have linkage. Therefore, the incomplete array declaration is
> a potential problem, but a solvable one.
>

Concur.

> Since it has file scope, no initializer, and no storage-class
> specifier, it counts as a tentative definition (6.9.2p2). In some cases,
> a tentative definition with no corresponding external definition ends up
> being treated as the actual definition, with an implicit initializer of


Formally it 'creates' a (nontentative) definition at the end of the
t.u. This produces the same result (same object) as if the tent-def
was treated as the definition, but using the size (e.g. sizeof cptr)
between the tent-def and the end of the t.u. doesn't work. (And
making it work with traditional one-pass-through-source compilers
would require clairvoyance or horrendous backpatching.)

> 0. However, that's not possible for a tentative definition of an object
> with an incomplete type; the compiler doesn't have enough information to
> know how much space to set aside for it. Therefore, an incomplete


Dissent. Although 6.9.2p2 doesn't quite say so, the initializer 'equal
to 0' is apparently actually {0} which is a valid initializer for an
array of 1 of any type, here char. 6.9.2p5 requires this, although it
is an example and thus formally nonnormative.

> tentative definition must be followed by another declaration of the same
> identifier, which has at least one of the following features:
>
> a) it defines the identifier as having a compatible complete type:
>
> char cptr[255];
>

This (also) works, but produces a different result.

> b) it declares the identifier to be 'extern', indicating that the actual
> definition of the identifier, which must have a compatible complete
> type, might be found in some other translation unit:
>
> extern char cptr[];
>

This doesn't work. Once you have a tentative definition you can't
'turn it off'. You must make _all_ declarations say 'extern' (and have
no initializer) in order to leave the object undefined in this t.u.

Similarly, if you declare 'static int foo;' and then later 'extern int
foo;' the internal linkage remains, it doesn't change to external.

> Regardless of which approach you use, at file scope
>
> char cptr[];
>
> tentatively defines cptr as an array of char, with the actual definition
> of that array to be provided elsewhere, while
>
> char *cptr;
>
> defines cptr to be a pointer to char.


This also is a tentative definition, of cptr as pointer to char; you
can have a subsequent real definition e.g.
char * cptr = &some_static_char_or_chars;
but if you don't then the tent-def 'creates' a real def like
char * cptr = 0 /* which is equivalent to NULL */ ;

- formerly david.thompson1 || achar(64) || worldnet.att.net


All times are GMT. The time now is 03:07 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.