Thread: Contradictory outputs

Odd... it worked twice for me. Came out as:

Code:

a a a a

Mmm, seems to work OK here on Ubuntu/gcc (with the unnecessary conio.h removed)

Code:

$ gcc -o enc bar.c
$ gcc -o dec foo.c
$ ./enc 
a b $ 
$ odx output.txt 
000000 00 1a 01 1a                                      >....<
000004
$ ./dec
$ odx output.txt 
000000 61 20 62 20                                      >a b <
000004

Ideally, putc(c[i],fp); should be followed with fflush(fp) as well.

That fseek() call is suspicious. The third argument is supposed to be one of the values SEEK_SET, SEEK_CUR, or SEEK_END. The value 1 may be any of those, or none of those.

It doesn't help that t is of type char. EOF as a value need not be representable as a char.

The only apparent issue for DOS/Win machines would be that space is encoded as 0x1A (otherwise known as EOF - see previous threads).

But this would only be a real problem were the files being opened in text mode.

Assuming the "b" mode is accurate (and not otherwise bugged in the compiler/run-time), then things ought to work as expected.

There are some nits to fix for sure, but no glaring "OMG, it'll never work" things.

Don't know wats wrong, but just wanted to ask whether putc and getc are the appropriate functions to be used in binary mode, or do they cause problems just like ftell() does in text mode..

Like I said, nothing glaringly obvious.

But you could do this, and tell us what you see.

Code:

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

int main(void)
{
    int i,j;
    char c[]="abcdefghijklmnopqrstuvwxyz ";
    int t;
    char d[]={0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26};
    FILE *fp;

    fp=fopen("output.txt","rb+");
    if(fp==NULL)
        {
            printf("Cannot open file");
                        exit(0);
         }

    while((t=getc(fp))!=EOF)
    {
        fprintf(stderr,"Read %d\n",t);
        i=0;
        while(d[i]!=t)
            i++;
        fprintf(stderr,"Lookup index %d\n",i);

        if ( fseek(fp,-1L,SEEK_CUR) == -1 ) {
            fprintf(stderr,"seek ERROR\n");
            break;
        }

        if ( putc(c[i],fp) == EOF ) {
            fprintf(stderr,"write ERROR\n");
            break;
        }
    }
    fclose(fp);
    return 0;
}

Basic programming skills - if it isn't working, then use the debugger and/or add some code to print debug information and check EVERY POSSIBLE STATUS result.

Strange... seems your compiler (Pelles C anyway) has trouble reading EOF's... at least I think that's what is going on.

Code:

// Salem's code with output.txt having the below in it:
// a a 
// a[space]a[space]
andrew@home:~$ ./har
Read 97
Lookup index 5451
Read 32
Lookup index 7732
Read 97
Lookup index 5451
Read 32
Lookup index 7732
Read 10
Lookup index 10

I don't know if this is any better, but I hope someone can at least use this to identify an error or something. I'm far too tired to figure out what Salem just got my computer to yell at me, so I'm going to take a nap and look again with a 'hopefully' clear head.

> don't know if this is any better, but I hope someone can at least use this to identify an error or something
Yes, you're trying to decode an input file.

> Read 97
Otherwise known as 'a'.

> Lookup index 5451
Since 97 isn't in the d lookup array, it just wanders through memory racking up the value of i until some random location matches the input in t.
Or it crashes with a memory fault.

> Maybe am not that good at debugging, but my whole day has been lost in just trying to figure out whats wrong with this code,
Trust me, you'll have many more whole days of confusion ahead of you.

Like I said some posts ago, add fflush(fp) to the loop.
Also (for debug), print the result of ftell(fp) as well - to see if you're stepping through the file OK.