You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 6517 Reporter: Richard Jones Status: closed (set by @xavierleroy on 2016-12-07T10:34:40Z) Resolution: fixed Priority: normal Severity: minor Version: 4.02.0+beta1 / +rc1 Target version: 4.03.0+dev / +beta1 Fixed in version: 4.03.0+dev / +beta1 Category: runtime system and C interface Related to:#4164#4877 Monitored by:@hcarty
Bug description
Headers like <caml/config.h> define a number of types without
a caml_ prefix. Unfortunately these types have very generic names
like "int64" which clash with other headers which also define these
types.
As an example it is not possible to combine the headers:
#include <caml/config.h>
#include <tiffio.h>
which currently causes compilation problems in camlimages.
Note that it is illegal to define any identifier ending in *_t in C99.
All of these are reserved for C. (http://stackoverflow.com/a/228797)
The full list of problematic types is:
int32 defined in caml/config.h
uint32 defined in caml/config.h
int64 defined in caml/config.h
uint64 defined in caml/config.h
asize_t defined in caml/misc.h
header_t defined in caml/mlvalues.h
mlsize_t in caml/mlvalues.h
tag_t in caml/mlvalues.h
color_t in caml/mlvalues.h
mark_t in caml/mlvalues.h
opcode_t in caml/mlvalues.h
intnat in caml/config.h
uintnat in caml/config.h
value in caml/mlvalues.h
Of these, int32, uint32, int64 and uint64 are the most problematic, and
seem to be the ones which could be changed with little effort. OCaml
should use the standard C99 types like int32_t etc.
The *_t typedefs are illegal as noted above.
Likely it will be impossible to get rid of value since it is used all
over the place by OCaml bindings.
I agree that we should change int32, uint32, int64 and uint64 to their C99 equivalents (with the usual hacks for MSVC). I'm afraid we have to live with the other types for backward compatibility: changing e.g. "value" would break a zillion Caml-C stub codes.
The change still breaks Caml-C stub around. For instance, in camlzip, there is a reference to uint32 which needs to be changed to uint32_t. OPAM will hopefully allow us to identify quickly all packages that need to be updated.
Yup a few packages need updating. Fedora has integrated this patch into our OCaml 4.02.0 release, and have patched a few packages as a result. I've sent the patches upstream, where I can easily find an upstream contact, but you can also check our git repo for each package, eg:
Original bug ID: 6517
Reporter: Richard Jones
Status: closed (set by @xavierleroy on 2016-12-07T10:34:40Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.0+beta1 / +rc1
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: runtime system and C interface
Related to: #4164 #4877
Monitored by: @hcarty
Bug description
Headers like <caml/config.h> define a number of types without
a caml_ prefix. Unfortunately these types have very generic names
like "int64" which clash with other headers which also define these
types.
As an example it is not possible to combine the headers:
#include <caml/config.h>
#include <tiffio.h>
which currently causes compilation problems in camlimages.
Note that it is illegal to define any identifier ending in *_t in C99.
All of these are reserved for C. (http://stackoverflow.com/a/228797)
The full list of problematic types is:
Of these, int32, uint32, int64 and uint64 are the most problematic, and
seem to be the ones which could be changed with little effort. OCaml
should use the standard C99 types like int32_t etc.
The *_t typedefs are illegal as noted above.
Likely it will be impossible to get rid of value since it is used all
over the place by OCaml bindings.
Steps to reproduce
To get a list of types defined by a header, do:
echo '#include <caml/config.h>' > types.c
gcc -c types.c -fdump-ada-spec
and then examine the *.ads files in the current directory.
The text was updated successfully, but these errors were encountered: