By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,572 Members | 2,949 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,572 IT Pros & Developers. It's quick & easy.

Why tthe header is not declared ?

P: n/a
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);
}

Jul 20 '08 #1
Share this Question
Share on Google+
30 Replies


P: n/a
xiao wrote:
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?

--
Ian Collins.
Jul 20 '08 #2

P: n/a
xiao wrote:
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)
Because you didn't declare it.
Why is that ? I think I have declared it . :(
Why would you think that? There isn't any line anywhere in your code
that looks remotely like a declaration of 'header'.
Jul 20 '08 #3

P: n/a
On Sat, 19 Jul 2008 19:10:37 -0700 (PDT), xiao <li*********@gmail.com>
wrote:
>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
Jul 20 '08 #4

P: n/a
On Jul 20, 10:04 am, Barry Schwarz <schwa...@dqel.comwrote:
<snip>
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.
Jul 20 '08 #5

P: n/a
In article <08**********************************@34g2000hsf.g ooglegroups.com>,
<vi******@gmail.comwrote:
>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.
Don't be silly.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 20 '08 #6

P: n/a
On Jul 20, 11:06 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <08543052-06c3-4240-9c9e-5be9f5750...@34g2000hsf.googlegroups.com>,

<vipps...@gmail.comwrote:
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.

Don't be silly.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Thank you very much guys~~~ :)
Jul 20 '08 #7

P: n/a
vi******@gmail.com wrote:
On Jul 20, 10:04 am, Barry Schwarz <schwa...@dqel.comwrote:
<snip>
>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.
The data files may not be portable between different implementations,
even if the code is.

S
Jul 20 '08 #8

P: n/a
vi******@gmail.com said:
On Jul 20, 10:04 am, Barry Schwarz <schwa...@dqel.comwrote:
<snip>
>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.
That is *one* aspect of portability.
It's not to get the same results in every system.
Getting consistent results across platforms is another aspect of
portability, one that is sometimes important and sometimes not. To give an
example of a portable program where consistent results are not important,
consider an aleatoric music-writing program - as long as you're getting
the right *kind* of results, that's enough. For some tasks, however, such
inconsistency would not be acceptable. Portability of results /is/
important in many applications.
Reading and writing the object representation
of integers in file streams does not harm in any way the programs
portability.
It depends on what you mean by "portability". It's a catch-all term that
means different things to different people. For example, in
comp.unix.programmer, it means "runs on ALL Unixes". :-) Sometimes, just
getting it to compile okay on the target system is *not* enough, and data
format portability is an important consideration. It is at such times that
good old-fashioned text files come into their own.

--
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
Jul 20 '08 #9

P: n/a
On Sun, 20 Jul 2008 08:08:53 -0700 (PDT), vi******@gmail.com wrote:
>On Jul 20, 10:04 am, Barry Schwarz <schwa...@dqel.comwrote:
<snip>
>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.
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
Jul 20 '08 #10

P: n/a
Barry Schwarz wrote:
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.netwhich 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
--
E-Mail address works, Jabber: he******@jabber.org, ICQ: 134682867

Jul 21 '08 #11

P: n/a
xiao wrote:
>
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:Th*************@gmail.com>

Jul 21 '08 #12

P: n/a
On Jul 20, 7:06 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <08543052-06c3-4240-9c9e-5be9f5750...@34g2000hsf.googlegroups.com>,

<vipps...@gmail.comwrote:
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.

Don't be silly.
Great advice :P.
Jul 21 '08 #13

P: n/a
On Jul 20, 8:31 pm, Barry Schwarz <schwa...@dqel.comwrote:
On Sun, 20 Jul 2008 08:08:53 -0700 (PDT), vipps...@gmail.com wrote:
On Jul 20, 10:04 am, Barry Schwarz <schwa...@dqel.comwrote:
<snip>
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.

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.
Jul 21 '08 #14

P: n/a
vi******@gmail.com said:

<snip>
Data being transfered between systems? The standard doesn't mention
that.
The Standard doesn't mention a lot of things. In fact, it says relatively
little about portability, and it certainly doesn't /define/ portability.
Reading or writing the representation of any object is perfectly
valid and portable.
That depends on what you mean by "portable".

If, for example, you write an int to a file, transfer the file to a
different platform, and read it back in as an int, you may well find that
the value copied into the int is different to the value you wrote out. The
endianism might differ, or the size of an int might differ, or it might be
different for some other reason. Or, of course, you might strike lucky -
it might be the same value.

There is more to portability than a lint-free compilation.

--
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
Jul 22 '08 #15

P: n/a
On Mon, 21 Jul 2008 16:08:26 -0700 (PDT), vi******@gmail.com wrote:
>On Jul 20, 8:31 pm, Barry Schwarz <schwa...@dqel.comwrote:
>On Sun, 20 Jul 2008 08:08:53 -0700 (PDT), vipps...@gmail.com wrote:
>On Jul 20, 10:04 am, Barry Schwarz <schwa...@dqel.comwrote:
<snip>
>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.

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.
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
Jul 22 '08 #16

P: n/a
In article <bf**********************************@k37g2000hsf. googlegroups.com>,
<vi******@gmail.comwrote:
>On Jul 20, 7:06 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
>In article <08543052-06c3-4240-9c9e-5be9f5750...@34g2000hsf.googlegroups.com>,

<vipps...@gmail.comwrote:
>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.

Don't be silly.

Great advice :P.
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.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '08 #17

P: n/a
Richard Heathfield wrote:
vi******@gmail.com said:

<snip>
>Data being transfered between systems? The standard doesn't mention
that.

The Standard doesn't mention a lot of things. In fact, it says relatively
little about portability, and it certainly doesn't /define/ portability.
>Reading or writing the representation of any object is perfectly
valid and portable.

That depends on what you mean by "portable".

If, for example, you write an int to a file, transfer the file to a
different platform, and read it back in as an int, you may well find that
the value copied into the int is different to the value you wrote out. The
endianism might differ, or the size of an int might differ, or it might be
different for some other reason. Or, of course, you might strike lucky -
it might be the same value.

There is more to portability than a lint-free compilation.
Portability of file data among several C implementations and various
hardware platforms cannot be assumed.

We have a good chance of being able to share simple ASCII text files
because we all agree on the format of the file: Zero or more lines of
zero or more characters terminated with newline.

Beyond that simple text above, the sender and receiver need to agree on
every aspect of the format of the file. If someone gave you a .DBF file
and didn't tell you its format, what could you possibly do with it?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 22 '08 #18

P: n/a
In article <81**********************************@p25g2000hsf. googlegroups.com>,
<vi******@gmail.comwrote:
>Data being transfered between systems? The standard doesn't mention
that.
Actually it does, but it doesn't give you many bones to chew on,
but that's exactly the problem.
>Reading or writing the representation of any object is perfectly
valid
Sure.
>and portable.
Even though "the standard doesn't mention" said representation
of any object between system? I'll even go one step further.
It does not even guarantee it (which is different than mentioning it)
between say different settings of the same compiler.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '08 #19

P: n/a
In article <DK******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:
>Richard Heathfield wrote:
>vi******@gmail.com said:
<snip>
>>Data being transfered between systems? The standard doesn't mention
that.

The Standard doesn't mention a lot of things. In fact, it says relatively
little about portability, and it certainly doesn't /define/ portability.
>>Reading or writing the representation of any object is perfectly
valid and portable.

That depends on what you mean by "portable".

If, for example, you write an int to a file, transfer the file to a
different platform, and read it back in as an int, you may well find that
the value copied into the int is different to the value you wrote out. The
endianism might differ, or the size of an int might differ, or it might be
different for some other reason. Or, of course, you might strike lucky -
it might be the same value.

There is more to portability than a lint-free compilation.

Portability of file data among several C implementations and various
hardware platforms cannot be assumed.
Not even across the same implementation (considering compiling iwth
packing off and then again with packing on -- vippstar, these are not
defined by the standard, but that's part of our point).
>We have a good chance of being able to share simple ASCII text files
because we all agree on the format of the file: Zero or more lines of
zero or more characters terminated with newline.
Well, even that's stretching it, because there are different formats,
and I haven't looked at this part of the standard in a real long time,
but probably there's a lot of luck going on with text files too :)
>Beyond that simple text above, the sender and receiver need to agree on
every aspect of the format of the file. If someone gave you a .DBF file
and didn't tell you its format, what could you possibly do with it?
Yup.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '08 #20

P: n/a
Greg Comeau said:
In article <DK******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:
>>Richard Heathfield wrote:
<snip>
>>>
There is more to portability than a lint-free compilation.

Portability of file data among several C implementations and various
hardware platforms cannot be assumed.

Not even across the same implementation (considering compiling iwth
packing off and then again with packing on -- vippstar, these are not
defined by the standard, but that's part of our point).
A propos of not very much, can I just say what a pleasure it is to see Greg
back amongst us?

<snip>
>If someone gave you a .DBF file
and didn't tell you its format, what could you possibly do with it?
I'd look the format up (and in fact that's precisely what I did do, under
precisely those circumstances). But yes, the point is well-made. I was
fortunate - the .DBF extension was a faithful indicator of the file's
contents according to the customs of the time (dBase III+), which is by no
means as much a given as some people seem to think. Somewhere or other
I've got a documentation-viewer from way back when, that allows me to read
all my .doc files in a nice comfy way, but it gets real confused if you
hand it an MS Word document file instead.

--
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
Jul 22 '08 #21

P: n/a
On Jul 22, 5:09 am, com...@panix.com (Greg Comeau) wrote:
In article <bf869d3e-0e54-496b-a4a8-938d77b1e...@k37g2000hsf.googlegroups.com>,

<vipps...@gmail.comwrote:
On Jul 20, 7:06 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <08543052-06c3-4240-9c9e-5be9f5750...@34g2000hsf.googlegroups.com>,
<vipps...@gmail.comwrote:
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.
Don't be silly.
Great advice :P.

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.
Jul 22 '08 #22

P: n/a
On Jul 22, 5:13 am, com...@panix.com (Greg Comeau) wrote:
In article <81d73edb-49f6-41da-8860-7972d2190...@p25g2000hsf.googlegroups.com>,

<vipps...@gmail.comwrote:
Data being transfered between systems? The standard doesn't mention
that.

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 :-)
Jul 22 '08 #23

P: n/a
vi******@gmail.com said:

<snip>
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.
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.

--
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
Jul 22 '08 #24

P: n/a
On Jul 22, 1:22 pm, Richard Heathfield <r...@see.sig.invalidwrote:
vipps...@gmail.com said:

<snip>
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.

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)
Jul 22 '08 #25

P: n/a
vi******@gmail.com said:
On Jul 22, 1:22 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>vipps...@gmail.com said:

<snip>
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.

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 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.
I disagree with you about the discussion being relevant,
That's up to you.

<snip>

--
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
Jul 22 '08 #26

P: n/a
On Jul 22, 1:52 pm, Richard Heathfield <r...@see.sig.invalidwrote:
vipps...@gmail.com said:
On Jul 22, 1:22 pm, Richard Heathfield <r...@see.sig.invalidwrote:
vipps...@gmail.com said:
<snip>
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.
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 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]; i++)
putc(strchr(charset, message[i]) - 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.
Jul 22 '08 #27

P: n/a
On Jul 22, 3:54 pm, vipps...@gmail.com wrote:
<snip>
putchar(charset[c - 64]);
<snip>
putc(strchr(charset, message[i]) - charset + 64, fp);
<snip>

Small correction: these 64 should've been 65.
Jul 22 '08 #28

P: n/a
vi******@gmail.com said:
On Jul 22, 1:52 pm, Richard Heathfield <r...@see.sig.invalidwrote:
<snip>
>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?

[...] 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 ]
<snip>
All clients agree on ASCII values when writing, and they remap ASCII
to the native character set when reading.
Kind of, but not quite. All clients agree on a set of symbols that are
common to all the character sets in use across the clients. The easiest
way to be sure of this is to restrict oneself to the C source character
set. Never mind the code points - they are neither here nor there. It's
meanings that matter, and in this case it's symbols, not code points, that
carry meaning. The fact that different character sets use different code
points for a particular character is a nuisance, but one that is dealt
with by my point that "you run them through appropriate filters when
moving between systems that have different native character sets". For
example, if you are porting text data from a PC to a mainframe, you'll
typically upload it using some kind of 3270 emulation software with built
in ASCII-to-EBCDIC conversion for text files. If you're porting text data
from a PC running Windows to a PC running Linux, you'll normally use an
FTP client and specify "ASC" to ensure that line end conversions are done.
That sort of thing. This is one of the tasks that one associates with the
act of moving data from one machine to another, not something you'd expect
every single C program to have to provide its own filters for. Of course,
if you're /writing/ the file transfer program, then yes, obviously you
will need to do this translation within the program itself. Or if you're
using a file transfer program that lacks the necessary translation
capability, then you'd want to write *one* program that sits on the far
side of the transfer and maps source code points to destination code
points.

The point(!) is that, for text files, this mapping can be done without
regard for the semantics of the file itself. A binary file containing
numerical data is much harder to map, because the mapping is very, very,
very sensitively dependent on the data format; in practice, you'd have to
write a separate mapping program for almost every different file type.
This simply isn't an issue with text, provided only that you're careful
not to abuse the text paradigm.

--
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
Jul 22 '08 #29

P: n/a
In article <76**********************************@2g2000hsn.go oglegroups.com>,
<vi******@gmail.comwrote:
>On Jul 22, 5:09 am, com...@panix.com (Greg Comeau) wrote:
>In article <bf869d3e-0e54-496b-a4a8-938d77b1e...@k37g2000hsf.googlegroups.com>,
<vipps...@gmail.comwrote:
>On Jul 20, 7:06 pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <08543052-06c3-4240-9c9e-5be9f5750...@34g2000hsf.googlegroups.com>,
<vipps...@gmail.comwrote:
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.
>Don't be silly.
>Great advice :P.

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.
Something like that.
>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 not convinced it does that, but don't want to get into that,
nor do I feel like looking it up, so let's assume it does.
>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.
If the above is so, or at least something like it, I agree with
focusing on Standard C here for this NG. But no real details
were offered beyond Standard C except to say that Standard C
does not say much beyond what it does say. So I don't see the
problem in saying Standard C doesn't say what happens. (Hmm
did I just say that. :) Anyway, I think this conversation is going
to get circular from this point, if it is not already....
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 23 '08 #30

P: n/a
In article <3a**********************************@l64g2000hse. googlegroups.com>,
<vi******@gmail.comwrote:
>On Jul 22, 5:13 am, com...@panix.com (Greg Comeau) wrote:
>In article <81d73edb-49f6-41da-8860-7972d2190...@p25g2000hsf.googlegroups.com>,
<vipps...@gmail.comwrote:
>Data being transfered between systems? The standard doesn't mention
that.

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 :-)
I have to admit to not looking much at this part of the standard
in quite some time but I'm pretty sure it leaves most of it
implementation-defined at the least.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 23 '08 #31

This discussion thread is closed

Replies have been disabled for this discussion.