Problem using fseek

[Maria Mela]

Hello everyone...

I´ve a problem with my code, when i put this lines:

recsize = sizeof(p1);
fseek(fp,-recsize,SEEK_CUR); fwrite(&p1,sizeof(p1),1,fp);
getch();

The file was saved with correct values and with some windows informations
too!?

like this " 8 
O r i g i n a l F i l e n a m e C m d . E x e l &
P
r o d u c t N a m e"

what are the problem?!

Kisses

 

[user923005]

Hello everyone...

I´ve a problem with my code, when i put this lines:

recsize = sizeof(p1);
fseek(fp,-recsize,SEEK_CUR); fwrite(&p1,sizeof(p1),1,fp);
getch();

The file was saved with correct values and with some windows informations
too!?

like this " 8 O r i g i n a l F i l e n a m e C m d . E x e l & P
r o d u c t N a m e"

what are the problem?!

Show the actual code you are using and not a snippet of it.
Simplify the code until you have the minimal fully working code that
demonstrates the problem.

As a wild guess, you might be trying to read an OLE compound document
using fread, which is destined to humor.

 

[Jeffrey Stedfast]

Show the actual code you are using and not a snippet of it.
Simplify the code until you have the minimal fully working code that
demonstrates the problem.

As a wild guess, you might be trying to read an OLE compound document
using fread, which is destined to humor.

or p1 points to a struct with pointers... fwrite() obviously won't
serialise string pointers in a struct.

maybe also byte padding? who knows.

 

[Maria Mela]

here´s my struct

struct customer {
int dd,mm,yy;
char cus_ac_no[15],cus_name[25],cus_add[45],cus_ph_no[17];
double cus_bal;
float cus_intrst;
}p1;

typedef struct customer cust;

FILE *fp,*ft;
int recsize;
char choice,any,ch,eno[23];
double dep,


void transac()//Transaccoes de um Cartao
{
int k,p,t,r;
system("cls");
k=valid();
rewind(fp);
if(k!=2)
{
// _setcursortype(_NOCURSOR);
calbox(); highvideo();
gotoxy(12,12); cprintf(" N£mero invalido! ");
gotoxy(19,14); cprintf(" Tente Novamente");
getch();
}
else
{
while(fread(&p1,sizeof(p1),1,fp)==1)
{
if(strcmp(p1.cus_ac_no,eno)==0)
{
calbox();
fflush(stdin);
choice=getchar();
switch(choice)
{
/*-----------------------------------------------------*/
case '1':
calbox();
gotoxy(5,5); cprintf("xxxxxx:");
gotoxy(8,7);cprintf("Euros :");
scanf("%lf",&dep);
p1.cus_bal+=dep;
acc_info(&p1);
recsize = sizeof(p1);
fseek(fp,-recsize,SEEK_CUR); fwrite(&p1,sizeof(p1),1,fp);
getch();
break;


"user923005" <[email protected]> escreveu na mensagem

Hello everyone...

I´ve a problem with my code, when i put this lines:

recsize = sizeof(p1);
fseek(fp,-recsize,SEEK_CUR); fwrite(&p1,sizeof(p1),1,fp);
getch();

The file was saved with correct values and with some windows informations
too!?

like this " 8 O r i g i n a l F i l e n a m e C m d . E x e l &
P
r o d u c t N a m e"

what are the problem?!

Show the actual code you are using and not a snippet of it.
Simplify the code until you have the minimal fully working code that
demonstrates the problem.

As a wild guess, you might be trying to read an OLE compound document
using fread, which is destined to humor.

 

[user923005]

You missed this bit:
" minimal fully working code "
Which means that it should at least compile and run and demonstrate
the problem.

I suspect you might have a problem with uninitialized data, or struct
alignment (if two different machines read and write the information)
but there is no way to know with what we have been given so far.

Since you are using non-standard Borland functions, it will probably
take a bit longer to get the answers because we will have to stub
those out.

 

[CBFalconer]

.... snip ...

fflush(stdin);
choice=getchar();
switch(choice)
{
/*-----------------------------------------------------*/
case '1':
calbox();
gotoxy(5,5); cprintf("xxxxxx:");
gotoxy(8,7);cprintf("Euros :");
scanf("%lf",&dep);

Why should anyone bother to analyze something that is not
compilable (no main, no #includes) and is obviously in error
(fflush does not function on stdin, no such functions as gotoxy,
cprintf) etc.

Post complete, compilable code, with non-standard garbage
eliminated, after cutting it down to 100 lines or less. By the
time you do that you will probably find the fault yourself. If you
don't know what is standard and what isn't, say so and the
non-portable non-standardisms will be rapidly pointed out to you by
the howling mob.

If you want help, make it easy for someone to help you.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Beej]

fflush does not function on stdin

That language is a little strong. fflush(stdin) clears the input
buffer on some systems, but one should know that it's not portable.

-Beej

 

[Keith Thompson]

That language is a little strong. fflush(stdin) clears the input
buffer on some systems, but one should know that it's not portable.

And that's a little weak. Passing a pointer to an input stream (such
as stdin) to fflush() invokes undefined behavior. Some
implementations may choose to define the behavior.

 

[Richard Heathfield]

Beej said:

That language is a little strong.

More precisely, the behaviour of fflush on input streams is undefined.

fflush(stdin) clears the input
buffer on some systems, but one should know that it's not portable.

And indeed there is no reason to risk it, since portable alternatives
exist, and are trivial to code.

 

[Keith Thompson]

Beej said:


More precisely, the behaviour of fflush on input streams is undefined.


And indeed there is no reason to risk it, since portable alternatives
exist, and are trivial to code.

That's not quite true, depending on what "input buffer" is being
cleared. For example, if input is from a keyboard, it might be useful
to zero the typeahead buffer, in case the user incorrectly anticipated
what the prompt was going to be:

The program prompts "Enter user name: "

The user types "fred" followed by a newline.

The system is being a bit sluggish. The user assumes that the
next prompt is going to be "Enter password: " and types "qLutGg8A"
followed by a newline.

The program was recently modified so a password isn't required,
and the next prompt is actually "Enter broadcast message: ".

Fred's password is now sent out to everybody on the system.

If a call to fflush(stdin) were done before the "Enter broadcast
message: " prompt was issued, *and* if this call discarded the
password characters, then this problem might be avoided. I've used
similar facilities in the past, but not in C. I don't know whether
fflush(stdin) actually works this way on any of the systems that
support it.

This is different from reading and discarding all input up to the next
newline, which is often all you really need.

But the fact remains, fflush(stdin) invokes undefined behavior, and
any code that depends on the behavior of an implementation that
chooses to define it is non-portable, perhaps dangerously so.

(BTW, don't bother guessing what "qLutGg8A" is. It's randomly
generated; I've never used it as a password, and I never will.)

 

[Beej]

And that's a little weak. Passing a pointer to an input stream
(such as stdin) to fflush() invokes undefined behavior. Some
implementations may choose to define the behavior.

Yes, the behavior is undefined except where it is defined. That is
very extremely true.

In any case, these are all more complete answers than merely saying
fflush does not function on stdin.

Short-circuit to the FAQ: http://c-faq.com/stdio/stdinflush2.html

-Beej

 

[Richard Tobin]

The program prompts "Enter user name: "

The user types "fred" followed by a newline.

The system is being a bit sluggish. The user assumes that the
next prompt is going to be "Enter password: " and types "qLutGg8A"
followed by a newline.

The program was recently modified so a password isn't required,
and the next prompt is actually "Enter broadcast message: ".

Fred's password is now sent out to everybody on the system.

(Off-topic, obviously)

A much more realistic example, which often happens in practice, is
that for some reason the username is rejected (perhaps because the
system is slow and it timed out), so the next prompt is "Enter user
name". The user's password is read as their username, the login
fails, and their password is stored in a world-readable log file of
failed logins.

-- Richard

 

[Hallvard B Furuseth]

struct customer {
(...)
}p1;
(...)
while(fread(&p1,sizeof(p1),1,fp)==1)
{
(...)
recsize = sizeof(p1);
fseek(fp,-recsize,SEEK_CUR); fwrite(&p1,sizeof(p1),1,fp);

Maybe you've opened the file in text mode instead of binary mode.
That'll break on some hosts. If so, add a 'b' to the mode flags in
fopen(). Another possibility is that the file is not seekable. Check
the return value from fseek() to catch that. And from fwrite(), while
you are at it.

 

[Chris Dollin]

Yes, the behavior is undefined except where it is defined. That is
very extremely true.

In any case, these are all more complete answers than merely saying
fflush does not function on stdin.

More complete, but possibly less useful.

What does `fflush(stdin)` do? We don't know: it isn't defined /by C/.
Should we use it in our code? No: it isn't defined /by C/.

The knowledge that /some/ systems do /something defined/ with it
doesn't seem to me to be that helpful, except I suppose in a
"nobody expects the Spanish Fflushquisition" kind of way.

 

[Flash Gordon]

Chris Dollin wrote, On 08/02/07 09:51:

More complete, but possibly less useful.

What does `fflush(stdin)` do? We don't know: it isn't defined /by C/.

That is fine.

Should we use it in our code? No: it isn't defined /by C/.

This I disagree with. Better is:

Should we use it in our code? Only if it is documented for all your
platforms of interest *and* you need the functionality it provides,
*and* you comment it *and* you don't post the non-portable code to
comp.lang.c

The knowledge that /some/ systems do /something defined/ with it
doesn't seem to me to be that helpful, except I suppose in a
"nobody expects the Spanish Fflushquisition" kind of way.

The knowledge is useful. Sometimes you need to do things that standard C
provides no mechanism for, and in those situations you use the
appropriate implementation specific method, which *might* be doing a
flush of an input stream. I've certainly had good reason in the past to
clear keyboard buffers (I do mean that rather than discard to the next
newline), and if I have good reason to again I'll do it, and if the
documented method for the system(s) of interest is fflush(stdin) that is
what I will do, I just won't expect that part of the code to be portable.