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

Declared global variable isn't being seen by main.

P: n/a
Can someone tell me why giv_len isn't being seen in this statement
below "printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len)"

=cut

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

char delimiter = '\n';
unsigned long long int cur_len = 0L;
int giv_len;
unsigned long int record = 0L;

int main(int argc, char *argv[])
{
char* infile = argv[1];
char* outfile = argv[2];
giv_len = atoi(argv[3]);
printf("giv_len is :%d\n",giv_len);

FILE* i = fopen(infile,"r");
FILE* o = fopen(outfile,"w");
int ch;
while((ch=fgetc(i) ) != EOF) {
++cur_len;

if(ch == delimiter) {
++record;
/*printf("%d\n",cur_len); */
if(cur_len != giv_len) {
printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len);
fprintf(o,"Record %d wrong length:%d\n",record,cur_len);
}
cur_len=0;
}
}
fclose(i);
fclose(o);
return 0;
}
Mar 14 '08 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Tr***********@gmail.com wrote:
Can someone tell me why giv_len isn't being seen in this statement
below "printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len)"
The answer is "because you lied to printf() by telling it that the cur_len
variable was an int".

Correct your printf() statement format string to reflect the fact that the
second variable value is an unsigned long long, and your problem should go
away.
=cut

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

char delimiter = '\n';
unsigned long long int cur_len = 0L;
int giv_len;
unsigned long int record = 0L;

int main(int argc, char *argv[])
{
char* infile = argv[1];
char* outfile = argv[2];
giv_len = atoi(argv[3]);
printf("giv_len is :%d\n",giv_len);

FILE* i = fopen(infile,"r");
FILE* o = fopen(outfile,"w");
int ch;
while((ch=fgetc(i) ) != EOF) {
++cur_len;

if(ch == delimiter) {
++record;
/*printf("%d\n",cur_len); */
if(cur_len != giv_len) {
printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len);
fprintf(o,"Record %d wrong length:%d\n",record,cur_len);
}
cur_len=0;
}
}
fclose(i);
fclose(o);
return 0;
}
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Mar 14 '08 #2

P: n/a
changed to the following:

printf("Record %lu wrong length:%llu Should be %d
\n",record,cur_len,giv_len);

to no avail
On Mar 13, 8:32 pm, Lew Pitcher <lpitc...@teksavvy.comwrote:
Tristin.Co...@gmail.com wrote:
Can someone tell me why giv_len isn't being seen in this statement
below "printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len)"

The answer is "because you lied to printf() by telling it that the cur_len
variable was an int".

Correct your printf() statement format string to reflect the fact that the
second variable value is an unsigned long long, and your problem should go
away.
=cut
#include <stdio.h>
#include <stdlib.h>
char delimiter = '\n';
unsigned long long int cur_len = 0L;
int giv_len;
unsigned long int record = 0L;
int main(int argc, char *argv[])
{
char* infile = argv[1];
char* outfile = argv[2];
giv_len = atoi(argv[3]);
printf("giv_len is :%d\n",giv_len);
FILE* i = fopen(infile,"r");
FILE* o = fopen(outfile,"w");
int ch;
while((ch=fgetc(i) ) != EOF) {
++cur_len;
if(ch == delimiter) {
++record;
/*printf("%d\n",cur_len); */
if(cur_len != giv_len) {
printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len);
fprintf(o,"Record %d wrong length:%d\n",record,cur_len);
}
cur_len=0;
}
}
fclose(i);
fclose(o);
return 0;
}

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Mar 14 '08 #3

P: n/a
I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.

Any way I can work around this and get the long long?
On Mar 13, 8:40 pm, Tristin.Co...@gmail.com wrote:
changed to the following:

printf("Record %lu wrong length:%llu Should be %d
\n",record,cur_len,giv_len);

to no avail

On Mar 13, 8:32 pm, Lew Pitcher <lpitc...@teksavvy.comwrote:
Tristin.Co...@gmail.com wrote:
Can someone tell me why giv_len isn't being seen in this statement
below "printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len)"
The answer is "because you lied to printf() by telling it that the cur_len
variable was an int".
Correct your printf() statement format string to reflect the fact that the
second variable value is an unsigned long long, and your problem should go
away.
=cut
#include <stdio.h>
#include <stdlib.h>
char delimiter = '\n';
unsigned long long int cur_len = 0L;
int giv_len;
unsigned long int record = 0L;
int main(int argc, char *argv[])
{
char* infile = argv[1];
char* outfile = argv[2];
giv_len = atoi(argv[3]);
printf("giv_len is :%d\n",giv_len);
FILE* i = fopen(infile,"r");
FILE* o = fopen(outfile,"w");
int ch;
while((ch=fgetc(i) ) != EOF) {
++cur_len;
if(ch == delimiter) {
++record;
/*printf("%d\n",cur_len); */
if(cur_len != giv_len) {
printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len);
fprintf(o,"Record %d wrong length:%d\n",record,cur_len);
}
cur_len=0;
}
}
fclose(i);
fclose(o);
return 0;
}
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Mar 14 '08 #4

P: n/a
Tr***********@gmail.com wrote:
I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.

Any way I can work around this and get the long long?
<top post snipped>

This is a well known "interoperability issue" between MinGW and
Microsoft's C runtime library. MinGW's compiler, gcc, supports long
long while the C library it links to by default (Microsoft's CRT) does
not support almost any C99 features, including long long. Thus printf
(which is part of CRT) displays the value incorrectly.

The fix is to use a compiler and C library that agree with each other.
An alternative to MinGW on Windows may be Cygwin, or DJGPP.

Mar 14 '08 #5

P: n/a
On Thu, 13 Mar 2008 18:44:34 -0700 (PDT), Tr***********@gmail.com
wrote:
>I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.
If you compiler doesn't support long long, your object declarations
should result in a compile time diagnostic. Have you set the warning
level to the appropriate level?
>Any way I can work around this and get the long long?
Why? unsigned long is guaranteed to support a value of at least 2G.
Are you planning on testing with a larger file?
>

On Mar 13, 8:40 pm, Tristin.Co...@gmail.com wrote:
>changed to the following:

printf("Record %lu wrong length:%llu Should be %d
\n",record,cur_len,giv_len);

to no avail
It would be nice if you told us what output you were expecting and
what you actually received.
>>
On Mar 13, 8:32 pm, Lew Pitcher <lpitc...@teksavvy.comwrote:
Tristin.Co...@gmail.com wrote:
Can someone tell me why giv_len isn't being seen in this statement
below "printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len)"
The answer is "because you lied to printf() by telling it that the cur_len
variable was an int".
Correct your printf() statement format string to reflect the fact that the
second variable value is an unsigned long long, and your problem should go
away.
=cut
#include <stdio.h>
#include <stdlib.h>
char delimiter = '\n';
unsigned long long int cur_len = 0L;
int giv_len;
unsigned long int record = 0L;
int main(int argc, char *argv[])
{
char* infile = argv[1];
char* outfile = argv[2];
giv_len = atoi(argv[3]);
Will the value you provide in argv[3] fit in an int?
printf("giv_len is :%d\n",giv_len);
FILE* i = fopen(infile,"r");
FILE* o = fopen(outfile,"w");
Don't you think you ought to check to make sure both streams are
actually open?
int ch;
while((ch=fgetc(i) ) != EOF) {
++cur_len;
if(ch == delimiter) {
++record;
You planning on supporting a file with 2G records?
/*printf("%d\n",cur_len); */
if(cur_len != giv_len) {
printf("Record %d wrong length:%d Should be %d
\n",record,cur_len,giv_len);
You changed this one -
fprintf(o,"Record %d wrong length:%d\n",record,cur_len);
but you forgot to change this one. Neither record nor cur_len are of
type int as promised by the %d specifications.
}
cur_len=0;
}
}
fclose(i);
fclose(o);
return 0;
}

Remove del for email
Mar 14 '08 #6

P: n/a
I'm using files that can potentially be several terabytes. My first
test file was over 232GB. I had to compile with the -
D_FILE_OFFSET_BITS=64 flag just to be able to open it. I'm getting
relatively good performance though, over 1GB a minute. Here's an
example of the output.

Record 201 exceeds maximum length:3192066904
Record 301 exceeds maximum length:4009622504

Yes the value provided to argv[3] will fit into an int. Our products
have a max length of a record so it'll never be bigger than 102400
bytes. This app should really help. Try searching through 500GB for a
single bad record. :)

Here's the actual "finished" code Maybe someone else can get some use
out of it or tell me some way to optimize it further.

=cut

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

/* Unsure if these are really needed */
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE

/* you must use the compiler flag -D_FILE_OFFSET_BITS=64 on linux
so that it is possible to open/parse files larger than 2GB

2008 March 13
*/
int debug = 0;

void help();

char delimiter = '\n';
unsigned long int cur_len = 0L;
int giv_len = 0;
unsigned long int record = 0L;

int main(int argc, char *argv[])
{
char* infile = NULL;
char* outfile = NULL;
giv_len = 0;

if(debug) {
int i = 0;
for(i=0;i<argc;i++) {
printf("%s\n",argv[i]);
}
}

if(argc == 1) {
help();
exit(0);
}

int option;
/* Parse Our options
************************************************** *********/
while( (option=getopt(argc,argv,"i:o:l:h")) != -1 ) {
switch(option) {
case 'i':
infile = optarg;
break;
case 'o':
outfile = optarg;
break;
case 'l':
giv_len = atoi(optarg);
break;
case 'h':
help();
break;
case '?':
printf("Unknown argument:%c\n",optopt);
exit(2);
break;
case ':':
printf("Option %c requires an argument\n",optopt);
exit(2);
break;

}
}

FILE* i;
FILE* o;

if( (( i = fopen(infile,"r") ) == NULL ) || ( o =
fopen(outfile,"w") ) == NULL) {
printf("You must specify a valid input and output file\n");
perror("Error");
exit(2);
}

if(giv_len == 0) {
printf("You must give a [maximum] record length\n");
exit(2);
}

int ch;
while((ch=fgetc(i) ) != EOF) {
++cur_len;

if(ch == delimiter) {
++record;

if(cur_len giv_len) {
printf("Record %lu exceeds maximum length:%lu
\n",record,cur_len);
fprintf(o,"Record %lu exceeds maximum length:%lu
\n",record,cur_len);
}
cur_len=0;
}
}
fclose(i);
fclose(o);
return 0;
}

void help() {
printf("\n");
printf("Variable Length File Verifier:\n");
printf("-i file The name of the input file\n");
printf("-o file The name of the output file\n");
printf("-l length The max number of bytes per record\n");
printf("-h This screen\n");
printf("\n");
printf("Example: variable.exe -i 99999.SO01 -o badrecords.txt -l
102400\n");
printf("\n");
printf("\n");
}

Mar 14 '08 #7

P: n/a
On Mar 13, 8:44 pm, Tristin.Co...@gmail.com wrote:
I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.
http://www.mingw.org/MinGWiki/index.php/long%20long
Mar 14 '08 #8

P: n/a
santosh <sa*********@gmail.comwrites:
Tr***********@gmail.com wrote:
>I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.

Any way I can work around this and get the long long?

<top post snipped>

This is a well known "interoperability issue" between MinGW and
Microsoft's C runtime library. MinGW's compiler, gcc, supports long
long while the C library it links to by default (Microsoft's CRT) does
not support almost any C99 features, including long long. Thus printf
(which is part of CRT) displays the value incorrectly.

The fix is to use a compiler and C library that agree with each other.
An alternative to MinGW on Windows may be Cygwin, or DJGPP.
Really? I've heard that MinGW has an inconsistency in the
representation of long double supported by the compiler vs. the
representation expected by the (MS-provided) runtime library. I
hadn't heard that there was an issue with long long. You could well
be right, of course.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 14 '08 #9

P: n/a
Barry Schwarz <sc******@dqel.comwrites:
On Thu, 13 Mar 2008 18:44:34 -0700 (PDT), Tr***********@gmail.com
wrote:
>>I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.

If you compiler doesn't support long long, your object declarations
should result in a compile time diagnostic. Have you set the warning
level to the appropriate level?
If the compiler supports long long, but the runtime library doesn't
(in particular, if printf doesn't support the "%llu" format), then you
could have problems that don't show up as compiler error messages. I
know that MinGW, which combines a compiler and a runtime library from
two different sources, has this kind of problem with long double; it
might have a similar problem with long long.

[snip]

Tristin, please don't top-post. Read the following:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 14 '08 #10

P: n/a
ym******@gmail.com writes:
On Mar 13, 8:44 pm, Tristin.Co...@gmail.com wrote:
>I think i figured it out. I'm on a windows box(using minGW). maybe it
doesn't support long long b/c when i change it to just unsigned long
and change the format accordingly, it works.

http://www.mingw.org/MinGWiki/index.php/long%20long
D'oh! I just posted two followups speculating on whether that might
be a problem; I could have saved the effort if I'd just read the
entire thread first. <EMILY_LITELLS>Never mind.</EMILY_LITELLA>

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 14 '08 #11

P: n/a
Tr***********@gmail.com wrote:
I'm using files that can potentially be several terabytes.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>
Mar 14 '08 #12

P: n/a
"Default User" <de***********@yahoo.comwrites:
Tr***********@gmail.com wrote:
>I'm using files that can potentially be several terabytes.


Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>
You posted this at 25 past 5 or so. Did you really not see Santosh's and
keith's admonishments from 20 minutes earlier? And dont come out with
that "my news server was behind" nonsense.

Please stop spamming this NG with your petty net nannying. If you wish
to continue doing this please at least post something pertinent to the
question as Keith has the common sense to do.
Mar 14 '08 #13

P: n/a
Barry Schwarz wrote:
Tr***********@gmail.com wrote:
>I think i figured it out. I'm on a windows box(using minGW).
maybe it doesn't support long long b/c when i change it to just
unsigned long and change the format accordingly, it works.

If you compiler doesn't support long long, your object
declarations should result in a compile time diagnostic. Have
you set the warning level to the appropriate level?
Not if the problem is in the linked library. Then problems may
show up in the linking step only.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com

Mar 14 '08 #14

P: n/a
You posted this at 25 past 5 or so. Did you really not see Santosh's and
keith's admonishments from 20 minutes earlier? And dont come out with
that "my news server was behind" nonsense.
I am using google groups to post and yes, there IS a lag. Do a post
and refresh a few times. It can take up to 10 minutes for your comment
to post and I imagine it can take just as long for someone else's post
to show.
Please stop spamming this NG with your petty net nannying. If you wish
to continue doing this please at least post something pertinent to the
question as Keith has the common sense to do.
I apologize for spamming the newsgroup and I'll chop and bottom post
from now on, but for someone so insistent on netequette, you sure
could learn a little tact yourself.

Mar 14 '08 #15

P: n/a
Tr***********@gmail.com writes:
>You posted this at 25 past 5 or so. Did you really not see Santosh's and
keith's admonishments from 20 minutes earlier? And dont come out with
that "my news server was behind" nonsense.

I am using google groups to post and yes, there IS a lag. Do a post
I did not reply to you.
and refresh a few times. It can take up to 10 minutes for your comment
to post and I imagine it can take just as long for someone else's post
to show.
>Please stop spamming this NG with your petty net nannying. If you wish
to continue doing this please at least post something pertinent to the
question as Keith has the common sense to do.

I apologize for spamming the newsgroup and I'll chop and bottom post
from now on, but for someone so insistent on netequette, you sure
could learn a little tact yourself.
See comment above.

The post I replied to was:

,----
| From: "Default User" <de***********@yahoo.com>
| Subject: Re: Declared global variable isn't being seen by main. - TPA
| Newsgroups: comp.lang.c
| Date: 14 Mar 2008 17:24:41 GMT
| User-Agent: XanaNews/1.17.5.9
|
| Tr***********@gmail.com wrote:
|
| I'm using files that can potentially be several terabytes.
|
|
| Please don't top-post. Your replies belong following or interspersed
| with properly trimmed quotes. See the majority of other posts in the
| newsgroup, or:
| <http://www.caliburn.nl/topposting.html>
`----

Feel no need to apologise - if you thought I was referring to you then
you have every right to feel miffed. As it was I was defending you if
anything.

The poster I replied to spends his whole day policing peoples posts and
telling people what they can post and how they should do it. It's
painful to watch so I felt like giving him a prod in the ribs.

Mar 14 '08 #16

P: n/a
Tr***********@gmail.com wrote:

Please stop spamming this NG with your petty net nannying. If you
wish to continue doing this please at least post something
pertinent to the question as Keith has the common sense to do.

I apologize for spamming the newsgroup and I'll chop and bottom post
from now on, but for someone so insistent on netequette, you sure
could learn a little tact yourself.

I doubt the message was directed towards you. I believe the person
meant me. At any rate, apparently from someone I killfiled. I'd guess
Richard or Kenny.


Brian
Mar 14 '08 #17

P: n/a
Tr***********@gmail.com said:
>
>You posted this at 25 past 5 or so. Did you really not see Santosh's and
keith's admonishments from 20 minutes earlier? And dont come out with
that "my news server was behind" nonsense.

I am using google groups to post and yes, there IS a lag.
Oh, pay him no mind. He wasn't actually replying to you, but because your
news server was behind, you didn't see the article to which he was
actually responding, so naturally you thought he was responding to you.
You have, in fact, demonstrated that his sentence 'And dont come out with
that "my news server was behind" nonsense' was itself nonsense - some
servers *do* lag.
Do a post
and refresh a few times. It can take up to 10 minutes for your comment
to post and I imagine it can take just as long for someone else's post
to show.
Right. But why confuse a troll with facts?

<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
Mar 14 '08 #18

P: n/a
Tr***********@gmail.com wrote:
>
>You posted this at 25 past 5 or so. Did you really not see
Santosh's and keith's admonishments from 20 minutes earlier? And
dont come out with that "my news server was behind" nonsense.

I am using google groups to post and yes, there IS a lag. Do a
post and refresh a few times. It can take up to 10 minutes for
your comment to post and I imagine it can take just as long for
someone else's post to show.
You are in fairly good shape, having stopped the top-posting. You
also need to ensure that you do not snip attributions for material
you quote. (Attributions are the initial "joe wrote:" lines in a
message.)

Bear two more factors in mind. Some users may respond almost
instantly. Others wait until they get around to it. This is after
possible transmission delays. Google is just another newsreader,
with serious faults, attached to the Usenet system.

A last point: You are responding to a notorious troll. That
particular 'Richard' is plonked by many here.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

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

Mar 15 '08 #19

P: n/a
CBFalconer wrote:

<snip>
[...] Google is just another newsreader,
with serious faults, attached to the Usenet system.
Google Groups is a newsreader as well as a news server. It also archives
most of Usenet's text groups.

<snip>

Mar 15 '08 #20

P: n/a
santosh wrote:
CBFalconer wrote:

<snip>
[...] Google is just another newsreader,
with serious faults, attached to the Usenet system.

Google Groups is a newsreader as well as a news server. It also
archives most of Usenet's text groups.
And doesn't do any of that very well.


Brian
Mar 16 '08 #21

P: n/a
Default User wrote:
santosh wrote:
>CBFalconer wrote:

<snip>
[...] Google is just another newsreader,
with serious faults, attached to the Usenet system.

Google Groups is a newsreader as well as a news server. It also
archives most of Usenet's text groups.

And doesn't do any of that very well.
I agree about the front-end and I don't have the knowledge or
qualifications to judge the server part, but can you tell me if there
any other even better Usenet archivers?

Mar 17 '08 #22

P: n/a
santosh wrote:
Default User wrote:
santosh wrote:
CBFalconer wrote:

<snip>

[...] Google is just another newsreader,
with serious faults, attached to the Usenet system.

Google Groups is a newsreader as well as a news server. It also
archives most of Usenet's text groups.
And doesn't do any of that very well.

I agree about the front-end and I don't have the knowledge or
qualifications to judge the server part, but can you tell me if there
any other even better Usenet archivers?

You seem to have confused "doesn't do something well" with "doesn't do
something as well as others". There are no other archives as complete
as Google's that I'm aware of. However, their archive is not only not
complete, it's been losing messages that previously were in the
archive. Not only that, its search mechanism has by turns been between
so-so and awful.

Brian
Mar 17 '08 #23

This discussion thread is closed

Replies have been disabled for this discussion.