The FreeType Project - Bugs: bug #54753, Can't create an FT_MemoryRec_
You are not allowed to post comments on this tracker with your current authentication level.
bug #54753: Can't create an FT_MemoryRec_
Submitter: | bungeman <bungeman> | ||
Submitted: | Fri 28 Sep 2018 06:58:14 PM UTC | ||
Severity: | 3 - Normal | Item Group: | None |
Status: | Fixed | Privacy: | Public |
Assigned to: | podtelez | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Tue 30 Oct 2018 06:52:45 PM UTC, comment #14: |
Alexei Podtelezhnikov <podtelez> |
Fri 26 Oct 2018 05:56:55 AM UTC, comment #13: Yes, reverting seems to be the right solution, given the signed vs. unsigned issue is really an ABI problem.
|
Werner LEMBERG <wl> |
Thu 25 Oct 2018 06:54:06 PM UTC, comment #12: Putting this in very practical terms, bungeman is concerned because chromium/skia are
|
Alexei Podtelezhnikov <podtelez> |
Wed 24 Oct 2018 10:08:56 PM UTC, comment #11: Okay, I am re-reading comment #1. The function pointer suggestion actually doesn't quite work either - I have seen recent gcc complains about function pointer prototype mis-matches; it is bad practise to cast back and forth from (void *) so I think that gcc checking function pointer prototypes is a good thing.
|
Hin-Tak Leung <htl10> |
Wed 24 Oct 2018 03:52:52 PM UTC, comment #10: Just to restate, my issue is that "size_t is not "long" on almost any platform, "size_t" is almost always "unsigned long" (except of course on win64). The signed vs unsigned issue causes c++ compilation errors (and c warnings) even when things should technically work at the bit level. I'm currently working around this in my c++ code by extracting the correct type from the function signatures, but this is not something every c++ user is going to want to do (and I'm not sure can be done in c). |
bungeman <bungeman> |
Sat 20 Oct 2018 08:43:42 PM UTC, comment #9: The current pain is mostly because we had it as "long" for a long time, and "size_t" is what it should be, for most of the memory related routines; on almost every platform, "long" is "size_t", so specialising win64 is the least disruptive choice. I spat a lot of "#ifdef _WIN64" while I was looking at my little problem, but maybe it does not need to be ugly if it can be centralized in one place as one redefinition of FT_SIZE_T . I think I am mostly against setting it with configure.ac, etc. |
Hin-Tak Leung <htl10> |
Sat 20 Oct 2018 08:34:20 PM UTC, comment #8: I am somewhat against introducing another FT_* types, actually. Because of the overhead of putting the other stuff in, configure.ac, cmake, visual studio projects, etc. Also we have already have a lot of types which are mostly identical on most platforms, like FT_Pos/FT_26dot6/FT_ULong :-(.
|
Hin-Tak Leung <htl10> |
Sat 20 Oct 2018 05:18:59 AM UTC, comment #7: Hin-Tak, see my comment #1 :-) |
Werner LEMBERG <wl> |
Fri 19 Oct 2018 08:21:55 PM UTC, comment #6: I am okay with reverting the change. When I first reported the problems about it, it was trying to debug an issue specific to win64. I knew that changing content of a public header that has been a while is likely to cause problems.
|
Hin-Tak Leung <htl10> |
Tue 02 Oct 2018 05:54:59 PM UTC, comment #5: Experimenting with ftmemchk.c in freetype2-demos (which appears to be the one use of FT_New_Library in the repo) the difference appears to be when compiling as c++ vs c. In 'c' mode gcc and clang both warn as shown in comment #4; in 'c++' mode they both produce the same message but it is an error. It was possible to do this by taking the compile command for ftmemchk.c and replacing 'gcc' with 'g++' and '-std=c99' with '-std=c++11'. |
bungeman <bungeman> |
Mon 01 Oct 2018 06:45:47 PM UTC, comment #4: GCC gives me a WARNING, not an error, when compiling against old headers:
|
Alexei Podtelezhnikov <podtelez> |
Mon 01 Oct 2018 05:08:12 PM UTC, comment #3: Sure, hiding things was ok, but this is about changing non-hidden API.
|
bungeman <bungeman> |
Fri 28 Sep 2018 08:39:35 PM UTC, comment #2: Thank you for your support of size_t. :)
|
Alexei Podtelezhnikov <podtelez> |
Fri 28 Sep 2018 08:06:14 PM UTC, comment #1: ... so may we should indeed use FT_SIZE_T and a configuration macro to control what FT_SIZE_T actually is. |
Werner LEMBERG <wl> |
Fri 28 Sep 2018 06:58:14 PM UTC, original submission:
I use FT_New_Library specifically for using particular malloc, free, and realloc implementations. The recent change from long to size_t (877aa1b2cc662978aae61ed4d5c6ea8ba56b2fe7) for memory management causes issues for some existing code. I have a wrapper allocation function which takes 'long' which used to match the signature of FT_Alloc_Func but 'size_t' is 'unsigned long' so the compiler complains that the wrapper function doesn't match the new declaration of FT_Alloc_Func when creating a FT_MemoryRec_. If I only compile with old headers I can leave things alone, but if I want to use new headers I need to change the signature but that is incompatible with old headers. The state of the ecosystem being what it is, it's fairly required to be able to build with older headers.
|
bungeman <bungeman> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-10-30 | podtelez | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2018-09-28 | wl | Assigned to | None | podtelez |
Powered by Savane 3.13-d3ae.
Corresponding source code
Reverted.