strange warning

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

  1. Then he could have made that point rather than claiming that "C does not
    have arrays".

    C arrays, unlike arrays in many other languages, are built on top of
    lower-level constructs, and yes, those concepts often show through.
    I don't claim that C's design is ideal, but C absolutely does have
    arrays (though not as, in some sense, first-class types).
     
    Keith Thompson, May 11, 2014
    #41
    1. Advertisements

  2. I"m not sure what you mean by "If we only had something that works like
    calloc". We do have calloc.

    Yes, C really does need arrays. Fortunately, it has them.
     
    Keith Thompson, May 11, 2014
    #42
    1. Advertisements

  3. Bill Cunningham

    David Brown Guest

    n1570 is a popular document because it was the last draft standard of
    C11 before the final standard was made. There is (as far as I know)
    almost no difference between n1570 and the real C11 standard, except
    that n1570 is freely (legally) available on the web, while you have to
    pay for the real standard. Thus people use n1570 rather than buying the
    C11 standard. I don't know if there is an equivalent for a good draft
    of C99 that is available as easily, but I'm sure someone will let us
    know if there is.

    There is no difference in this sort of area between C11 and C99, so
    n1570 is a fine reference here.

    As for gcc's C11 support, look at: <http://gcc.gnu.org/wiki/C11Status>
    for a summary. Also look at
    <http://en.wikipedia.org/wiki/C11_(C_standard_revision)> for the
    differences between C99 and C11. In my view, there is not a lot to get
    excited about - static assertions are nice, and atomic variables /may/
    be useful depending on how they are implemented.
     
    David Brown, May 11, 2014
    #43
  4. n1256.pdf

    <snip>
     
    Ben Bacarisse, May 11, 2014
    #44
  5. "Yes", "they are". ;-)
     
    Ben Bacarisse, May 11, 2014
    #45
  6. N1256 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>
    is a freely available draft that contains the official C99 standard
    with the three Technical Corrigenda merged into it. It was published
    after the release of the C99 standard, unlike N1570, which was
    published before the release of the C11 standard. N1256 is, for
    most purposes, actually more useful than the official C99 standard.
    (The three Technical Corrigenda are available at no charge.)

    Larry Jones, a commitee member, posted a summary of the differences
    between N1570 and C11 last year in comp.std.c:

    There are a number of them, but most are just minor editorial
    tweaks, changes to boilerplate text, and shuffling things around
    to keep the powers that be happy. The biggest change was removing
    _Alignof from a bunch of places it shouldn't have been added
    (based on the erroneous notion that it takes either a type or an
    expression like sizeof does when it really only takes a type):
    6.3.2.1p2, p3, p4, fn. 65; and 6.7.1 fn. 121.

    N1570 failed to specify values for the __STDC_VERSION__ and
    __STDC_LIB_EXT1__ macros. The released C11 standard did not correct
    these errors. They were corrected in the first (and, so far, only)
    Technical Corrigendum; both expand to 201112L.
    Standard support for threading could be useful, but so far I'm not aware
    of any C11 implementations that don't already support POSIX threads.
     
    Keith Thompson, May 11, 2014
    #46
  7. When a function doesn't make any calls to IO routines, and scales in
    N, then that releases something. All we need is a universal language for
    specifying the input and output or such algorithms, and the manipulations
    they perform, and we've created something permanent and as useful for
    as long as the specification matches something in the real world.

    That's real programming. I'm not saying you will never use a fixed-length
    array. But they're not so common and usually a sign that you've coded
    the algorithm incorrectly.
     
    Malcolm McLean, May 11, 2014
    #47
  8. Bill Cunningham

    Ian Collins Guest

    Algorithms often have to work with physical or other externally defined
    fixed sized entities. Probably >50% of the code I write is dealing with
    these fixed sized things. Am I coding incorrectly?
     
    Ian Collins, May 12, 2014
    #48
  9. Bill Cunningham

    David Brown Guest

    For my own part, over 80% of the code I write deals with fixed sizes
    (and most of the code I write that doesn't have fixed sizes is written
    in Python rather than C).

    For smaller embedded systems, fixed sizes are definitely the norm -
    malloc and other dynamic allocations (such as VLA) are shunned, or
    banned outright by many coding standards.

    Of course, such small embedded systems are only one area of C
    programming. But as higher level languages take more of a share of "big
    system" programming and there is more and more embedded programming
    being done, a larger proportion of C programming is embedded.
     
    David Brown, May 12, 2014
    #49
  10. It's a sign that you're not using very rigourous methods, but only a
    sign. There's often a conflict between micro-efficiency and good design,
    and you don't always want to resolve it in favour of good design.

    Then if the algorithms are essentially trivial then it matters a lot less
    about porting them. I've just spent about two months on a single function,
    for example. Obviously we don't want to spend another two months taking
    out all the non-general assumptions if the company decide to target a
    new platform. If the algorithm is just "step through the array and get
    the closest value to x" then that takes only a few minutes to write,
    it's much less important to make sure you pass in N as a parameter.
    Would saving couple of bytes of stack space actually make the fixed
    method better? Well, sometimes. It just depends on the situation.
     
    Malcolm McLean, May 12, 2014
    #50
  11. Bill Cunningham

    Ian Collins Guest

    I was going to replay saying that Malcolm tends to trivialise the kind
    of work we do, but I see He has already done so in his reply to my post.
     
    Ian Collins, May 12, 2014
    #51
  12. Bill Cunningham

    Ian Collins Guest

    Hello, real world calling...

    So when using the fixed sizes defined by my system's headers for the
    kernel data structures I am processing I'm micro-optimising? Give me a
    break.
     
    Ian Collins, May 12, 2014
    #52
  13. Bill Cunningham

    Noob Guest

    You might be thinking of this kind of definition:

    char *s1 = "abcdefg";

    Contrast with

    char s2[] = "abcdefg";

    Regards.
     
    Noob, May 12, 2014
    #53
  14. The person who wrote the kernel headers has decided to define the interface
    as raw structures and a fixed size, abstracted a bit by a hash define.

    A clear case of micro-optimisation. But not necessarily a bad decision, given the
    limitations of current systems, or maybe the fact that the kernel is a legacy
    system that has been continuously developed back from the days when 640k
    was enough for anybody.
    You then use N directly instead of reading it at one place then passing it to
    every subroutine. Another clear case of micro-optimisation. Maybe defensible,
    "micro-optimisation" has a technical meaning, it doesn't mean "optimisation
    that gains only a bit a run time".
    There's also the issue of keeping interfaces clean. That's a issue with C, largely
    solved by the use of structures, but not entirely. The basic strategy is to
    populate a structure with pointers to the kernel data structures and their sizes,
    the pass it to the subroutines to take out the dependencies on the fixed structures.
    So we can then reuse the code if the kernel interface changes other than by
    adding or subtracting an entry from a structure array. But again, that's not
    necessarily worth doing, largely for micro efficiency reasons, but also because
    you're maybe making the interfaces harder to document and use. You have to
    look at every situation, there are general principles, but it's not as simple as
    blindly applying a rule.
     
    Malcolm McLean, May 12, 2014
    #54
  15. Bill Cunningham

    Ian Collins Guest

    Or an enum.
    No it isn't. It's a sign of an environment where dynamic allocation is
    frowned upon or even banned.

    Regardless of the motivation, my original point that fixed arrays are
    widely used in real world code still holds.
     
    Ian Collins, May 12, 2014
    #55
  16. Lets explain further.

    We've got this situation

    typedef struct
    {
    int a;
    int b;
    } KERNELSTRUCTURE;

    #define NKERNELSTRUCTS 10

    KERNELSTRUCTURE kernelstructs[10]; /* writing to these structures has side effects ! */

    So how do we handle it?

    typedef struct
    {
    int N;
    KERNELSTRUCTURE *kernel; /*the bits that manipulate the kernel */
    KERNELSTRUCTURE *copy; /* what we'll be reading and writing from */
    bool *dirty; /* possibly keep track of dirty structures */
    } ABSTRACTION;


    Then we set one up by reading the kernel at program start.
    Then we pass an ABSTRACTION * to all out subroutines. So what we've done is we've converted
    the subroutines from IO routines, which have side-effects, to pure bit-shuffling functions. All
    they're doing is shuffling bits about in copy.
    The we have one function.

    void synch(ABSTACTION *abs)
    {
    /* go through updating dirty kernel entries */
    /* maybe you also need to read the kernel again */
    }

    That's the one place we update the kernel, it's the only function which can have any side
    effects.

    What's the advantage? Well now we've decoupled testing and debugging from the
    particular kernel. We run our subroutines on a UNIX box and verify that for every kernel
    state we're interested in, they put copy into the correct state. All the bit shuffling is
    correct.
    It simply remains to hook up sync to a real kernel on real hardware.

    Now of course you can have all sorts of problems, such as needing to update the
    kernel and get back a result from the system immediately. There might not be
    time to go all the way back up the call tree, call synch, then go back down again to
    process the answer. This design is not a magic bullet which can be blindly applied.

    But it's the sort of thing I'm talking about.

    And you think I don't "live in the real world?".
     
    Malcolm McLean, May 12, 2014
    #56
  17. Seeing a CLC reg telling *anyone* *anything* about "the real world" is a
    screamer in and of itself.

    (Something about glass houses...)
     
    Kenny McCormack, May 12, 2014
    #57
  18. Ian does live in the real world. But he's a bit like a car mechanic who's been on
    lots of courses, and has twenty years' experience, and knows exactly what type
    of brake pad you need to fit on the Ford Fiesta and why the fuel lines on the
    Mini Cooper can be a bit dodgy. So he thinks he knows everything there is to
    know about cars.
     
    Malcolm McLean, May 12, 2014
    #58
  19. Bill Cunningham

    Ian Collins Guest

    Bullshit. But do know what, and how useful, a fixed length array is.
     
    Ian Collins, May 12, 2014
    #59
  20. Bill Cunningham

    James Kuyper Guest

    I think he means "if calloc() were the only available way to dynamically
    allocate memory". Possibly, he might also be talking about a
    hypothetical language in which arrays could not be declared, so that
    dynamically allocating memory was the only way to create a pointer to
    two or more consecutive objects of a single type.
     
    James Kuyper, May 12, 2014
    #60
    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.