Re: dereferencing void *

Discussion in 'C Programming' started by Dan Pop, Jul 7, 2003.

  1. Dan Pop

    Dan Pop Guest

    In <bebevq$p67$> "Jun Woong" <> writes:

    >A diagnostic is not required, and at least in C90, if the
    >implementation fails to translate or execute a probram just because it
    >contains dereferencing a void *, then it's not conforming, which is
    >completely different from your position.


    Chapter and verse, please. AFAICT, the implementation can fail to
    translate or execute *any* program (except the one mentioned in 5.2.4.1)
    without having its conformance affected.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 7, 2003
    #1
    1. Advertising

  2. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bebm6p$271$...
    > In <bebevq$p67$> "Jun Woong" <> writes:
    >
    > >A diagnostic is not required, and at least in C90, if the
    > >implementation fails to translate or execute a probram just because it
    > >contains dereferencing a void *, then it's not conforming, which is
    > >completely different from your position.

    >
    > Chapter and verse, please. AFAICT, the implementation can fail to
    > translate or execute *any* program (except the one mentioned in 5.2.4.1)
    > without having its conformance affected.
    >


    The "rubber teeth" problem which is the reason I said "just because"
    instead of "because" to mean "with only a reason that ..."


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 7, 2003
    #2
    1. Advertising

  3. Dan Pop

    Dan Pop Guest

    In <bebmkb$1qk$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bebm6p$271$...
    >> In <bebevq$p67$> "Jun Woong" <> writes:
    >>
    >> >A diagnostic is not required, and at least in C90, if the
    >> >implementation fails to translate or execute a probram just because it
    >> >contains dereferencing a void *, then it's not conforming, which is
    >> >completely different from your position.

    >>
    >> Chapter and verse, please. AFAICT, the implementation can fail to
    >> translate or execute *any* program (except the one mentioned in 5.2.4.1)
    >> without having its conformance affected.

    >
    >The "rubber teeth" problem which is the reason I said "just because"
    >instead of "because" to mean "with only a reason that ..."


    Would it be possible to get a coherent/meaningful reply?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 7, 2003
    #3
  4. On 7 Jul 2003 13:11:39 GMT, (Dan Pop) wrote:

    >In <bebmkb$1qk$> "Jun Woong" <> writes:
    >
    >
    >>"Dan Pop" <> wrote in message news:bebm6p$271$...
    >>> In <bebevq$p67$> "Jun Woong" <> writes:
    >>>
    >>> >A diagnostic is not required, and at least in C90, if the
    >>> >implementation fails to translate or execute a probram just because it
    >>> >contains dereferencing a void *, then it's not conforming, which is
    >>> >completely different from your position.
    >>>
    >>> Chapter and verse, please. AFAICT, the implementation can fail to
    >>> translate or execute *any* program (except the one mentioned in 5.2.4.1)
    >>> without having its conformance affected.

    >>
    >>The "rubber teeth" problem which is the reason I said "just because"
    >>instead of "because" to mean "with only a reason that ..."

    >
    >Would it be possible to get a coherent/meaningful reply?


    I am not sure what Jun is writing about either, but I thought that a
    conforming implementation had to accept any strictly conforming
    program (see subclause 4, paragraph 6). There are differences
    between hosted and freestanding, but let's not get lost in those
    details.

    So an implementation cannot be considered conforming if it fails to
    accept a strictly conforming program. Any other program that the
    implementation accepts would be considered a conforming program. But
    the implementation does not have to accept programs that are not
    strictly conforming.

    Best wishes,

    Bob
     
    Robert W Hand, Jul 7, 2003
    #4
  5. Dan Pop

    Dan Pop Guest

    In <bec04f$ck3$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bebrib$kf2$...
    >> In <bebmkb$1qk$> "Jun Woong" <> writes:
    >>
    >>
    >> >"Dan Pop" <> wrote in message news:bebm6p$271$...
    >> >> In <bebevq$p67$> "Jun Woong" <> writes:
    >> >>
    >> >> >A diagnostic is not required, and at least in C90, if the
    >> >> >implementation fails to translate or execute a probram just because it
    >> >> >contains dereferencing a void *, then it's not conforming, which is
    >> >> >completely different from your position.
    >> >>
    >> >> Chapter and verse, please. AFAICT, the implementation can fail to
    >> >> translate or execute *any* program (except the one mentioned in 5.2.4.1)
    >> >> without having its conformance affected.
    >> >
    >> >The "rubber teeth" problem which is the reason I said "just because"
    >> >instead of "because" to mean "with only a reason that ..."

    >>
    >> Would it be possible to get a coherent/meaningful reply?

    >
    >You are talking about the "rubber teeth" and the interpretation of "to
    >accept" with that "the implementation can fail to translate or execute
    >*any* program ..."


    Right.

    >What I meant is about the intent,


    What is the intent of 5.2.4.1?

    >giving the
    >practical and more restrictive interpretation to the term "accept," in


    By that interpretation, there is NO conforming C implementation at all,
    because, for any given implementation, it is possible to produce a
    strictly conforming program that cannot be translated and executed, due
    to lack of resources.

    >order to emphasize that dereferencing a void pointer inself is not an
    >illegal construct.


    All you had to say is that dereferencing a void pointer doesn't invoke
    undefined behaviour and doesn't require a diagnostic. The reason being
    that the standard allows expressions of type void (e.g. calling free()).

    >Which is the reason I wrote "just because."


    Which is misleading in the extreme.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 7, 2003
    #5
  6. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bec1bv$5k7$...
    > In <bec04f$ck3$> "Jun Woong" <> writes:

    [...]
    >
    > >What I meant is about the intent,

    >
    > What is the intent of 5.2.4.1?


    Check up the Rationale.

    >
    > >giving the
    > >practical and more restrictive interpretation to the term "accept," in

    >
    > By that interpretation, there is NO conforming C implementation at all,
    > because, for any given implementation, it is possible to produce a
    > strictly conforming program that cannot be translated and executed, due
    > to lack of resources.


    Two extremes to interpret the committee's intent for conformance.

    > >Which is the reason I wrote "just because."

    >
    > Which is misleading in the extreme.
    >


    Okay, I should have written my intention in detail or in a different
    way.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 7, 2003
    #6
  7. Dan Pop

    Dan Pop Guest

    In <bec3h6$hh9$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bec1bv$5k7$...
    >> In <bec04f$ck3$> "Jun Woong" <> writes:

    >[...]
    >>
    >> >What I meant is about the intent,

    >>
    >> What is the intent of 5.2.4.1?

    >
    >Check up the Rationale.


    It was a rhetorical question? ;-)

    >> >giving the
    >> >practical and more restrictive interpretation to the term "accept," in

    >>
    >> By that interpretation, there is NO conforming C implementation at all,
    >> because, for any given implementation, it is possible to produce a
    >> strictly conforming program that cannot be translated and executed, due
    >> to lack of resources.

    >
    >Two extremes to interpret the committee's intent for conformance.


    I have no clue about the committee's intent for conformance (and I doubt
    the committee members themselves have). All I have is the text of the
    standard and this text is severely broken in this area: 5.2.4.1 can be
    trivially satisifed by any piece of junk and 4p6 cannot be satisfied by
    any implementation (for any reasonable definition of "accept").

    When I claimed that the current situation could be trivially fixed by
    adding a few more translation limits, PJ Plauger told me that I'm a fool
    (or words to that effect). Nevertheless, I continue to believe that
    5.2.4.1 can be fixed this way (add a limit for the source code size,
    one for the total amount of statically allocated data and one for the
    total amount of automatically allocated data and you can meaningfully
    request that *any* correct program not exceeding these limits is
    translated and executed).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 7, 2003
    #7
  8. Dan Pop

    Kevin Easton Guest

    Dan Pop <> wrote:
    > In <bec04f$ck3$> "Jun Woong" <> writes:

    [...]
    >>giving the
    >>practical and more restrictive interpretation to the term "accept," in

    >
    > By that interpretation, there is NO conforming C implementation at all,
    > because, for any given implementation, it is possible to produce a
    > strictly conforming program that cannot be translated and executed, due
    > to lack of resources.


    It's even possible for the abstract machine itself, because
    sizeof(int *) * CHAR_BIT creates an upper bound on the number of distinct
    int objects that may be created.

    - Kevin.
     
    Kevin Easton, Jul 8, 2003
    #8
  9. Dan Pop

    Kevin Easton Guest

    Tom St Denis <> wrote:
    > Kevin Easton wrote:
    >> Dan Pop <> wrote:
    >>
    >>>In <bec04f$ck3$> "Jun Woong" <> writes:

    >>
    >> [...]
    >>
    >>>>giving the
    >>>>practical and more restrictive interpretation to the term "accept," in
    >>>
    >>>By that interpretation, there is NO conforming C implementation at all,
    >>>because, for any given implementation, it is possible to produce a
    >>>strictly conforming program that cannot be translated and executed, due
    >>>to lack of resources.

    >>
    >>
    >> It's even possible for the abstract machine itself, because
    >> sizeof(int *) * CHAR_BIT creates an upper bound on the number of distinct
    >> int objects that may be created.

    >
    > I don't think thats true. Say you have a 32-bit address than by your
    > logic you could make 2^32 ints [say int == 32 bits] but thats 16GB of
    > memory [34 bit address space].


    It's perfectly possible for a 32bit (int *) to address 16GB of integers
    - you just need to require that integers be aligned on 4-byte
    boundaries, and then the bottom two bits of an integer address is always
    00, so the 32 bit (int *) is holding the upper 32 bits of a 34 bit
    address.

    But that doesn't matter anyway, because I said "upper bound".

    - Kevin.
     
    Kevin Easton, Jul 8, 2003
    #9
  10. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bec7nh$ius$...
    > In <bec3h6$hh9$> "Jun Woong" <> writes:
    > >"Dan Pop" <> wrote in message news:bec1bv$5k7$...
    > >>
    > >> What is the intent of 5.2.4.1?

    > >
    > >Check up the Rationale.

    >
    > It was a rhetorical question? ;-)


    The Rationale explains the committee's intent of the subclause; it's
    not that I'm claiming that every conforming implementation must follow
    the intent to conform the standard, but I'm just talking about a
    reasonable implementation whose quality is good enough.

    [...]
    >
    > When I claimed that the current situation could be trivially fixed by
    > adding a few more translation limits, PJ Plauger told me that I'm a fool
    > (or words to that effect). Nevertheless, I continue to believe that
    > 5.2.4.1 can be fixed this way (add a limit for the source code size,
    > one for the total amount of statically allocated data and one for the
    > total amount of automatically allocated data and you can meaningfully
    > request that *any* correct program not exceeding these limits is
    > translated and executed).
    >


    I think it's very hard to prescribe the complete set of limits which
    all conforming implementations in different environments each of which
    imposes various restrictions can meet; even if it's possible, lots of
    interpretation problems would be raised after it's done. Personally,
    I'm satisfied with that the market forces make things work well in
    this area.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 8, 2003
    #10
  11. Dan Pop

    Dan Pop Guest

    In <bedlin$oo0$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:bec7nh$ius$...
    >> In <bec3h6$hh9$> "Jun Woong" <> writes:
    >> >"Dan Pop" <> wrote in message news:bec1bv$5k7$...
    >> >>
    >> >> What is the intent of 5.2.4.1?
    >> >
    >> >Check up the Rationale.

    >>
    >> It was a rhetorical question? ;-)

    >
    >The Rationale explains the committee's intent of the subclause; it's
    >not that I'm claiming that every conforming implementation must follow
    >the intent to conform the standard, but I'm just talking about a
    >reasonable implementation whose quality is good enough.


    What would be a reasonable interpretation of 5.2.4.1?

    >> When I claimed that the current situation could be trivially fixed by
    >> adding a few more translation limits, PJ Plauger told me that I'm a fool
    >> (or words to that effect). Nevertheless, I continue to believe that
    >> 5.2.4.1 can be fixed this way (add a limit for the source code size,
    >> one for the total amount of statically allocated data and one for the
    >> total amount of automatically allocated data and you can meaningfully
    >> request that *any* correct program not exceeding these limits is
    >> translated and executed).
    >>

    >
    >I think it's very hard to prescribe the complete set of limits which
    >all conforming implementations in different environments each of which
    >imposes various restrictions can meet;


    Why? Make those limits small enough and everything should be OK.

    >even if it's possible, lots of
    >interpretation problems would be raised after it's done.


    ???

    >Personally,
    >I'm satisfied with that the market forces make things work well in
    >this area.


    This is a lame excuse for leaving such a huge loophole in the standard.
    If a vendor doesn't want to fix a bug, he can still claim conformance.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 8, 2003
    #11
  12. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:beeqt2$6c5$...
    > In <bedlin$oo0$> "Jun Woong" <> writes:

    [...]
    > >
    > >The Rationale explains the committee's intent of the subclause; it's
    > >not that I'm claiming that every conforming implementation must follow
    > >the intent to conform the standard, but I'm just talking about a
    > >reasonable implementation whose quality is good enough.

    >
    > What would be a reasonable interpretation of 5.2.4.1?


    The reasonable interpretation you think can differ from mine or the
    intent of the committee. The only thing we should agree is its literal
    interpretation.

    > >
    > >I think it's very hard to prescribe the complete set of limits which
    > >all conforming implementations in different environments each of which
    > >imposes various restrictions can meet;

    >
    > Why? Make those limits small enough and everything should be OK.


    Try to submit your proposal to the committee.

    >
    > This is a lame excuse for leaving such a huge loophole in the standard.
    > If a vendor doesn't want to fix a bug, he can still claim conformance.
    >


    Don't you understand what the market forces mean? If the vendor think
    that the standard's requirement is too hard to meet, it can simply
    give up the conformance - the standard has no legal force to make
    implementations conform to it.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 9, 2003
    #12
  13. Dan Pop

    Dan Pop Guest

    In <beg4ho$sii$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:beeqt2$6c5$...
    >> In <bedlin$oo0$> "Jun Woong" <> writes:

    >[...]
    >> >
    >> >I think it's very hard to prescribe the complete set of limits which
    >> >all conforming implementations in different environments each of which
    >> >imposes various restrictions can meet;

    >>
    >> Why? Make those limits small enough and everything should be OK.

    >
    >Try to submit your proposal to the committee.


    Why should I waste my time? If they decided their version is good enough
    nothing would change their minds.

    >> This is a lame excuse for leaving such a huge loophole in the standard.
    >> If a vendor doesn't want to fix a bug, he can still claim conformance.

    >
    >Don't you understand what the market forces mean?


    Much better than you.

    >If the vendor think
    >that the standard's requirement is too hard to meet, it can simply
    >give up the conformance - the standard has no legal force to make
    >implementations conform to it.


    That's where the market forces come into play. If the vendor is unable
    to claim conformance to the standard adopted by the market, people
    will look elsewhere. Right now, any implementation, no matter how
    broken, can claim conformance, misleading the potential customer.

    BTW, if C99 is still a pipe dream in the real world, it's also due
    to the market forces.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 9, 2003
    #13
  14. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:begnlj$kq9$...
    > In <beg4ho$sii$> "Jun Woong" <> writes:

    [...]
    > >If the vendor think
    > >that the standard's requirement is too hard to meet, it can simply
    > >give up the conformance - the standard has no legal force to make
    > >implementations conform to it.

    >
    > That's where the market forces come into play. If the vendor is unable
    > to claim conformance to the standard adopted by the market, people
    > will look elsewhere. Right now, any implementation, no matter how
    > broken, can claim conformance, misleading the potential customer.


    It sounds resonable. But, AFAICT the "rubber teeth" was adopted for a
    political reason in order to compromise with the various restrictions
    of the real world. As always, you keep claiming that a part of the
    stadard is simply broken without showing any fragment of your concrete
    proposal to fix it in a formal form; should I dig out a past
    discussion again to see it which might be really foolish one? If you
    really think you can improve it, then please share it with the
    committee members. Or if you think it makes you waste time to do so,
    I'll quit this discussion in order to save my time.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 9, 2003
    #14
  15. Dan Pop

    Dan Pop Guest

    In <begvp1$hap$> "Jun Woong" <> writes:


    >"Dan Pop" <> wrote in message news:begnlj$kq9$...
    >> In <beg4ho$sii$> "Jun Woong" <> writes:

    >[...]
    >> >If the vendor think
    >> >that the standard's requirement is too hard to meet, it can simply
    >> >give up the conformance - the standard has no legal force to make
    >> >implementations conform to it.

    >>
    >> That's where the market forces come into play. If the vendor is unable
    >> to claim conformance to the standard adopted by the market, people
    >> will look elsewhere. Right now, any implementation, no matter how
    >> broken, can claim conformance, misleading the potential customer.

    >
    >It sounds resonable. But, AFAICT the "rubber teeth" was adopted for a
    >political reason in order to compromise with the various restrictions
    >of the real world. As always, you keep claiming that a part of the
    >stadard is simply broken without showing any fragment of your concrete
    >proposal to fix it in a formal form;


    I have given you a fairly precise outline of my proposal, upthread.
    Why should I bother rewriting it in standardese, since the idea is
    exactly the same? Are you unable to read plain English or what?

    The exact values in my proposal are not important, they can be as small
    as the most conservative committee member wants.

    >should I dig out a past
    >discussion again to see it which might be really foolish one? If you
    >really think you can improve it, then please share it with the
    >committee members.


    As I've said, I have better uses for my time. The committee members have
    already said that the text is good enough for them, which basically means
    that they would automatically turn down any suggestion.

    >Or if you think it makes you waste time to do so,
    >I'll quit this discussion in order to save my time.


    I have already explained *why* it would be a waste of time, both upthread
    and in this post. Feel free to quit this discussion any time you wish.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 9, 2003
    #15
  16. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:behipg$4jn$...
    > In <begvp1$hap$> "Jun Woong" <> writes:

    [...]
    > >
    > >It sounds resonable. But, AFAICT the "rubber teeth" was adopted for a
    > >political reason in order to compromise with the various restrictions
    > >of the real world. As always, you keep claiming that a part of the
    > >stadard is simply broken without showing any fragment of your concrete
    > >proposal to fix it in a formal form;

    >
    > I have given you a fairly precise outline of my proposal, upthread.


    To add more items to the "rubber teeth", rewrite some of them to relax
    restrictions and guarantee a subset of strictly conforming programs
    which are reasonably small to be translated and executed successfully
    in any conforming implementation?

    > Why should I bother rewriting it in standardese, since the idea is
    > exactly the same? Are you unable to read plain English or what?


    A formal and concrete proposal is likely to make it easier to find
    a problem in it, or to be more persuasive if no problem in it. A
    proposal like yours has been raised before (in csc? I don't recall),
    but the consequence was that it wasn't perfect enough to make the
    committee rewrite the text becuase it was possible to write a program
    which abuses holes of the proposal to press the physical limits of an
    implementation. Even if I'm satisfied with the current state because
    of the market forces work well until now, but it's not that I'm very
    happy with it.

    >
    > >should I dig out a past
    > >discussion again to see it which might be really foolish one? If you
    > >really think you can improve it, then please share it with the
    > >committee members.

    >
    > As I've said, I have better uses for my time. The committee members have
    > already said that the text is good enough for them, which basically means
    > that they would automatically turn down any suggestion.


    Complaining without tries changes anything.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 10, 2003
    #16
  17. Dan Pop

    Jun Woong Guest

    "Kevin Easton" <> wrote in message news:newscache$m7zshh$nj3$...
    > Jun Woong <> wrote:

    [...]
    > >
    > > A formal and concrete proposal is likely to make it easier to find
    > > a problem in it, or to be more persuasive if no problem in it. A
    > > proposal like yours has been raised before (in csc? I don't recall),
    > > but the consequence was that it wasn't perfect enough to make the
    > > committee rewrite the text becuase it was possible to write a program
    > > which abuses holes of the proposal to press the physical limits of an
    > > implementation. Even if I'm satisfied with the current state because
    > > of the market forces work well until now, but it's not that I'm very
    > > happy with it.

    >
    > If we just look at "stack space" limits, it's obviously pretty easy to
    > say "The program shall never have more than 50 functions simultaneously
    > executing.", but how do you specify limits on the total amount of
    > automatic objects? You clearly can't specify it in terms of bytes,
    > because then a program can't be shown to conform to the limits in
    > isolation, only on a particular implementation. It seems like you would
    > have to do something like:
    >
    > * All types other than struct, array or union types have a type-weight
    > of 1.
    >
    > * The weight of a union type is the weight of it's heaviest member.
    >
    > * The weight of a struct or array type is the sum of the weights of its
    > members.
    >
    > * No program shall have, at any point in it's execution, automatic
    > objects with overlapping lifetimes with a total type-weight of more
    > than 10,000.
    >
    > (Probably with lower numbers for freestanding implementations).
    >
    > You would have to take into account the fact that the test program
    > could go almost to the limit, and then call a standard library function
    > - so the limits would have to be formulated taking into account the
    > worst-case standard library call, which might be quite bad for some of
    > the stdio functions.
    >


    Agreed. That's what I keep saying in my previous postings. It was
    always possible to devise a program to press the physical limits of
    a feasible implementation, not exceeding limits specified in a
    proposed "rubber teeth." It's never easy to rewrite it to content
    every implementer and user.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 10, 2003
    #17
  18. Dan Pop

    Dan Pop Guest

    In <newscache$m7zshh$nj3$> Kevin Easton <> writes:

    >If we just look at "stack space" limits, it's obviously pretty easy to
    >say "The program shall never have more than 50 functions simultaneously
    >executing.", but how do you specify limits on the total amount of
    >automatic objects? You clearly can't specify it in terms of bytes,
    >because then a program can't be shown to conform to the limits in
    >isolation, only on a particular implementation.


    And what's wrong with that? An implementation is only required to deal
    with the programs not exceeding the limits on that implementation.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 10, 2003
    #18
  19. Dan Pop

    Kevin Easton Guest

    Dan Pop <> wrote:
    > In <newscache$m7zshh$nj3$> Kevin Easton <> writes:
    >
    >>If we just look at "stack space" limits, it's obviously pretty easy to
    >>say "The program shall never have more than 50 functions simultaneously
    >>executing.", but how do you specify limits on the total amount of
    >>automatic objects? You clearly can't specify it in terms of bytes,
    >>because then a program can't be shown to conform to the limits in
    >>isolation, only on a particular implementation.

    >
    > And what's wrong with that? An implementation is only required to deal
    > with the programs not exceeding the limits on that implementation.


    It would seem to me to be useful to be able to point to a particular
    class of programs and say "all conforming implementations must accept
    and correctly translate these programs".

    There is also the issue of padding to consider (I believe some
    implementations pad out automatic variables to a particular
    multiple of sizeof(char), so a simple summation of the sizeof all
    automatic variables with overlapping lifetimes won't suffice).

    - Kevin.
     
    Kevin Easton, Jul 10, 2003
    #19
  20. Dan Pop

    Jun Woong Guest

    "Dan Pop" <> wrote in message news:bejs4n$ra0$...
    > In <newscache$m7zshh$nj3$> Kevin Easton <> writes:
    >
    > >If we just look at "stack space" limits, it's obviously pretty easy to
    > >say "The program shall never have more than 50 functions simultaneously
    > >executing.", but how do you specify limits on the total amount of
    > >automatic objects? You clearly can't specify it in terms of bytes,
    > >because then a program can't be shown to conform to the limits in
    > >isolation, only on a particular implementation.

    >
    > And what's wrong with that? An implementation is only required to deal
    > with the programs not exceeding the limits on that implementation.
    >


    What difference this makes from the current state of the standard?
    An implementation is allowed to fail to translate or execute a very
    simple program just because it exceeds the limits on that
    implementation.


    --
    Jun, Woong ()
    Dept. of Physics, Univ. of Seoul
     
    Jun Woong, Jul 10, 2003
    #20
    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. Ollej Reemt
    Replies:
    7
    Views:
    602
    Jack Klein
    Apr 22, 2005
  2. Jun Woong

    Re: dereferencing void *

    Jun Woong, Jul 6, 2003, in forum: C Programming
    Replies:
    0
    Views:
    385
    Jun Woong
    Jul 6, 2003
  3. Stig Brautaset

    `void **' revisited: void *pop(void **root)

    Stig Brautaset, Oct 25, 2003, in forum: C Programming
    Replies:
    15
    Views:
    836
    The Real OS/2 Guy
    Oct 28, 2003
  4. Replies:
    5
    Views:
    881
    S.Tobias
    Jul 22, 2005
  5. Replies:
    1
    Views:
    435
    Victor Bazarov
    May 23, 2007
Loading...

Share This Page