compiling error

[Kapteyn's Star]

Hi newsgroup

The program here given is refused by GCC with a error i cannot
understand. It says
rnd00.c: In function ‘main’:
rnd00.c:26: error: expected expression before ‘]’ token

How to make it compile? I also tried buf[10] but that gives "segmentati on
fault". Thanks in advanced.

/* scanf 10 random integers from /dev/random */
#include <stdio.h>

void open_file(FILE *f)
{
f= fopen("/dev/random", "r");
}

void read_values(FIL E *f, int buf[], int count)
{
do
{
--count;
fread((void*)&b uf[count], sizeof(int), 1, f);
}
while(count 0);
}

int main()
{
int buf[10];
int count= 10;
FILE *f;

open_file(f);
read_values(f, buf[], count);
do
{
--count;
printf("%d ", buf[count]);
}
while(count 0);
return 0;
}


--
Kapteyn's Star

[Richard Heathfield]

Re: compiling error

Kapteyn's Star said:

Hi newsgroup
>
The program here given is refused by GCC with a error i cannot
understand. It says
rnd00.c: In function ?main?:
rnd00.c:26: error: expected expression before ?]? token
>
How to make it compile? I also tried buf[10] but that gives "segmentati on
fault". Thanks in advanced.
>
/* scanf 10 random integers from /dev/random */
#include <stdio.h>
>
void open_file(FILE *f)
{
f= fopen("/dev/random", "r");

This won't do what you think. If you want a function to change the value of
an object, you must pass to that function the address of the object.
Alternatively, you can get the function to return the new value of the
object, and pick it up in the caller, as shown:

FILE *open_file()
{
return fopen("/dev/random", "r");
}

usage: fp = open_file();

If you want to do it the parameter way, you need to do this:

void open_file(FILE **f)
{
*f = fopen("/dev/random", "r");
}

Usage: open_file(&fp);

Remember that fopen will return a null pointer if it fails to open the
file.

}
>
void read_values(FIL E *f, int buf[], int count)
{
do
{
--count;
fread((void*)&b uf[count], sizeof(int), 1, f);

Simpler:
fread(&buf[count], sizeof buf[count], 1, f);

or even
fread(buf + count, sizeof buf[count], 1, f);

<snip>

int main()
{
int buf[10];
int count= 10;
FILE *f;
>
open_file(f);
read_values(f, buf[], count);

This should be: read_values(f, buf, count);

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Bacarisse]

Re: compiling error

Kapteyn's Star <remove_digits_ for_email_7Kapt eyns3.Star@g0m8 ai2l.9com>
writes:
<snip>

void open_file(FILE *f)
{
f= fopen("/dev/random", "r");
}

In addition to the other comments, that should be "rb".

--
Ben.

[Kapteyn's Star]

Re: compiling error

Richard Heathfield writes:

Kapteyn's Star said:
>

>Hi newsgroup
>>
>The program here given is refused by GCC with a error i cannot
>understand. It says
>rnd00.c: In function ?main?:
>rnd00.c:26: error: expected expression before ?]? token
>>
>How to make it compile? I also tried buf[10] but that gives
>"segmentatio n fault". Thanks in advanced.
>>
>/* scanf 10 random integers from /dev/random */ #include <stdio.h>
>>
>void open_file(FILE *f)
>{
> f= fopen("/dev/random", "r");

>
This won't do what you think. If you want a function to change the value
of an object, you must pass to that function the address of the object.
Alternatively, you can get the function to return the new value of the
object, and pick it up in the caller, as shown:
>
FILE *open_file()
{
return fopen("/dev/random", "r");
}
>
usage: fp = open_file();
>
If you want to do it the parameter way, you need to do this:
>
void open_file(FILE **f)
{
*f = fopen("/dev/random", "r");
}
>
Usage: open_file(&fp);

oops I forget constantly that C does pass by value for functions, curse
of having learned Pascal in school :)

Remember that fopen will return a null pointer if it fails to open the
file.

Okay. I ommited checking fopen() because /dev/random exists here. But i
see your point, it might be absent under older kernels.

>}
>>
>void read_values(FIL E *f, int buf[], int count) {
> do
> {
> --count;
> fread((void*)&b uf[count], sizeof(int), 1, f);

>
Simpler:
fread(&buf[count], sizeof buf[count], 1, f);

I thought that a typecast is needed when converting between different
typed pointers...

or even
fread(buf + count, sizeof buf[count], 1, f);

This is neat! I still not getting the hang of pointer arithmetics. :(
But sizeof without parenthesis just feels weird. I thought it wont
compile but it does! So much to learn in c...

<snip>
>

>int main()
>{
> int buf[10];
> int count= 10;
> FILE *f;
>>
> open_file(f);
> read_values(f, buf[], count);

>
This should be: read_values(f, buf, count);

Okay arrays when passed to function should not have the index but the
index is needed when in the prototype? Noted.

Thanx to you and Ben... program works now!

--
Kapteyn's Star

[Kapteyn's Star]

Re: compiling error

Ben Bacarisse writes:

Kapteyn's Star <remove_digits_ for_email_7Kapt eyns3.Star@g0m8 ai2l.9com>
writes:
<snip>

>void open_file(FILE *f)
>{
> f= fopen("/dev/random", "r");
>}

>
In addition to the other comments, that should be "rb".

I read in books that in Linux/UNIX there is no difference in text and
binary formats...that was why i left out the b. So i take it that b must
always be used?? Thanx Ben.

--
Kapteyn's Star

[Richard Heathfield]

Re: compiling error

Kapteyn's Star said:

Richard Heathfield writes:
>

>Kapteyn's Star said:
>>

>>}
>>>
>>void read_values(FIL E *f, int buf[], int count) {
>> do
>> {
>> --count;
>> fread((void*)&b uf[count], sizeof(int), 1, f);

>>
>Simpler:
> fread(&buf[count], sizeof buf[count], 1, f);

>
I thought that a typecast is needed when converting between different
typed pointers...

If you need a cast, the chances are good that the conversion isn't
appropriate anyway. In this case, fread takes void * for the first arg,
and the language guarantees that a conversion will be provided between
void * and any object-pointer type, in either direction, so you don't need
the cast at all.

>

>or even
> fread(buf + count, sizeof buf[count], 1, f);

>
This is neat! I still not getting the hang of pointer arithmetics. :(
But sizeof without parenthesis just feels weird. I thought it wont
compile but it does! So much to learn in c...

If you specify a type - sizeof(int) - you need the parentheses, but
specifying a type is almost always the Wrong Thing. Types can change.
Using sizeof on an expression is far better, because if/when you change
the type, you don't have to worry about the sizeof because it will already
"know", so to speak. If you did sizeof(int), however, and later switched
to, say, double, you'd have had to change the sizeof to sizeof(double) - a
maintenance task that is easily overlooked by mistake.

><snip>
>>

>>int main()
>>{
>> int buf[10];
>> int count= 10;
>> FILE *f;
>>>
>> open_file(f);
>> read_values(f, buf[], count);

>>
>This should be: read_values(f, buf, count);

>
Okay arrays when passed to function

Er, this is always awkward...

You can't pass an array to a function. But when you try, what actually
happens is that C interprets the array name as if it were a pointer to the
first element of the array. This is because C is pass-by-value, and arrays
don't have values as such. In practice, it's exactly what you want, most
of the time, so no harm done.

should not have the index but the
index is needed when in the prototype? Noted.

Yes, the type decoration for arrays is required in the declaration, whether
it's a function declaration or object declaration or whatever. (Of course,
in a function declaration it isn't really an array - T foo[] is understood
by the compiler to mean T *foo, which is a little confusing in my opinion,
but that's C for you.)

But in usage, you just need the name of the object, plus any operators that
you want to apply to that object. Note that, sometimes, you do want the []
operator, e.g. if you are accessing a value in the array, you need to know
which value you are accessing: as in...

printf("%d\n", buf[count]);

Note that this is precisely equivalent to:

printf("%d\n", *(buf + count));

A relatively obscure equivalence, but it should bring home to you that buf
doesn't need to have a [] constantly nailed to its behind. :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Re: compiling error

Kapteyn's Star said:

Ben Bacarisse writes:
>

>Kapteyn's Star <remove_digits_ for_email_7Kapt eyns3.Star@g0m8 ai2l.9com>
>writes:
><snip>

>>void open_file(FILE *f)
>>{
>> f= fopen("/dev/random", "r");
>>}

>>
>In addition to the other comments, that should be "rb".

>
I read in books that in Linux/UNIX there is no difference in text and
binary formats...

Right. But on other platforms, the difference is real.

that was why i left out the b. So i take it that b must
always be used??

It's a great habit to get into. One day, they might pay you huge amounts of
money to work on a W. To work on a Wi. A W. A <cough cough coughWINdows
system. And on that system, the difference is real and significant. When
opening binary files under Linux or Unix there is no harm in adding the
"b" (the Standard requires it to be supported), so for the sake of one
extra letter you keep yourself in good shape for when, some day, you have
to get your code to run under some other system.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kapteyn's Star]

Re: compiling error

Richard Heathfield writes:

Kapteyn's Star said:
>

>Richard Heathfield writes:
>>

>>Kapteyn's Star said:
>>>
>>>}
>>>>
>>>void read_values(FIL E *f, int buf[], int count) {
>>> do
>>> {
>>> --count;
>>> fread((void*)&b uf[count], sizeof(int), 1, f);
>>>
>>Simpler:
>> fread(&buf[count], sizeof buf[count], 1, f);

>>
>I thought that a typecast is needed when converting between different
>typed pointers...

>
If you need a cast, the chances are good that the conversion isn't
appropriate anyway. In this case, fread takes void * for the first arg,
and the language guarantees that a conversion will be provided between
void * and any object-pointer type, in either direction, so you don't
need the cast at all.

One small question. If fread() takes a void pointer then how does it know
that what I actually pass in an integer array? Will it figure it out from
the sizeof argument or is some magic going on??

If you specify a type - sizeof(int) - you need the parentheses, but
specifying a type is almost always the Wrong Thing. Types can change.
Using sizeof on an expression is far better, because if/when you change
the type, you don't have to worry about the sizeof because it will
already "know", so to speak. If you did sizeof(int), however, and later
switched to, say, double, you'd have had to change the sizeof to
sizeof(double) - a maintenance task that is easily overlooked by
mistake.

I see what you say. But sizeof(type) is understandable when i look at it
but sizeof expression means i have to figure out the expresson and find
out to which type it belongs.

You can't pass an array to a function. But when you try, what actually
happens is that C interprets the array name as if it were a pointer to
the first element of the array. This is because C is pass-by-value, and
arrays don't have values as such. In practice, it's exactly what you
want, most of the time, so no harm done.

I think i can understand... so arrays are not copied on the stack when we
give them as args to a function but a pointer to it is passed instead. So
given:

int arr[5];
func(arr);

in func() *arr is the same as arr[0] and &arr == &arr[0]?

>should not have the index but the
>index is needed when in the prototype? Noted.

>
Yes, the type decoration for arrays is required in the declaration,
whether it's a function declaration or object declaration or whatever.
(Of course, in a function declaration it isn't really an array - T foo[]
is understood by the compiler to mean T *foo, which is a little
confusing in my opinion, but that's C for you.)

which usage is better in function declarations T *arr or T arr[]? but
there is no difference in actual functions right? That is, everything I
can do with func(T arr[]); can be done with func(T *arr); also??

But in usage, you just need the name of the object, plus any operators
that you want to apply to that object. Note that, sometimes, you do want
the [] operator, e.g. if you are accessing a value in the array, you
need to know which value you are accessing: as in...
>
printf("%d\n", buf[count]);
>
Note that this is precisely equivalent to:
>
printf("%d\n", *(buf + count));
>
A relatively obscure equivalence, but it should bring home to you that
buf doesn't need to have a [] constantly nailed to its behind. :-)

Okay I think im getting the hang of all this. six months back I tried to
learn C from Teach Yourself C in 24 hours but it was too boring :) Now I
have got The C Programming Language which was highly recommanded in this
group...the problems are very interesting but some are tough also!

Thanks for your response.

--
Kapteyn's Star

[Kapteyn's Star]

Re: compiling error

A small thing confuses me. man urandom says

When read, the /dev/random device will only return random bytes...

So is it correct of me to read from /dev/random int values? Or i should
have read instaed of 10 int 40 char values and then cast them to 10 ints??

can i also do the below to get random real numbers?

float a[5];
fread(a, sizeof a[0], 5, dev_random);

is this also the same as?

fread(a, sizeof a, 1, dev_random);

are these all okay?

thanks for any help.


--
Kapteyn's Star

[Keith Thompson]

Re: compiling error

Kapteyn's Star <remove_digits_ for_email_7Kapt eyns3.Star@g0m8 ai2l.9comwrites :
[...]

One small question. If fread() takes a void pointer then how does it know
that what I actually pass in an integer array? Will it figure it out from
the sizeof argument or is some magic going on??

There's no magic. fread() *doesn't* know that you've passed it an
integer array (and in fact you haven't; see below).

The first argument to fread() is normally the address of an array, or
of the first element of an array, which will be converted to void* (a
raw address). This tell fread() where in memory your object is, but
nothing else about it.

The second and third arguments are the size in bytes of each element
of your array, and the number of elements you want to read into. This
tells fread() how much data to read; it's the second and third
arguments multiplied together to yield the size in bytes of the array.

(So why not just use a single size argument? Because fread() reads
whole elements at a time. If you ask it to read 10 4-byte elements
from a file that only has 15 remaining byte, it will only set the
first 3 4-byte elements of your array; it won't touch the 4th element
of your array.)

And of course the fourth specifies the stream you want to read from.

>If you specify a type - sizeof(int) - you need the parentheses, but
>specifying a type is almost always the Wrong Thing. Types can change.
>Using sizeof on an expression is far better, because if/when you change
>the type, you don't have to worry about the sizeof because it will
>already "know", so to speak. If you did sizeof(int), however, and later
>switched to, say, double, you'd have had to change the sizeof to
>sizeof(doubl e) - a maintenance task that is easily overlooked by
>mistake.

>
I see what you say. But sizeof(type) is understandable when i look at it
but sizeof expression means i have to figure out the expresson and find
out to which type it belongs.

Not necessarily; the *compiler* has to figure that out. Typically the
expression is the name of an object. You usually need the size of
that object, whatever type it happens to be. And you don't
necessarily have to know the type of the object to understand why you
need its size.

some_type arr[N];
fread(arr, sizeof arr[0], N, some_file);

To know that the fread call's arguments are correct, you don't need to
know the type of arr, you just need to know that it's an N-element
array of *something*.

And as for "sizeof" without parentheses looking funny, think of it
this way. "sizeof" is an operator, not a function. It happens to be
the only operator in C whose symbol is a keyword (which looks like an
identifier, which looks like it could be a function name) rather than
one or more punctuation marks. Operators don't require parentheses on
their operands (you can write -x, you don't have to write -(x)). The
sizeof operator is no different; you can write sizeof x; you don't
have to write sizeof(x). Though you can add parentheses if you like,
and in some cases it might be necessary for disambiguation.

It's similar in this way to the return statement. You can write
"return x;" rather than "return(x); ", because "return" isn't a
function. (It's not an operator either; it's a special form of
statement.) You can write "return(x); " if you really want to, but the
parentheses are just part of an ordinary parenthesized expression, not
part of the syntax of the return statement.

*But* there's another form of the "sizeof" operator, one whose operand
is a type name rather than an expression. This form of "sizeof" is
what's weird and exceptional. The type name is enclosed in
parentheses, but the parentheses aren't the same as the parentheses
you see on a function call; they're specified by an entirely different
syntax rule. And they're necessary to avoid ambiguity. You can think
of ``sizeof ( type-name )'' as a special distinct form of expression
-- and one that you really don't need to use very often. (The use of
parentheses on a cast is a similar case of surrounding a type name
used in an expression with parentheses to avoid ambiguity.)

>You can't pass an array to a function. But when you try, what actually
>happens is that C interprets the array name as if it were a pointer to
>the first element of the array. This is because C is pass-by-value, and
>arrays don't have values as such. In practice, it's exactly what you
>want, most of the time, so no harm done.

>
I think i can understand... so arrays are not copied on the stack when we
give them as args to a function but a pointer to it is passed instead.

Almost, but not quite. I think it's time to bring out (drum roll)
The Rule.

You *can't* give an array as an argument to a function. You can try,
but it's just not possible in C. (Well, you can wrap the array in a
struct and pass the struct, but we'll ignore that; you can't do it
directly.)

Let's forget about functions, parameters, and arguments for a moment,
and just talk about arrays and pointers.

When you have an expression of array type (such as the name of an
array object), that expression is, *in most contexts*, immmediately
and implicitly converted to a pointer to (equivalently: the address
of) the first element of the array. The only exceptions to this are:
(1) when the array expression is the operand of a "sizeof" operator
(so "sizeof arr" gives you the size of the entire array, not the size
of a pointer); (2) when the array expression is the operand of a unary
"&" (so "&arr" gives you the address of the array, not of its first
element); and (3) when the array expression is a string literal used
in an initializer for an array object. The last case is slightly
obscure; it means that this:
char s[] = "hello";
initializes the array s with { 'h', 'e', 'l', 'l', 'o' '\0' }, not
with a pointer value.

So, when you call a function like:

given:
>
int arr[5];
func(arr);

the expression "arr" is of array type, and its context isn't one of
the three exceptions, so it's implicitly converted to the address of
arr[0], of type int*. This conversion has nothing to do with the fact
that it's a function argument; the same thing would happen in any
context other than the Big Three.

Here's an interesting point: The rules for multidimensiona l arrays are
a direct consequence of this. The standard needn't have mentioned
multidimensiona l arrays at all. They're implied by the rules for
one-dimensional arrays, and for array-to-pointer conversion. Given:

int array_2d[10][20] = { ... };
int elem = array_2d[5][6];

Figuring out how array_2d[5][6] resolves to an element of the 2d array
given the rules I've described is an interesting exercise.

Another rule (which, IMHO, just causes confusion) is that in a
parameter declaration, an array declaration is really a pointer
declaration. This isn't a run-time conversion, it's a compile-time
re-interpretation. So this:

void func(int arr[]);

really *means* this:

void func(int *arr);

The "[]" form can be used to document the fact that you expect to be
passing (the address of the first element of) an array to the
function. But I prefer the "*" form, since it says what it really
means.

An excellent resource for this kind of thing is section 6 of the
comp.lang.c FAQ, <http://www.c-faq.com>.

in func() *arr is the same as arr[0] and &arr == &arr[0]?

Assuming func's parameter was declared as "int *arr" or "int arr[]",
then yes, *arr is the same as arr[0]. But &arr and &arr[0] are not
the same thing. Remember that, inside func, arr is a pointer object
(a parameter); &arr is the address of that pointer object. &arr[0];
is the address of the first (zeroth?) element of the array to whose
first element arr points.

arr == &arr[0] is correct, though.

And remember that the address of an array and the address of its first
element are two different things. They both refer to the same
location in memory, but they're of different types.

[snip]

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: compiling error

On Tue, 15 Jul 2008 10:01:53 -0700, Keith Thompson wrote:

You *can't* give an array as an argument to a function. You can try,
but it's just not possible in C.

Are you allowed to pass an array rvalue to a variadic function in C90?

[Keith Thompson]

Re: compiling error

Harald van Dijk <truedfx@gmail. comwrites:

On Tue, 15 Jul 2008 10:01:53 -0700, Keith Thompson wrote:

>You *can't* give an array as an argument to a function. You can try,
>but it's just not possible in C.

>
Are you allowed to pass an array rvalue to a variadic function in C90?

No, it's still converted to a pointer value.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Re: compiling error

Kapteyn's Star said:

A small thing confuses me. man urandom says
>
When read, the /dev/random device will only return random bytes...

RandomISH.

So is it correct of me to read from /dev/random int values? Or i should
have read instaed of 10 int 40 char values and then cast them to 10
ints??

If you have to cast, you're probably making a mistake. I mentioned that in
a previous reply.

When you open a stream of bytes in binary mode, that's precisely what you
get - a raw stream of bytes. C doesn't care what they represent. Reading
them in chunks of sizeof i as ints is just fine.

can i also do the below to get random real numbers?
>
float a[5];
fread(a, sizeof a[0], 5, dev_random);

Only if you can guarantee that every bit pattern represents a valid float
value (which you can't, because they don't, on most systems).

is this also the same as?
>
fread(a, sizeof a, 1, dev_random);

Yes, and unfortunately it's equally broken. You're okay to do this with
ints, but not with floating point.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: compiling error

On Tue, 15 Jul 2008 10:28:29 -0700, Keith Thompson wrote:

Harald van Dijk <truedfx@gmail. comwrites:

>On Tue, 15 Jul 2008 10:01:53 -0700, Keith Thompson wrote:

>>You *can't* give an array as an argument to a function. You can try,
>>but it's just not possible in C.

>>
>Are you allowed to pass an array rvalue to a variadic function in C90?

>
No, it's still converted to a pointer value.

As far as I was aware, array rvalues are never converted to pointers in
C90, and that conversion is one of the changes C99 made. If you say that
the conversion does exist in C90, could you also say in what other
contexts it can be performed?

[Joachim Schmitz]

Re: compiling error

Richard Heathfield wrote:

Kapteyn's Star said:
>

>Ben Bacarisse writes:
>>

>>Kapteyn's Star
>><remove_digit s_for_email_7Ka pteyns3.Star@g0 m8ai2l.9comwrit es:
>><snip>
>>>void open_file(FILE *f)
>>>{
>>> f= fopen("/dev/random", "r");
>>>}
>>>
>>In addition to the other comments, that should be "rb".

>>
>I read in books that in Linux/UNIX there is no difference in text and
>binary formats...

>
Right. But on other platforms, the difference is real.
>

>that was why i left out the b. So i take it that b must
>always be used??

>
It's a great habit to get into. One day, they might pay you huge
amounts of money to work on a W. To work on a Wi. A W. A <cough cough
coughWINdows system. And on that system, the difference is real and
significant. When opening binary files under Linux or Unix there is
no harm in adding the "b" (the Standard requires it to be supported),
so for the sake of one extra letter you keep yourself in good shape
for when, some day, you have to get your code to run under some other
system.

But Windows doesn't have a /dev/random, so you'd have to modify the code
anyway...
/dev is a UNIXism (and /dev/radnam non portable at all), so it should be
safe to drop the b.

Bye, Jojo