Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It would be nice if <caml/*.h> didn't define types like "int64" #6517

Closed
vicuna opened this issue Aug 20, 2014 · 4 comments

Comments

Projects
None yet
1 participant
@vicuna
Copy link

commented Aug 20, 2014

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.

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Aug 26, 2014

Comment author: @xavierleroy

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Aug 27, 2014

Comment author: @xavierleroy

Commit 15131 in SVN trunk uses <stdint.h> plus int32_t, etc instead of int32, etc.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 2, 2014

Comment author: @alainfrisch

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 2, 2014

Comment author: Richard Jones

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:

http://pkgs.fedoraproject.org/cgit/ocaml-ocamlnet.git/tree/

(replace ocaml-ocamlnet with Fedora package name)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.