|
OK. It looks as if it is reading EOF but the binary format of the file has 1A (26) as the last byte.
Firstly, the app is reading 255 which is the non-2s complement of -1 which is EOF. Why isn't it reading the 26 at all?
Second, what if there exists valid data equalling 255 that is not supposed to be the EOF? how do you tell the filestream to read it as such and keep the stream open?
|
|
|
|
|
first of all you didn't answer whether you are writting the dictionary file size as per your code it is not. EOF is fgetc returns to indicate error you need to check the error status using functions like feof or ferror to determine error, eof or useful data.
|
|
|
|
|
Yes the dictionary size is being written to the first element of the dictionary.
Second, I have used feof to determine that it is reading the last byte as (EOF==-1). What I am saying is, the binary format of the input file shows that it is 26 not -1. What I want to know is why it is reading the EOF character and not the one which is clearly in the file.
|
|
|
|
|
Problem solved. I opened it using "r" and not "rb". Apparently the substitute character 0x1A is used as EOF in text files.
|
|
|
|
|
I was going to ask you how you opened it, i overrated you initially i didn't asked about binary mode.
|
|
|
|
|
but the dictionary size write and feof is not there in your code. Without more code i cannot say more, how you initialise, close, seek the file before read.
|
|
|
|
|
No Raj, it's cool. It's working now. I know what the problem was. I opened it to read it as a text file. The EOF character for text streams is 0x1A which equals 26 (I'm guessing this applies to Windows systems only). So obviously when the stream reads 0x1A it returns -1 as EOF to the application. The key is to fopen with "rb" and not only "r". Obviously then you are reliant on yourself to make sure your app doesn't read over the end of your file. In my application EOF is irrelevant because I use dimensions to keep track of where I am. That's why it doesn't appear in my code. In fact, for binary files it would appear that EOF is only useful for binary data which does not include the EOF value. Anyway, it is working now, so thank you for all your help.
|
|
|
|
|
I already shown in my code how i opened to read file with "rb"
|
|
|
|
|
just a guess. wouldn't flushing the stream help you in this regard ?
|
|
|
|
|
toxcct, you may be onto something here.
I've done this:
for(unsigned int i = 1; i <= dict_size; i++)<br />
{<br />
dictionary[i] = readintbigendian(in);<br />
if(i%60==30)
fflush(in);<br />
}
Interestingly, it now starts reading incorrectly from the 30th value onwards. So flushing is the cause of it rather than the solution. I'm no expert on the internals of stream mechanics, so any suggestions on how to restructure my stream access would be highly appreciated.
|
|
|
|
|
hum, but are you sure you want to write this ?
for(unsigned int i = 1; i <= dict_size; i++)
instead of this :
for(unsigned int i = 0; i < dict_size; i++)
because arrays are 0-based.
but i'm not sure this is related though
|
|
|
|
|
No it isn't. The reason it starts at 1 is cos I store the length of the dictioary array in the first element.
|
|
|
|
|
arg, but that's awful !!! lol.
really, you should consider revising this bad habit 
for the flushing stuff, i have no much idea unfortunately
|
|
|
|
|
well it's not a habit lol. I just did it that way cos it's quick and easy. It's a varsity project so I'm not too bothered about it being elegant. :p
|
|
|
|
|
flushing is to commit the data to disk which the OS keeps in memory for optimisation, "The commit-to-disk feature of the run-time library lets you ensure that critical data is written directly to disk rather than to the operating-system buffers", this may not be the issue in your case.
if you want to use call flush after the write loop to ensure data is written directly to disk.
|
|
|
|
|
That is the same habit that Pascal strings (and BSTRs) have. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
|
hi masters,
i want to allocate memory (64k) at the desired location (address). i remember that it is possible.
can any one give me some idea regarding this?
thanks in advance.
|
|
|
|
|
before giving you more directions, i'd like to know your goals please.
why are you needing to allocate such a huge amount of memory at a given location which windows will probably overwrite or already handles some...?
|
|
|
|
|
toxcct wrote: huge amount of memory
64K? Seriously?
|
|
|
|
|
Hi
thanks for your response.
here is the task please guide me.
i want to interact with an ISA device in the system, and to access its registers, it demands to access the memory available at some X location.
this we came to understand by studying an obsolete console application written for that device.
any ideas?
thank you.
|
|
|
|
|
On NT4 and higher, you cannot directly access the devices registers. The OS will not permit it. You need to have a driver and your app then interacts with the driver.
Judy
|
|
|
|
|
the OS that iam using is windows 98. so it should support right?
|
|
|
|
|
Yes it should but I don't remember how to specifiy the memory mapping.
Judy
|
|
|
|
|
toxcct wrote: why are you needing to allocate such a huge amount of memory
hehe
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
