On Tue, 15 Jul 2014 20:40:08 +0200
Markus Teich <markus.teich_AT_stusta.mhn.de> wrote:
> I hope this explains my issue.
The definition is ambiguous and I start to get the impression the guy
who defined this format had a naive view on what a "blank" is:
Just a normal whitepace (0x20), as you already suspected.
We now have two options: Either really define what should be put as a
delimiter, or just don't care.
Easiest to parse directly is using 0x00, but this is not very
comfortable once you want to write an image-header.
Another thing that bugs me is the inflexiblity of the width and
height-definition. 99% of all images have at most coordinates < 9999,
which means that you waste 10 bytes of image size on 99% of all images,
because every number is zero-padded.
Why not do it like this:
9 "imagefile"
1 0x20
var width
1 0x20
var height
1 0x00
and work with it like this:
char *
readimage(int fd, int *w, int *h)
{
size_t s;
uint8_t c, *p, *data;
for(s = 0; !s || c && s < SIZE_MAX; ++s){
if(!read(fd, &c, 1))
return NULL;
}
if (s < 9 || !(data = malloc(s)) || lseek(fd, 0, SEEK_SET) == -1
|| read(fd, buf, s) != s || strncmp("imagefile", data, 9)
|| !(p = strtok(data, " ") || !(*w = atoi(p))
|| !(p = strtok(p, " ") || !(*h = atoi(p)) ) {
free(data);
return NULL;
}
s = (*w) * (*h) * 4;
free(data);
data = malloc(data, s);
if (!data || read(fd, data, s) != s) {
free(data);
return NULL;
}
return data;
}
This implementation allows arbitrary-size width and height values while
remaining relatively simple at the same time.
imagefile 800 600^_AT_[data]
vs
imagefile 000000800 000000600^_AT_[data]
There may be some overhead, but it is the most flexible solution, as it
both allows simple files with no zero-padding in the values and is a bit
stricter when it comes to the header format (and fails in case it's
malformed instead of just taking what's there and failing silently).
Just imagine some person in the year 2140 who can't save his
2000000000x3000000 image, because we didn't take care of that and fixed
the number-width. :P
Let me know what you think.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Wed Jul 16 2014 - 14:02:27 CEST