Re: To find the size of array using its pointer

From: Lawrence Kirby (lknews_at_netactive.co.uk)
Date: 01/20/05 

Date: Thu, 20 Jan 2005 18:09:42 +0000

On Thu, 20 Jan 2005 09:06:25 -0800, Sontu wrote:

> Thanks. So nice of you all, for replying, but I think if i tell you my
> intent then my problem will become much clearer.
>
> In C, parameters to functions are either passed using "call by value"
> or "call by reference" [infact only "call by value", "call by
> reference" can be considered as the former if value is address].
>
> Now if need to implement "call by value-result", precisely on EXISTING
> CODE, what should i do?

I think you'd really need to convince us that this is a sensible thing to
do. Presumably thr existing code is designed to work without these "call
by value-result" semantics so why change it? What are you REALLY trying to
achieve? What you are describing is a means, not an end.

> I mean,
>
> int main(void)
> {
> char buffer[20];
> func(buffer);
> }
> }
> }
> void func(char *bufpas)
> {
> char _buffer[20]; //temporary array
> memcpy(_buffer,bufpas,20);

How does the existing func() code know how big buffer is?

> ......
> ...
>
> memcpy(bufpas,_buffer,20);
> }
> }
> should happen. For this to happen either i can use source-2-source
> transformation

Then maybe you can add an extra size argument automatically. It may not be
easy to figure out the needed size though, e.h. if the caller is passing a
value from a pointer variable rather than a declared array directly.

> or modify the compiler.

I doubt whether that will be a viable alternative.

> But in any case i need to know
> the size of "bufpas" to allocate a temporary array of same size.
>
> If its not clear, kindly mention, i will try to make it comprehensive.

My reaction to how to do something like this is "don't", reexamine the
underlying problem and find a better solution. Which brings us back to my
original qustion, what are you really trying to do?

Lawrence

Relevant Pages

  • Re: OT: Critics and Reviewers
    ... There is but one pattern when I've written you (again, the note in question was to Dave): ... You claim confusion or lock onto the wrong conclusions. ... When you did claim to understand me the most favorable reply from me failed to convince you that you were wrong regarding my intent. ...
    (rec.music.beatles)
  • Re: [PATCH] asm-generic: uaccess: fix up local access_ok() usage
    ... On Sat, Jun 13, 2009 at 10:30, Mike Frysinger wrote: ... directly when the access_okis clearer in intent and for more people, ... expands to the same C code (i.e. always specify the first field -- access ...
    (Linux-Kernel)
  • Re: Add a ternary operator to the language?
    ... > is clearer than when you only use: ... It won't always be a string though-- remember, ... there's not an easy way to mis-intepret what the intent is (in ...
    (borland.public.delphi.non-technical)
  • Re: [PATCH 3/4] asm-generic: uaccess: fix up local access_ok() usage
    ... Mike Frysinger wrote: ... directly when the access_okis clearer in intent and for most people, ... expands to the same C code (i.e. always specify the first field -- access ...
    (Linux-Kernel)
  • Re: Macro to copy down specific number of rows
    ... Using Resize might be clearer in terms of intent. ... Tom Ogilvy "Melanie Breden" wrote in message ... >>> indicating how many times the names should be replicated ...
    (microsoft.public.excel.programming)