To: Richard Heathfield

B

Bill Cunningham

I made a minor adjustment to your flip function from a previous post. I
tried to compile into an .o file and got these errors. What have I done now?

Thanks

void flip(unsigned char *c, size_t len)
{
while(len--)
{
*b = ~*b;
++b;
}
}

v.c:1: parse error before "size_t"
v.c: In function `flip':
v.c:3: `len' undeclared (first use in this function)
v.c:3: (Each undeclared identifier is reported only once
v.c:3: for each function it appears in.)
v.c:5: `b' undeclared (first use in this function)

Bill
 
B

Bill Cunningham

Bill Cunningham said:
I made a minor adjustment to your flip function from a previous post. I
tried to compile into an .o file and got these errors. What have I done
now?

Thanks

void flip(unsigned char *c, size_t len)
{
while(len--)
{
*b = ~*b;
++b;
}
}

v.c:1: parse error before "size_t"
v.c: In function `flip':
v.c:3: `len' undeclared (first use in this function)
v.c:3: (Each undeclared identifier is reported only once
v.c:3: for each function it appears in.)
v.c:5: `b' undeclared (first use in this function)

Bill

Oh god. Now I really feel stupid. I need to think more before I post. I
need to include stdio.h ! I think this might be the only problem.

Bill
 
B

Beej Jorgensen

Bill Cunningham said:
v.c:1: parse error before "size_t"

The error "parse error before yyy" often tends to mean "I don't know
what yyy is."

In this case, size_t isn't a "built-in" type; it comes from a header
file. Try #include <stddef.h> to define it.

-Beej
 
B

Bill Cunningham

In this case, size_t isn't a "built-in" type; it comes from a header
file. Try #include <stddef.h> to define it.

Ok I see. Thanks. But what do you mean in this case?

Bill
 
M

mark

I made a minor adjustment to your flip function from a previous post. I
tried to compile into an .o file and got these errors. What have I done now?

Thanks

void flip(unsigned char *c, size_t len)
{
while(len--)
{
*b = ~*b;
++b;
}
}

v.c:1: parse error before "size_t"
v.c: In function `flip':
v.c:3: `len' undeclared (first use in this function)
v.c:3: (Each undeclared identifier is reported only once
v.c:3: for each function it appears in.)
v.c:5: `b' undeclared (first use in this function)

Bill

hey bill

try putting

typedef unsigned long long size_t;

at the beginning of the file.
 
B

Barry Schwarz

hey bill

try putting

typedef unsigned long long size_t;

at the beginning of the file.

Proof positive that not all the advice you receive on Usenet is worth
following.
 
M

mark

Proof positive that not all the advice you receive on Usenet is worth
following.

echo '#include <stdio.h>' | gcc -x c -E - | wc -l
748

why slow down compilation by including massive complex headers just to get
one typedef.
 
J

Jens Thoms Toerring

try putting
typedef unsigned long long size_t;
at the beginning of the file.

I don't think that's a very good advice. First of all 'unsigned
long long' may not even exist on Bill's machine. And then why
define it yourself when the compiler rather likely comes with
<stddef.h> that already defines 'size_t' (written by people
that probably know a lot more about the machine than me, you or
Bill)? (Or Bill would be using a very outdated compiler - but
that would, at the same time, significantly reduce his chances
of having a 'unsigned long long' type.)

And, BTW, concerning the error message:

There's an argument of the function with the name 'c' and I
strongly suspect that the use of 'b' within the function should
be replaced by using this 'c' variable...

Regards, Jens
 
B

Bill Cunningham

He means that size_t is not a keyword,
the way that unsigned and char are.

unsigned and char are part of the C language proper,
meaning that no headers are needed
in order to use those words in C code.

size_t is a feature of the standard library.
size_t is defined in <stddef.h>
and the definition of size_t is also duplicated
in many other headers, like <stdio.h>.
I wondered about that because I used printf and sizeof with just stdio.h
defined and printf said "4" bytes without stddef.h.

Bill
 
O

Old Wolf

echo '#include <stdio.h>' | gcc -x c -E - | wc -l

bash: gcc: command not found
why slow down compilation by including massive complex headers just to get
one typedef.

On my system, the relevant header has:
typedef unsigned int size_t;

Applying your "version" would just cause a cascade of errors.
 
M

mark

bash: gcc: command not found


On my system, the relevant header has:
typedef unsigned int size_t;

Applying your "version" would just cause a cascade of errors.

yes of course, if your using a legacy 32-bit operating system then you
need a different typedef.
 
F

Flash Gordon

mark said:
yes of course, if your using a legacy 32-bit operating system then you
need a different typedef.

Or a non-legacy 32 bit system, or a non-legacy 16 bit system, or the
next generation 128 bit system...

There really is no good reason not to include the an appropriate header,
then you don't have to worry about it as it will always be correct. As
mentioned by someone else, one of the possible appropriate headers is
not massive.
 
K

Keith Thompson

mark said:
yes of course, if your using a legacy 32-bit operating system then you
need a different typedef.

No, all you need is "#include <stddef.h>", and your code can work
properly without modification on *any* conforming system.

The true cost of "#include <stdio.h>" is not the number of lines
it causes the compiler to process, it's the actual time (and other
resources) it takes. I think you'll find the real cost is trivial.
If you don't believe me, measure it.

On the other hand, the cost of re-inventing the wheel by declaring
size_t yourself rather than relying on the implementation's
declaration can be huge. In the best case, it costs programmer
time (not just computer time) to modify the source every time it's
recompiled on a different system, or to confirm that the existing
definition is correct. How? Probably by examining the system's
stddef.h header -- if you can find it. How long will it take
you to find it, to load it into your editor, to follow any macro
expansions and typedefs it might depend on, and to be sure you've
gotten it right? Compare this to the time it takes your compiler
to process it.

And suppose you've written your own declaration for size_t, and then
later you decide you want to do some I/O so you add "#include
<stdio.h>". Now you have two declarations for size_t.

(I'm surprised to discover that gcc doesn't complain about this:

#include <stddef.h> typedef unsigned int size_t;

where <stddef.h> happens to typedef size_t as unsigned int; as far as
I can tell by reading the standard, that's a constraint violation.)

Others in this thread have made rather mild comments about your
advice to declare:

typedef unsigned long long size_t;

I'll state it more strongly: that's among the worst C advice I've
seen.
 
A

Antoninus Twink

Probably by examining the system's stddef.h header -- if you can find
it. How long will it take you to find it, to load it into your
editor, to follow any macro expansions and typedefs it might depend
on, and to be sure you've gotten it right?

Keith, Keith, Keith, I'm disappointed in you.

Imagine you of all people falling into the classic clc gotcha of making
the cavalier assumption that stddef.h is a file, and susceptible to
processing with an "editor"!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top