No it would not require system() callls... The FindFirstFile(), FindNextFile(), CopyFile() etc calls that you would use are part of the standard Windows API and can be called directly from C code and will work on all versions of Windows since Win95.Originally Posted by parimal.s.dave
The portability issue is going to be problematic since each OS has it's own filesystem and thus it's own API calls for locating and enumerating files.
Not having used the file header method before, this is interesting... Would you say this is more or less reliable than using file extensions?
For a certainty it will be slower, since each file has to be opened, verified and closed before copying.
It will be a better check for the "is not", because presuming this is what image viewers, etc, do, it is a conclusive test -- a corrupted jpeg file without a proper ffd8 at the beginning will be rejected by the software.
But there could be binary files that coincidentally start with ffd8. Depending on what this is for, I guess first doing a case insensitive check for jpg or jpeg, then checking the header to make sure it really is such a thing (or can be treated as such by some software) would be thorough.
For sure, because the time constraint will be disk I/O, and presumably you have to read the directory info either way.For a certainty it will be slower, since each file has to be opened, verified and closed before copying.
If you are happy to presume the files in the filesystem are properly labelled, you might as well just use the suffix. I guess if that proves problematic you could go the header route.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
IBTD, as per this site the first 2 bytes of any jpeg file should == 0xffd8
The format for itCbitC files is such that the first two bytes is 0xffd8. As such, when you come across a file for which the first two bytes is 0xffd8, that alone cannot confirm that the file format is JPEG, because it might be an itCbitC file.
But if you come across a file for which the first two bytes is not 0xffd8, you can be certain that it is neither in JPEG nor itCbitC format.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
lol!
Alright I stand corrected, because as per this the jpeg magic no. is the first 4 bytes i.e. 0xffd8ffe0.
thank u everyone for your help !!!! i have done my job!!!!!
