Re: [C] Array bounds in function prototypes

From: Andrey Tarasevich (andreytarasevich_at_hotmail.com)
Date: 03/11/04 

Date: Wed, 10 Mar 2004 15:55:15 -0800

Jason Spashett wrote:
> ...
>> Well, just like it says, an array argument 'decays' into a pointer
> ...
>
> Thanks for the detailed information. However, exactly why does it decay to a
> pointer in a function prototype? I can't see why the array typing
> information could not be preserved, is it for backwards compatibility? [ And
> as an aside: is this the same in C++, I would presume not ]

If you preserve the array typing, then the syntax that you used will
formally mean that the array is passed "by value", i.e. the function
receives the _copy_ of the argument array. But in both C and C++ array
are neither copyable nor assignable. (Unfortunately I don't remember the
exact rationale behind the original limitation). This means that "pass
by value" syntax for arrays in C/C++ should be either outlawed or forced
to mean something else. In the current C/C++ it is the latter, as was
already explained by Mike.

The workaround that will preserve the array typing is to pass the array
"by pointer"

  void fn(unsigned char (*map)[256]) {
    printf("%u", sizeof *map );
  }

or, in C++, "by reference"

  void fn(unsigned char (&map)[256]) {
    printf("%u", sizeof *map );
  }

> I realised that I could pass a pointer to an array of n elements to do the
> job, I've never actually passed fixed sized array before. I normally just
> say char *map instead.

Using 'char* map' or 'char map[]' is just a useful trick that allows you
to declare a function that will be able to work with arrays of different
sizes. If the function is supposed to work only with arrays of one
pre-determined size, then the better idea would be to use either "pass
by pointer" or "pass by reference" approach, since they offer better
type safety.

> In the case of printf("%u", sizeof x); won't x get promoted to unsigned int
> anyway, even if one does cast a size_t type to some unsigned type it may not
> work anyway (in theory) ?

Sorry, I don't understand the question. 

-- 
Best regards,
Andrey Tarasevich

Relevant Pages

  • Re: char **argv & char *argv[]
    ... "pointer to pointer to char". ... >> pointer)) pointing to the first element of an array. ... so we have to start adding more context. ... type "pointer to char", rather than "array MISSING_SIZE of char". ...
    (comp.lang.c)
  • Re: why cannot assign to function call
    ... hypothetical C-like languages, ... sizeof business would still indicate that a pointer was being passed. ... talk about variables of an array type. ... the earlier version of the standard didn't have numbered ...
    (comp.lang.python)
  • Re: multi dimensional arrays as one dimension array
    ... please - where does the standard say that such a conversion ... Pointer conversion yields a pointer to the same object as ... exist only where there are array declarations. ...
    (comp.lang.c)
  • Re: Evaluating unary *
    ... 'arr' exists, ... value can be used with the same syntax as would be used to access a 2D array of the kind you're referring to, but that 2D array is just a different way of looking as the same object that was already created by the definition of 'arr'. ... to me, it makes sense to return a pointer to the first value of an array, but to return the address of the pointer to the first value of an array, is not directly possible as such. ... lea eax, ...
    (comp.std.c)
  • Re: Copying an array slice (Was: Re: Difficulties with passing multi-dimensional arrays)
    ... > the pointer to array of unknown size. ... but it still compiles without a cast. ... unknown at compile time so nothing can be checked. ...
    (comp.lang.c)
Loading