Christoph M. Becker
Christoph M. Becker
Hm, not sure if that would work for GIFs, though.
While I'd love to simplify `gdft.c` in this regard, I'm afraid we can't do that for BC reasons before 3.0.
> let's deprecate it properly Would a respective note in the documentation suffice, or should we also emit a `GD_NOTICE` or even a `GD_WARNING`?
Thanks, I like that! However, there are two issues. Most importantly, if we'd ever have a test for `gdImageDashedLine()` `make check` would fail due to the deprecation warning which is...
Thanks for reporting! I don't think we support EBCDIC, in which case it should be trivial to fix this.
> what if we just hardcoded it to gd_xbm_generated ? If somebody is really using this for including multiple XBMs in some C compilation unit, that won't work. On the...
Oh, right, we never use that as filename, so I'd go with the latter (rename parameter, and don't mangle it anymore).
https://github.com/libgd/libgd/blob/0f9dd9627aa9f5095164a73e84905bb4af4bfc8f/src/gd_xbm.c#L225 The parameter is called `file_name` although it is never used as filename, but is rather used as identifier (prefix) for the generated C code. Renaming the parameter, *and* simultaniously...
Maybe implementing #335 would be a (partial) solution? (I mean that one could constrain the amount of memory consumed by libgd this way.)
> iiuc, Google's oss-fuzz utilizes libfuzzer which means we need to specially compile all of libgd, so we could add some ifdef logic in some core paths to handle this....