is this legal declaration/not correct output

[Carramba]

Hi!
I have written some peace of code, but I wonder if it's legal for ansi-c
I have no problem to compiling it, but since I'm inexperience and the
output is not correct I have doubts. Thank you for help!

#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

int main(){

int i;
for(i=0;i<10;i++){
int __buff(*send,i);
}

for(i=0;i<10;i++){
__buff(send,i) = i;
}
for(i=0;i<10;i++){
printf("%d \n",__buff(send,i));
}

return 0;
}

The output is always 3...
My intentions is to deal with several int pointer with loops, since I'm
lazy to write all int's...
I want to make X number of int pointer

int *pointer_1
.....
int *pointer_X

allocate memory for all
pointer_1=malloc(sizeof( *pointer_1))
.....
pointer_X=malloc(sizeof( *pointer_X))
fill them with values
and do something

if this way not proper is there a "hack" for lazy programmer like me?

Thank you again!

L R

[Carramba]

sorry... old code.. :) here is the "right version"

#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

int main(){

int i;
int __buff(*send, ZERO);
for(i=0;i<4;i++){
int __buff(*send,i);
}
for(i=0;i<4;i++){
__buff(send,i) = malloc(sizeof (__buff(*send,i)));
}

for(i=0;i<4;i++){
__buff(send,i) = i;
}
for(i=0;i<4;i++){
printf("%d \n",__buff(send,i));
}

return 0;
}

[Walter Roberson]

In article <46***********************@news.luth.se>,
Carramba <us**@example.netwrote:

>#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

That defines an object-like macro __buff() that takes two parameters,
but no matter what the parameters are, always emits the variable name
s_c . Literally, ess underscore cee, totally unrelated to the s
and c parameters given to the macro. The output behaviour you
observe can be deduced from this.

You cannot just join parameters together in the manner you were thinking;
it -is- possible to create new identifiers from macro parameters, but
it requires fancier preprocessor work, and the replacement is
always done at -compile- time, not at execution time.

I would suggest that what you want to do is use arrays, not
try to generate new variable names dynamically.

>int main(){

int i;
int __buff(*send, ZERO);
for(i=0;i<4;i++){
int __buff(*send,i);
}
for(i=0;i<4;i++){
__buff(send,i) = malloc(sizeof (__buff(*send,i)));
}

for(i=0;i<4;i++){
__buff(send,i) = i;
}
for(i=0;i<4;i++){
printf("%d \n",__buff(send,i));
}

return 0;
}

--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[Carramba]

Walter Roberson skrev:

In article <46***********************@news.luth.se>,
Carramba <us**@example.netwrote:

>#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

That defines an object-like macro __buff() that takes two parameters,
but no matter what the parameters are, always emits the variable name
s_c . Literally, ess underscore cee, totally unrelated to the s
and c parameters given to the macro. The output behaviour you
observe can be deduced from this.

You cannot just join parameters together in the manner you were thinking;

I was afraid so

it -is- possible to create new identifiers from macro parameters, but
it requires fancier preprocessor work, and the replacement is
always done at -compile- time, not at execution time.

could you by kind and suggest how to do it?
I would really like to learn some fancy c stuff :) is it ok that they
are created at compile time.

I would suggest that what you want to do is use arrays, not
try to generate new variable names dynamically.

[Keith Thompson]

Carramba <us**@example.netwrites:

sorry... old code.. :) here is the "right version"

#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

Identifiers starting with underscores are reserved to the
implementation. It's more complex than that, but you should avoid
using such identifiers them in your own code.

This macro ignores its arguments and expands to the identifier "s_c".
I doubt that that's what you intended. You might want to look into
the "##" operator.

You've managed to write code that compiles, but that doesn't do
anything resembling what you're trying to do.

int main(){

Ok, but "int main(void)" is more explicit.

int i;
int __buff(*send, ZERO);

This simply expands to

int s_c;

for(i=0;i<4;i++){
int __buff(*send,i);

You declare another variable named "s_c" inside your loop, but you
don't use it.

}
for(i=0;i<4;i++){
__buff(send,i) = malloc(sizeof (__buff(*send,i)));

This expands to
s_c = malloc(sizeof s_c);

Since s_c is an int, and malloc() returns a void* (and the compiler
knows it, since you have the correct "#include <stdlib.h>" directive),
this is illegal (actually a constraint violation; the compiler is
required to issue a diagnostic, but it's allowed to accept it).

More briefly, your compiler almost certainly warned you about a type
mismatch, but you ignored the warning. If your compiler *didn't* warn
you, crank up its warning levels until it does.

}

for(i=0;i<4;i++){
__buff(send,i) = i;

s_c = i;

}
for(i=0;i<4;i++){
printf("%d \n",__buff(send,i));

printf("%d \n",s_c);

}

return 0;
}

I can really only guess what you're *trying* to do. Looking at a
snippet of your code:

#define __buff(s, c) s_c
/* ... */

for(i = 0; i < 4; i++) {
int __buff(*send,i);
}

I *think* you're trying to create the following declarations:

int *send_0;
int *send_1;
int *send_2;
int *send_3;

The preprocessor just doesn't work that way. If your __buff() macro
were defined correctly, using the ## operator, the line would expand
to

int *send_i;

Macro expansion does textual substitution. The *value* of i is not
available to the preprocessor; it doesn't exist until your program is
actually running.

And even if that worked, the scope of the variable declaration is just
the compound statement. A new variable is created on each iteration
of the loop, and destroyed on reaching the closing '}'.

Basically, you've badly mixed up compilation time and execution time.

You're trying to create a numbered sequence of variables.

That's called an array:

int *send[4];

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Carramba]

Keith Thompson skrev:

Carramba <us**@example.netwrites:

>sorry... old code.. :) here is the "right version"

I can really only guess what you're *trying* to do. Looking at a
snippet of your code:

I posted in my first help request.. but with wrong code. and then
reposting code I just forgot to repost question ... seem like a lot
mistakes today :(

My intentions is to deal with several int pointer with loops, since I'm
lazy to write all int's...
I want to make X number of int pointer

int *pointer_1
......
int *pointer_X

allocate memory for all
pointer_1=malloc(sizeof( *pointer_1))
......
pointer_X=malloc(sizeof( *pointer_X))
fill them with values
and do something

if this way not proper is there a "hack" for lazy programmer like me?

Thank you again!

>
#define __buff(s, c) s_c
/* ... */

for(i = 0; i < 4; i++) {
int __buff(*send,i);
}

I *think* you're trying to create the following declarations:

int *send_0;
int *send_1;
int *send_2;
int *send_3;

yes I was *hopping* to by able to achieve this

The preprocessor just doesn't work that way. If your __buff() macro
were defined correctly, using the ## operator, the line would expand
to

int *send_i;

Macro expansion does textual substitution. The *value* of i is not
available to the preprocessor; it doesn't exist until your program is
actually running.

And even if that worked, the scope of the variable declaration is just
the compound statement. A new variable is created on each iteration
of the loop, and destroyed on reaching the closing '}'.

Basically, you've badly mixed up compilation time and execution time.

I understand that now...

You're trying to create a numbered sequence of variables.

That's called an array:

int *send[4];

good idea! this is one possible solution!
I kind of enjoy using macros, and this is the result of *over using*
it... this is bit a shame that one can create preprocessor loop.. some
times would make life easier.

Thank you.

L R

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <46***********************@news.luth.se>,
Carramba <us**@example.netwrote:

>>#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

That defines an object-like macro __buff() that takes two parameters,
but no matter what the parameters are, always emits the variable name
s_c . Literally, ess underscore cee, totally unrelated to the s
and c parameters given to the macro. The output behaviour you
observe can be deduced from this.

[...]

Quibble: it's a function-like macro, not an object-like macro.
But yes, it ignores its arguments.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Carramba]

Keith Thompson skrev:

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

>In article <46***********************@news.luth.se>,
Carramba <us**@example.netwrote:

>>#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

That defines an object-like macro __buff() that takes two parameters,
but no matter what the parameters are, always emits the variable name
s_c . Literally, ess underscore cee, totally unrelated to the s
and c parameters given to the macro. The output behaviour you
observe can be deduced from this.

[...]

Quibble: it's a function-like macro, not an object-like macro.
But yes, it ignores its arguments.

why is that
#define min(X, Y) ((X) < (Y) ? (X) : (Y))
calling min(1,2) will expend to ((1) < (2) ? (1) : (2))

but
#define __buff(s, c) s_c
calling __buff(1,2) will expand to s_c and not to 1_2 ?
is this because of '_' ?
would
#define __buff(s, c) sc
__buff(1,2) =make 12 ?

[Walter Roberson]

In article <46***********************@news.luth.se>,
Carramba <us**@example.netwrote:

>My intentions is to deal with several int pointer with loops, since I'm
lazy to write all int's...
I want to make X number of int pointer

int *pointer_1
.....
int *pointer_X

allocate memory for all
pointer_1=malloc(sizeof( *pointer_1))
.....
pointer_X=malloc(sizeof( *pointer_X))
fill them with values
and do something

>if this way not proper is there a "hack" for lazy programmer like me?

No. The closest you could come would be a macro, perhaps called
Declare_and_malloc, that you would use like

Declare_and_malloc(pointer,1);
Declare_and_malloc(pointer,2);

and so on for each value, with the macro expanding to

int *pointer_1 = malloc(sizeof(*pointer_1));
int *pointer_2 = malloc(sizeof(*pointer_2));

and so on.

But there is no way to do something like:

#for J(1,10) Declare_and_malloc(pointer,J);

and have it generate the Declare_and_malloc(pointer,1);
and Declare_and_malloc(pointer,2); and so on up to 10.

Use arrays instead:

int *pointers[10];
for (j = 1; j < 10; j++)
pointers[j] = malloc(sizeof **pointers);

--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[Walter Roberson]

In article <46***********************@news.luth.se>,
Carramba <us**@example.netwrote:

>why is that
#define min(X, Y) ((X) < (Y) ? (X) : (Y))
calling min(1,2) will expend to ((1) < (2) ? (1) : (2))

>but
#define __buff(s, c) s_c
calling __buff(1,2) will expand to s_c and not to 1_2 ?
is this because of '_' ?
would
#define __buff(s, c) sc
__buff(1,2) =make 12 ?

No. Macros work on the basis of matching tokens, and _ is a valid
part of a token name. In

#define __buff(s,c) s_c

the preprocessor sees the single token s_c not the three tokens
s _ c .

It is possible to put tokens together, but the steps necessary are
obscure:
#define Join3b(a,b,c) a ## b ## c
#define Join3(a,b,c) Join3b(a,b,c)

then

Join3(s,_,c) would expand to s_c

It is -necessary- to use a two-step process to get this to work.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[Keith Thompson]

Carramba <us**@example.netwrites:
[...]

why is that
#define min(X, Y) ((X) < (Y) ? (X) : (Y))
calling min(1,2) will expend to ((1) < (2) ? (1) : (2))

but
#define __buff(s, c) s_c
calling __buff(1,2) will expand to s_c and not to 1_2 ?
is this because of '_' ?
would
#define __buff(s, c) sc
__buff(1,2) =make 12 ?

Let's get rid of the leading underscores:

#define buff(s, c) s_c

buff(1, 2) /* expands to s_c; the arguments are ignored */

"s_c" is simply a single identifier. In an identifier, the '_'
character acts very much like a letter (except for the fact that
leading underscores can cause problems). s_c is a token by itself;
it's *not* composed of separate tokens s and c separated by an
underscore.

Similarly:

#define buff(s, c) sxc
buff(1, 2) /* expands to sxc; the arguments are ignored */

It is possible to paste tokens together in macro expansions, using the
"##" operator. Any decent C textbook should explain this (I recommend
Kernighan & Ritchie's _The C Programming Language_, known to its
friends as K&R2). I'm not going to go into detail here because (a)
you're likely to learn more if you do the research yourself (and I
might get something wrong), and (b) it's not a good solution to your
problem.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Carramba wrote:

>
I have written some peace of code, but I wonder if it's legal for
ansi-c I have no problem to compiling it, but since I'm inexperience
and the output is not correct I have doubts. Thank you for help!

#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

identifiers starting with an underscore are generally reserved for
the implementation. Don't use them.

>
int main(){

Better to specify the parameters. In this case use "int
main(void)".

>
int i;
for(i=0;i<10;i++){

Separate things with spaces.

int __buff(*send,i);

In general (especially C90) you can't specify storage after code.
Macros just do text replacement. This is meaningless, with s_c
undefined.

}

for(i=0;i<10;i++){
__buff(send,i) = i;
}
for(i=0;i<10;i++){
printf("%d \n",__buff(send,i));
}

return 0;
}

The output is always 3...

You have some work to do.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Carramba]

Carramba skrev:

>
L R

thank you all!

[David Thompson]

On Wed, 16 May 2007 22:46:47 -0400, CBFalconer <cb********@yahoo.com>
wrote:
<snip: several good points>

int i;
for(i=0;i<10;i++){

Separate things with spaces.

int __buff(*send,i);

(Which actually expands to int s_c;)

In general (especially C90) you can't specify storage after code.

In C90 (really C<99) you can't have declarations after statements
_within a block_. Since the body of this for statement is a compound
statement == block, a declaration at its beginning is perfectly legal.
But it is effective only within that block, and does not declare a
variable usable _after_ this for loop ends, much less a series of such
variables, as the OP wanted.

Macros just do text replacement. This is meaningless, with s_c
undefined.

Just text replacement yes, but the result int s_c; is a perfectly
valid though useless declaration that locally defines s_c.

}

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net