Re: Are bad developer libraries the problem with M$ software?

From: Glynn Clements (
Date: 11/19/02

  • Next message: Andrew Griffiths: "Re: Are bad developer libraries the problem with M$ software?"
    From: Glynn Clements <>
    Date: Tue, 19 Nov 2002 03:45:19 +0000
    To: "" <>

    "" wrote:

    > As a follow-up to my post, where I said:
    > "I believe you mean strlen and not sizeof. sizeof(mystr) will return
    > the same as sizeof(char*), which is sizeof(int) in most cases or 4 on
    > 32-bit platforms.
    > Unless there's something I wasn't aware of: you're using a bizarre
    > compiler, or C++, or there's a special case for char arrays on the
    > stack."
    > Looks like there's a special case for char arrays on the stack (which
    > I guess technically would be of type char[] and not char*).

    It's nothing to do with the stack; arrays in the data segment are no
    different to arrays on the stack.

    The size of an array is the product of the number of elements and the
    size of each element. The size of a pointer is fixed, and is normally
    the same as the platform's "word size" (e.g. 2, 4 or 8 bytes for 16,
    32 and 64 bit platforms respectively).

    However, it's easy to get confused by the various ways in which C
    treats arrays and pointers as being equivalent. E.g. arrays are always
    passed by reference (as a pointer to the start of the array). If you
    declare a function's argument as an array, e.g.

            void foo(char arg[])

    it's actually a pointer.

    > Once you pass the string around to functions as a char*, or allocate
    > it dynamically, you can't use sizeof.
    > #include <stdio.h>
    > void fn (char *p) {
    > printf ("sizeof(p) = %d\n", sizeof(p));
    > }
    > int main () {
    > char x[15];
    > printf ("sizeof(x) = %d\n", sizeof(x));
    > fn (x);
    > return 0;
    > }
    > Output:
    > sizeof(x) = 15
    > sizeof(p) = 4

    Note that you would get exactly the same result if the array "x" was
    in the data segment (a global variable or a "static" local variable)
    rather than on the stack.

    Glynn Clements <>

    Relevant Pages

    • Re: size_t and Array Limits (From: ptrdiff_t maximum)
      ... The semantics for the 'sizeof' operator doesn't include any mention of arrays in the C90 Standard? ... Why it bothers me is that we might try to work with a pointer which points to something akin to a C array object, but which is provided by something external to our program, such as implementation or OS. ... If 'size_t' is a typedef to a standard integer type, then we really need 'SIZE_MAX' rather than relying on finding the maximum value of the standard integer type. ...
    • Re: ALLOCATABLE arrays
      ... || If try to create a very large array on the stack and you do not have enough ... || Allocating on the heap gives you access to a hell of a lot more memory (well ... and "heap" (and there probably are/were some computers which don't/didn't ... | Automatic arrays are always allocated on the stack. ...
    • Re: Fortran memory allocation (stack/heap) issues
      ... > rather than Fortran, ... dynamic allocation, and relatively little stack allocation. ... value return and arrays by reference. ...
    • Re: Stack or Heap
      ... it ran out of stack space. ... combined with a default that puts many arrays on the stack ... which conforms with the C-standard will compile without error ... seg fault due to stack/heap issues. ...
    • Re: Need some help understanding array definitions
      ... Data structures defined with VARIABLE, CREATE, VALUE, CONSTANT, and related words are, indeed, all global. ... Unlike some languages, Forth doesn't discourage defining global data structures, but it's important to understand their proper use. ... They provide for "persistent" data, as well as space for strings and arrays. ... Strings and arrays should be in defined data structures and referenced by address and length or address on the stack. ...