Originally posted by Daniel Massie: I'm not so sure about that. My instructions state: "4 byte numeric, magic cookie value. Identifies this as a data file "
To me that says that the value should be checked.
To me that says "4 byte numeric, magic cookie value. Identifies this as a data file "
That's just telling you what's in the file. It's not uncommon to put a "magic cookie value" at the start of a file. So that when you go to read the data, you know that you have to move into the file by 4 bytes before you try to read the header information. That doesn't mean you have to check it. You can, but you don't have to. It's probably a good idea, and it couldn't hurt. I, for one, actually DO check it, and for the sake of a good design, I would recommend it, but I don't think that it's actually implied that you need to check it.
Originally posted by Luiz Reginaldo Curado: One more thought... Remember: you will not be graded for additional code, but you can lost points if you do not implement what is required.
You're not suggesting that we over-do the crap out of the project just to make sure we get every little thing they were looking for but not telling us about, are you?
You're not suggesting that we over-do the crap out of the project just to make sure we get every little thing they were looking for but not telling us about, are you?
Wow. Somebody has a lot of time on his hands...
- Adam
There's no time limit, so no excuse to cut corners. It's also no competition to get done faster than someone else, so no excuse to cut corners.
I'd rather have an overengineered solution that covers all the points asked for in the specs and then some than some rapidly smashed together piece of junk that misses a single point because I was so hyped up about wanting it completed yesterday that I forgot about something in my haste.
It seems like the consensus on this, is that while not required, verifying the magic cookie value is good practice. If this is the case then (here comes the stupid question) how if this verification done?
Do you find out and make a note of what that magic cookie value is, then when the data object (or whatever) attempts to open the file, you make sure it has this same (hardcoded) cookie value?
What if another application also used the database file, and made changes to this magic cookie value?
My reading is that magic cookie must be ignored, since you dont know validation rules. The reason is that it is unknown by the developer until execution. So it's value could be that or could be other. We ignore the nature and use of the cookie. As a personal note, i think it is used by Sun automatic tests to verify the integrity of the uploaded database file or/and choose the right Data implementation from a factory...
I passed, and did validate the magic cookie. (You're probably looking for the other folks, who passed without validation...)
> Do you find out and make a note of what that magic cookie value is, then > when the data object (or whatever) attempts to open the file, you make > sure it has this same (hardcoded) cookie value?
Yes. If the magic cookie value was an exact match, then I assumed the file contents were in the expected format (that is, schema description followed by data section).
> What if another application also used the database file, and made changes > to this magic cookie value?
The file would be treated as corrupted, and not eligible to be used. For example, we wouldn't know if the information in the schema description section was also overlaid, which could cause unexpected results.
Cindy, no just curious as to the consensus. I have much bigger things that are vexing me right now than figuring out how to use that cookie! It's so small, I figured it is probably better to just go ahead and use it like a validiy flag. I kind of think it is there for a reason (to be used). Congrats on your pass.
Post by:autobot
passwords must contain 14 characters, a number, punctuation, a small bird, a bit of cheese and a tiny ad.
a bit of art, as a gift, the permaculture playing cards