strange warning

Discussion in 'C Programming' started by Bill Cunningham, May 10, 2014.

  1. I meant an application type. Its implementation in whatever primitive type
    construct the language provides would be irrelevant.

    If you wanted for some reason to represent the three r, g, b values of some
    image pixels as an array: char[3], and had a bunch of pixel-processing
    routines to work on such a type, would you bother to pass the 3 as an extra
    argument to each?[/QUOTE]

    What makes this newsgroup so much fun is how much at cross-purposes the
    two groups are. People like BartC & Malcolm are talking about taking trips
    to the market and such, while others like Kiki and his buddies just wanna
    talk about things like carburetors, cylinders, spark plugs, valves,
    pistons, and so on.

    And they want us to know, over and over and over again, just how many of
    each a typical engine has.
     
    Kenny McCormack, May 13, 2014
    1. Advertisements

  2. An excellent summary of CLC reg behavior.

    Definitely a keeper.

    As Han From China so adroitly pointed out, the first ones to start
    insulting people are always the regs - and then when people respond in
    kind, they act all hurt and complain about being insulted.
     
    Kenny McCormack, May 13, 2014
    1. Advertisements

  3. Bill Cunningham

    James Kuyper Guest

    That concept may in fact be useful, but it is not part of C as currently
    defined.
    In principle, yes, we do need it. C pointer arithmetic is defined in
    terms of an array, which is an object type; an object with no declared
    type and no effective type cannot have an array type - even though it's
    perfectly clear how that situation should be dealt with.

    That strikes me as a weakness in the current definition. I don't think
    it's ever likely to be a real-world problem, but the description of
    pointer arithmetic should be modified to be meaningful when applied to a
    pointer to an object that has no declared type, which has not yet
    acquired an effective type (or which has acquired one that is different
    from the pointed-at type).
    The behavior is undefined ".. by the omission of any explicit definition
    of behavior ..." (4p2). The only definition for the behavior of pointer
    arithmetic is in terms of positions in an array of objects of the
    pointed-at type, and the pointer points at a object which is not such an
    array, so that definition does not apply.
     
    James Kuyper, May 13, 2014
  4. I've muddied the waters by saying that if you declare

    int postcount[10]; /* number of posts user has made to each account */
    int Naccounts = 5; /* number of accounts held by user, note max 10 */

    and fill up the data somehow, you've got an array of five integers and a
    buffer of 10 integers.

    Usually you don't need to make that distinction because it's obvious from
    context which you mean, also because C doesn't make it - it's a higher
    level concept that doesn't map easily to C's way of doing things.
    In C++, however, people are usually very clear on the difference between
    vector::size() and vector::capacity().
     
    Malcolm McLean, May 13, 2014
  5. Bill Cunningham

    David Brown Guest

    No, that would not be making any sort of mistake.
    I don't think you are either stupid or inexperienced (nor do I think you
    think that of others), but I do think you don't pay due consideration to
    C outside your own little world.
    That is your view, and it is not unreasonable in many cases. It is also
    the view supported by the standards, as far as I can see. But the point
    is that this is not the /only/ view, and it is not necessarily the
    /best/ view. I gave a list of possibilities regarding strlen
    limitations - some are limits imposed due do practical limitations, and
    some are improvements over the standard version (when used in
    appropriate contexts).
    Sanity test, especially compile-time ones, are always a good idea.
    That's always true. There are several ways of handling such situations
    - good documentation and commenting, clear separation of the limiters
    and the implementation (such as putting the limits as #define's within
    the modules header, rather than buried in the implementation code), and
    being explicit about the limitations.

    But it is also worth remembering that for a lot of embedded code, the
    code is written for a specific purpose on specific hardware. The reason
    for the limitation never goes away, because it is part of the system.
    Maybe a project would have a strlen() function limited to 20 characters,
    because the screen only has space for 20 characters. When the "reason"
    goes away, you are using different hardware - it is a different system,
    and the code changes or is re-written to suit.

    There is always a balance between general, flexible, re-usable code and
    dedicated, constraint, efficient and specific code. Dedicated code is
    often the right choice.
     
    David Brown, May 13, 2014
  6. I was adding support for .puz files to my crossword program the other day.
    They store the width and height of the crossword as single bytes.

    Why, why, why, why why?

    It would be interesting to see how my grid-filling routines scale up.
    Pre-computer, it would have been totally impractical to print a
    crossword that big. But the university has acquired a "wall" of screens.
    They're intended for viewing medical images, but the temptation to
    put a giant crossword on it is there.
     
    Malcolm McLean, May 13, 2014
  7. Why do we have to do that? The point of the #define is to make the
    code clearer; without it, it's not obvious what a given instance of
    8 means. If there's no requirement for the code to deal with a width
    other than 8, why waste time implementing that unneeded flexibility?
    (In some cases it's going to be easier to write code that doesn't
    care what the specific value of CHESSBOARDWIDTH is, but in other
    cases it might not be.)
     
    Keith Thompson, May 13, 2014
  8. Bill Cunningham

    David Brown Guest

    The biggest surprise is that you have spent such a long time using terms
    in a way that made no sense to anyone else, rather than trying to get to
    the real issue.

    And yes, Ben, there are /many/ experienced programmers who write
    programs that use a fixed size rather than passing the size as a
    parameter. Referring to Malcolm's snakes and ladders program, there are
    plenty of situations where:

    void DoMove(SQUARE board[NSQUARES], int playerid, int diceroll);

    is a far better choice than:

    void DoMove(SQUARE *board, int Nsquares, int playerid, int diceroll);


    In most of my C programming, the first version is going to be the
    preference - the size of my boards are fixed at compile-time, so I want
    to take advantage of that knowledge to write source clearer code, get
    better compile-time checking, generate smaller and faster object code,
    and avoid any hint of dynamic memory allocation.
     
    David Brown, May 13, 2014
  9. Bill Cunningham

    David Brown Guest

    That's why static assertions were invented. (And they have existed for
    a long time - C11 just made them neater.) When your implementation code
    makes use of the assumption that CHESSBOARDWIDTH is 8, just write

    static_assert(CHESSBOARDWIDTH == 8, "The code currently supports 8x8
    chess boards only");
     
    David Brown, May 13, 2014
  10. I understand what Malcolm is talking about [*]. So, you claim of "anyone" is,
    of course, false.

    [*] And so would you if you got that stick out of your a**.

    --
    Modern Christian: Someone who can take time out from
    complaining about "welfare mothers popping out babies we
    have to feed" to complain about welfare mothers getting
    abortions that PREVENT more babies to be raised at public
    expense.
     
    Kenny McCormack, May 13, 2014
  11. The phrase "application type" doesn't make the distinction you're trying
    to make either. I think I understand what you're getting at, but you're
    not expressing it clearly.

    [...]
     
    Keith Thompson, May 13, 2014
  12. Yes, you have. Does that mean you're going to stop muddying the waters?
     
    Keith Thompson, May 13, 2014
  13. But that's not what I said! I write such programs too, but, generally,
    I try to write functions that don't know array sizes. If you actually
    find it a contentious claim, then we can agree to differ, but I'll note
    that I am a little surprised.

    (Maybe I expressed it badly. To me "generally" does not mean "almost
    always" or even "more often than not". It just means in the general
    case where there are no specifics that can alter what I consider a
    default choice.)
    Hmm. I don't follow some of these points. Parameterising the function
    by size does not, to me, hint at dynamic allocation, and I can't see why
    the code would be significantly clearer in either case. And I might be
    missing what you mean about better compile-time checking too, possibly
    by not having used compilers with the kind of checks you have in mind.

    As a result, the specific here would probably not cause me to change my
    default -- I go with what I do in general and add the size as a
    parameter -- but the compile-time checks might make me change my mind if
    I knew what they were.
     
    Ben Bacarisse, May 13, 2014
  14. Another failing grade handed down by Headmaster Kiki.

    How will you ever explain this to Mom?

    --
    (This discussion group is about C, ...)

    Wrong. It is only OCCASIONALLY a discussion group
    about C; mostly, like most "discussion" groups, it is
    off-topic Rorsharch [sic] revelations of the childhood
    traumas of the participants...
     
    Kenny McCormack, May 13, 2014
  15. Another failing grade handed down by Headmaster Kiki.

    How will you ever explain this to Mom?

    --
    Here's a simple test for Fox viewers:

    1) Sit back, close your eyes, and think (Yes, I know that's hard for you).
    2) Think about and imagine all of your ridiculous fantasies about Barack Obama.
    3) Now, imagine that he is white. Cogitate on how absurd your fantasies
    seem now.

    See? That wasn't hard, was it?
     
    Kenny McCormack, May 13, 2014
  16. The fact is that I can see where he's coming from. I can see the context
    from which he is speaking and how what he says makes sense in that context.

    Here's the thing: If, when you [rhetorical "you", not you specifically]
    read a post on Usenet, that doesn't make sense to you in your own context,
    if. instead of continuing to insist that your own context is the only
    possible one (and thus, responding accordingly, as Kiki and others do here),
    you made some effort to re-arrange your prejudices so that the post does
    make sense, you'll find two things to be true:

    1) Usenet will make a lot more sense.
    2) It will be a lot less fun.

    The "standards jockeys" here (and we know who they are, don't we...) are,
    of course, the worst in terms of absolutely refusing to ever even consider
    re-arranging their prejudices. This makes them, incidentally, good school
    masters, but little else...
    Indeed. Quite so.

    And another failing grade received from the committee above...

    --
    Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
    an 8 bit operating system based on a 4 bit architecture from a 2 bit company
    that can't stand 1 bit of competition.

    Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
    tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
    operating system based on a 4 bit architecture from a 2 bit company that
    can't stand 1 bit of competition.
     
    Kenny McCormack, May 13, 2014
  17. Bill Cunningham

    David Brown Guest

    Perhaps I misread, or misinterpreted you.
    I don't disagree (I certainly don't disagree about the functions /you/
    write!) - for lots of types of programming, you don't know the sizes at
    compile time. My point is that there are also lots of types of
    programming in which you /do/ know the sizes at compile time - or
    perhaps you know maximum sizes at compile time and want to fix that in
    the code.
    Parameterising the size does not /require/ dynamic allocation, but it
    often goes together. Dynamic allocation typically implies parameterized
    size, even though the opposite is not required.

    I feel that the version with the "SQUARE board[NSQUARES]" parameter is
    clearer because we are talking about an array of a specific size, not
    just a pointer to some SQUARE's somewhere. And the compiler may be able
    to check accesses to the array better, because it knows the size of the
    array. The information can also be used to generate more optimal code.

    But some of this is surely just personal preference. Perhaps because of
    the kind of work I do, I prefer to deal in more concrete and fixed
    objects - I am more comfortable with a fixed size data type than a more
    abstract pointer-to-something. Another effect is that debugging can
    often be easier, as the debugger can show the whole array sensibly.
    I don't think there would be much to be gained by compile-time checks or
    optimisations in this case, but sometimes there can be. For example, in
    the case of a chess board with N by N squares, checks could be made
    about the ranges and the knowledge that N is 8 (or whatever it is
    #define'd to) could easily lead to faster code for accessing the two
    dimensional array.
     
    David Brown, May 13, 2014
  18. Bill Cunningham

    James Kuyper Guest

    A C array with either automatic or allocated storage duration starts out
    uninitialized unless explicitly initialized or created by calloc(). I
    presume that when you say "contain data" you're not referring to the
    indeterminate values represented by uninitialized memory. Therefore,
    your definition of "array" is quite different from the one provided by
    the C standard.
    To avoid confusion, I'll refer to the things that you refer to as
    "arrays" as McLean-arrays.

    It just occurred to me to wonder: do you consider buffers and
    McLean-arrays to be conflicting or non-overlapping sets? Specifically,
    do you think that buffers cannot "be indexed in 0 constant time by an
    integer subscript"?
    Let's consider a version of C which was modified to "tighten up the
    distinction between a buffer and a [McLean-]array.". Does this mean that
    you would impose this rule only for McLean-arrays, and not for buffers?
    If so, what should happen when indexed a buffer with a negative value,
    or one >=N?
    If C were tightened up as you suggest, what distinctions should the
    standard make between the conversions allowed for pointers to buffers
    and pointers to McLean-arrays?
     
    James Kuyper, May 13, 2014
  19. As an aside, C99 allows the same information to be conveyed in the
    second case like so:

    void DoMove(SQUARE board[Nsquares], int Nsquares, int playerid, int diceroll);

    (This is particularly useful when dealing with 2D (and higher) arrays as
    the information enables you to index the arrays in a natural way.)

    <snip>
     
    Ben Bacarisse, May 13, 2014
  20. Bill Cunningham

    Ike Naar Guest

    Shouldn't 'int Nsquares' come before 'board[Nsquares]' in order for this
    to work? Like

    void DoMove(int Nsquares, SQUARE board[Nsquares], int playerid, int diceroll);
     
    Ike Naar, May 13, 2014
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.