Why tthe header is not declared ?

[xiao]

HI~ EVERY ONE~ I have a small program here, when I tried to compile
it , it always reminds that


arrary.c: In function `main':
arrary.c:39: error: `header' undeclared (first use in this function)
arrary.c:39: error: (Each undeclared identifier is reported only once
arrary.c:39: error: for each function it appears in.)

Why is that ? I think I have declared it .





#include<stdlib.h>
#include<string.h>

typedef struct _HEADER {

short num1;
short num2;
short num3;
short num4;

}HEADER;

short i;

short x;
short y;
short z;


void readheader(HEADER *,FILE
*);-------------------------------------------THIS IS LINE 39
void writeheader(HEADER *,FILE *);


main()

{

FILE *fp1;
FILE *fp2;

short ***datatable;

fp1=fopen("g.dat","r");
fp2=fopen("newdata.dat","wb+");

readheader(header,fp1);
writeheader(header,fp2);

for(x=0; x<2 ;x++){
for (y=0; y<3; y++){
for(z=0; z<4; z++){

fwrite(&datatable[x][y][z],sizeof(short),24,fp2);
fclose(fp1);
fclose(fp2);
}
}
}
}

void readheader(HEADER *header,FILE *fp1)
{
fread(&(header->num1),sizeof(short),1,fp1);
fread(&(header->num2),sizeof(short),1,fp1);
fread(&(header->num3),sizeof(short),1,fp1);
fread(&(header->num4),sizeof(short),1,fp1);
}

void writeheader(HEADER *header,FILE *fp2)
{
fwrite(&(header->num1),sizeof(short),1,fp2);
fwrite(&(header->num2),sizeof(short),1,fp2);
fwrite(&(header->num3),sizeof(short),1,fp2);
fwrite(&(header->num4),sizeof(short),1,fp2);
}

 

[Ian Collins]

HI~ EVERY ONE~ I have a small program here, when I tried to compile
it , it always reminds that


arrary.c: In function `main':
arrary.c:39: error: `header' undeclared (first use in this function)
arrary.c:39: error: (Each undeclared identifier is reported only once
arrary.c:39: error: for each function it appears in.)

Why is that ? I think I have declared it .

Where?

 

[Barry Schwarz]

HI~ EVERY ONE~ I have a small program here, when I tried to compile
it , it always reminds that


arrary.c: In function `main':
arrary.c:39: error: `header' undeclared (first use in this function)
arrary.c:39: error: (Each undeclared identifier is reported only once
arrary.c:39: error: for each function it appears in.)

Why is that ? I think I have declared it .





#include<stdlib.h>
#include<string.h>

typedef struct _HEADER {

short num1;
short num2;
short num3;
short num4;

}HEADER;

short i;

short x;
short y;
short z;


void readheader(HEADER *,FILE
*);-------------------------------------------THIS IS LINE 39
void writeheader(HEADER *,FILE *);


main()

{

FILE *fp1;
FILE *fp2;

short ***datatable;

fp1=fopen("g.dat","r");
fp2=fopen("newdata.dat","wb+");

readheader(header,fp1);

More than likely this is the actual line 39 since it is the first
place you use the token header. Where do you think you defined the
object this token should refer to?

writeheader(header,fp2);

for(x=0; x<2 ;x++){
for (y=0; y<3; y++){
for(z=0; z<4; z++){

fwrite(&datatable[x][y][z],sizeof(short),24,fp2);
fclose(fp1);
fclose(fp2);
}
}
}
}

void readheader(HEADER *header,FILE *fp1)

While perfectly legal, reading and writing integers as binary data can
severely limit portability.

{
fread(&(header->num1),sizeof(short),1,fp1);
fread(&(header->num2),sizeof(short),1,fp1);
fread(&(header->num3),sizeof(short),1,fp1);
fread(&(header->num4),sizeof(short),1,fp1);
}

void writeheader(HEADER *header,FILE *fp2)
{
fwrite(&(header->num1),sizeof(short),1,fp2);
fwrite(&(header->num2),sizeof(short),1,fp2);
fwrite(&(header->num3),sizeof(short),1,fp2);
fwrite(&(header->num4),sizeof(short),1,fp2);
}

Remove del for email

 

[vippstar]

While perfectly legal, reading and writing integers as binary data can
severely limit portability.

I disagree, how does it harm portability? Portability is to be able to
compile the code in different systems. It's not to get the same
results in every system. Reading and writing the object representation
of integers in file streams does not harm in any way the programs
portability.

 

[Richard Tobin]

While perfectly legal, reading and writing integers as binary data can
severely limit portability.

[/QUOTE]

I disagree, how does it harm portability? Portability is to be able to
compile the code in different systems.

Don't be silly.

-- Richard

 

[xiao]

Don't be silly.

-- Richard

Thank you very much guys~~~

 

[Stephen Sprunk]

I disagree, how does it harm portability? Portability is to be able to
compile the code in different systems. It's not to get the same
results in every system. Reading and writing the object representation
of integers in file streams does not harm in any way the programs
portability.

The data files may not be portable between different implementations,
even if the code is.

S

 

[Barry Schwarz]

I disagree, how does it harm portability? Portability is to be able to
compile the code in different systems. It's not to get the same
results in every system. Reading and writing the object representation
of integers in file streams does not harm in any way the programs
portability.

Compiling a program is not an end objective, it is one of a series of
steps taken to achieve an end objective. Part of that objective
should be for the code to work properly. Writing integer data in
binary on one system and trying to read it on another can lead to
problems with endian-ness (big vs little vs other), size (short need
not be two bytes) and representation (e.g., 1-complement,
2-complement, signed magnitude). It's even worse with floating point
data. Not all systems use IEEE; mine has three different
representations built into the hardware.

For data being transferred between systems using files, one simple way
to alleviate this problem is to put the data in the file as text. (OT:
for network transfers, there all those cute little system dependent
conversion functions which allow different systems to transfer/receive
the date in a network compliant format.)


Remove del for email

 

[Wolfgang Draxinger]

For data being transferred between systems using files, one
simple way to alleviate this problem is to put the data in the
file as text. (OT: for network transfers, there all those cute
little system dependent conversion functions which allow
different systems to transfer/receive the date in a network
compliant format.)

In the case you don't want to use text --- this can have various
reasons, one might be, that you have certain memory and runtime
constraints, that forbid a complex text->binary parsing
stage --- there are ways to store date binaray, while reataining
portability. An IMHO excellent example for this is the "tpl"
libraray <http://tpl.sourceforge.net> which provides some
XML-ish features for data serialization, into binary files.

Another example would be EBML, originally invented as the basis
for the Matroska multimedia stream container.
<http://ebml.sourceforge.net>

The worst one can do is just dump some binaray into a physical
file, i.e. something that a user might transfer somehow onto
another system.

Of course it's fine to raw dump data into a pipe for, say, inter
process communication.

Wolfgang Draxinger

 

[Kenneth Brody]

HI~ EVERY ONE~ I have a small program here, when I tried to compile
it , it always reminds that

arrary.c: In function `main':
arrary.c:39: error: `header' undeclared (first use in this function)
arrary.c:39: error: (Each undeclared identifier is reported only once
arrary.c:39: error: for each function it appears in.)

Why is that ? I think I have declared it .

You haven't.

[...]

void readheader(HEADER *,FILE
*);-------------------------------------------THIS IS LINE 39

No, it's probably not.

void writeheader(HEADER *,FILE *);

main()

{

FILE *fp1;
FILE *fp2;

short ***datatable;

fp1=fopen("g.dat","r");
fp2=fopen("newdata.dat","wb+");

readheader(header,fp1);

This is probably line 39. Where have you declared "header"?

writeheader(header,fp2);

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[vippstar]

Don't be silly.

Great advice .

 

[vippstar]

Compiling a program is not an end objective, it is one of a series of
steps taken to achieve an end objective. Part of that objective
should be for the code to work properly. Writing integer data in
binary on one system and trying to read it on another can lead to
problems with endian-ness (big vs little vs other), size (short need
not be two bytes) and representation (e.g., 1-complement,
2-complement, signed magnitude). It's even worse with floating point
data. Not all systems use IEEE; mine has three different
representations built into the hardware.

For data being transferred between systems using files, one simple way
to alleviate this problem is to put the data in the file as text. (OT:
for network transfers, there all those cute little system dependent
conversion functions which allow different systems to transfer/receive
the date in a network compliant format.)

Data being transfered between systems? The standard doesn't mention
that. Reading or writing the representation of any object is perfectly
valid and portable.

 

[Barry Schwarz]

Data being transfered between systems? The standard doesn't mention
that. Reading or writing the representation of any object is perfectly
valid and portable.

Are we talking about the same thing? Reading on a 2-complement system
the representation of a negative value produced on a 1-complement
system is guaranteed to yield a different value. Reading the binary
representation of INT_MIN produce on my IBM mainframe on a signed
magnitude big-endian system will produce -0. Reading the 2 byte short
value 1 produced on a big-endian system will produce 256 on a little
endian system. Any of these is enough to impact portability.

Given the above, please tell me how reading and writing binary data is
portable.


Remove del for email

 

[vippstar]

The "problem" here is that I suspect that was Richard's point.
To wit, you referred only to source code portability, and I'll
take a great leap to some strict perspective of Standard C,
whereas that (or whatever is being referred to) is not the only
portability that needs to be taken into consideration.

Of course, in "real world" programming, you do care for other things.
That's why protocols, file formats and other means of communication
between systems exist. My point is that C has guarantees from the
start to the end of the program and that's it; It guarantees you can
write and then read back the integer (assuming no file stream errors).

I'm serious here, I don't see how portability of files across
different systems has any relevance to ISO C. If this was posted in
comp.unix.programmer for example, it would be relevant.

 

[vippstar]

Actually it does, but it doesn't give you many bones to chew on,
but that's exactly the problem.

Where? How? I'd be surprised, but I like surprises

 

[vippstar]

(e-mail address removed) said:



The point is that ISO C makes certain guarantees about the contents of a
stream written by a C program (and, conversely, does *not* make certain
other guarantees which we might perhaps have liked it to make in an ideal
world, but which it can't make for genuine practical reasons).

Those guarantees that it /does/ make are topical here, and there is a
genuine technical advantage to be gained from writing code that deals with
streams only within the subset of file-handling techniques that ISO C
guarantees to be portable. It seems to me that the discussion of such
techniques is relevant, topical, and merit-worthy.

Which subset are you talking about? I disagree with you about the
discussion being relevant, but I don't think such discussions harm the
group in any way. (whereas a discussion about java or the weather
would certainly 'harm' the group)

 

[vippstar]

(e-mail address removed) said:





I lack the time right now to provide a detailed reply. Sorry. I'll try to
get back to this if I can. Broadly, however, if you write text files that
contain only characters that C defines as being within the source
character set, and if you run them through appropriate filters when moving
between systems that have different native character sets, you can be sure
that, when you read them back in on the other system (assuming, of course,
that you do it *right*!), you'll have the same data.

Language lawyers can no doubt drill a few holes in that summary, and it's
the plugging of those holes for which I currently lack the time.

Is this close to what you have in mind?

[ portable.c start ]

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

int main(void) {

FILE *fp;
int i, c;
const char charset[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; /* assume
the whole c character set */
const char message[] = "HELLO WORLD";

fp = fopen("recv", "rb");
if(fp == NULL) {
perror("recv");
return EXIT_FAILURE;
}

while((c = getc(fp)) != EOF) {
if(c > 64 && c < 91)
putchar(charset[c - 64]);
/* else not recognized character */
}

fclose(fp);

fp = fopen("send", "wb");
if(fp == NULL) {
perror("send");
return EXIT_FAILURE;
}

for(i = 0; message; i++)
putc(strchr(charset, message) - charset + 64, fp);

fclose(fp);

return 0;
}

[ portable.c end ]

All clients agree on ASCII values when writing, and they remap ASCII
to the native character set when reading.

 

[vippstar]

On Jul 22, 3:54 pm, (e-mail address removed) wrote:

putchar(charset[c - 64]);

putc(strchr(charset, message) - charset + 64, fp);

<snip>

Small correction: these 64 should've been 65.