Re: Banks and economy

Discussion in 'C Programming' started by s_dubrovich@yahoo.com, Oct 22, 2008.

  1. Guest

    On Oct 21, 9:58 am, Phil Carmody <>
    wrote:
    > writes:
    > > On Oct 19, 11:15 am, Phil Carmody <>
    > > wrote:
    > >> 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
     
    , Oct 22, 2008
    #1
    1. Advertising

  2. 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, wrote:
    > On Oct 21, 9:58 am, Phil Carmody <>
    > wrote:
    > > writes:
    > > > On Oct 19, 11:15 am, Phil Carmody <>
    > > > wrote:
    > > >> 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 :)
     
    Nick Keighley, Oct 22, 2008
    #2
    1. Advertising

  3. James Kuyper Guest

    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.
     
    James Kuyper, Oct 22, 2008
    #3
  4. On Wed, 22 Oct 2008 11:09:33 GMT, James Kuyper
    <> wrote:

    > 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
     
    David Thompson, Nov 3, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gordon Abbot
    Replies:
    12
    Views:
    638
    Jonathan N. Little
    Mar 1, 2006
  2. Replies:
    0
    Views:
    231
  3. Mikhail
    Replies:
    0
    Views:
    289
    Mikhail
    Jul 27, 2009
  4. Mikhail
    Replies:
    0
    Views:
    334
    Mikhail
    Jul 27, 2009
  5. Replies:
    2
    Views:
    118
Loading...

Share This Page