Machine readable function/enum specs?

Is there any canonical set of machine readable info on function signatures, enum values, etc. for OpenGL and extensions?

Closest I’ve found so far is the *.spec files from , but they seem to be out of date by a few extensions. Is there a new site for these, or are they no longer being updated?

Also tried using the files GLEW uses to generate its header, but they seem to be missing a few functions as well (PointParameteri[v] so far, but haven’t gone looking for others)

This is now the up to date extension registry :

But not .spec :frowning:

I just did some updates to the registry. It now includes the gl.spec / enum.spec / enumext.spec files which are the database from which glext.h is generated. Go to and look under the “Enumerant and Function Registry” subhead.

Jon Leech

Great !

In glext.h in the GLEXT_64_TYPES_DEFINED section

inttypes.h and stdint.h do not exist in Win32 when using visual studio compilers/platform and there doesn’t seem to be a specific _WIN32/WIN32 ifdef/defined to catch that.

Originally posted by GuybrushThreepwood:
[b] In glext.h in the GLEXT_64_TYPES_DEFINED section

inttypes.h and stdint.h do not exist in Win32 when using visual studio compilers/platform and there doesn’t seem to be a specific _WIN32/WIN32 ifdef/defined to catch that. [/b]
I think that’s fixed now - please let me know if the current version is still broken. Also if there is an int64_t defined anywhere in the Visual Studio headers, please point me to it so I can clean up the header a bit.

I had a look around and it seems there is a type for 64bit built into the Visual Studio which is __int64. The closest definition to int64_t I’ve found, is in a file in the platform sdk called basetsd.h, which has the types…

typedef signed __int64 INT64, *PINT64;
typedef unsigned __int64 UINT64, *PUINT64;

I’ll test out the new glext.h when it refreshes on the site, doesn’t seem to of updated yet.

Edit Ahh I see you used the __int64, new header works fine now.

Jon Leech, I’d like to bring to your attention some errata that exist in the spec files since December 2001. Detailed information and patches exist here .

I’ve encountered these problems while writing a set of bindings for use with the .Net/Mono CLR. While these will not really affect a C or C++ program (since all constants are just #defined), they do hinder stricter type checking for languages that support it (i.e. you should only be able to pass a BeginMode value to glBegin and not a LightParameter). Moreover it would be helpful to have some official documentation on the data contained in the spec files (what exactly does each parameter mean), as this would ease the creation of bindings for different programming languages.

Last, but not least, is an xml based format planned for the spec files in the near future, or is it more of a long-term goal?

The XML format is a longer-term thing. Mesa has a DTD they use but it is a custom effort; what I’d really like is something that fits into the Docbook 4.5 schema, to go with updates to the documentation infrastructure. Just haven’t had time to work through that.

There really isn’t any design documentation on the .spec file format. It is something that grew organically at SGI starting in the late 1980s and the scripts are all there is. Most of the fields are fairly self-explanatory and you can ask questions if something is unclear.

I’ll take a look at the Haskell patches after getting back from the Khronos meeting next week. I think some of them have been incorporated since those patches were written up. It’s also hard to completely classify all the enumerants because some tokens get reused for completely different purposes in different functions, and/or subsets of a group are accepted in different calls (this happens a lot with pixel format tokens, for example). Also because it requires coming up with a lot of different labels to categorize different tokens. I have not put the complete specfile infrastructure up in the registry, just the database files, although what’s on the old site is only a little out of date at this point. If people want those scripts as well, I’ll look into mirroring more of the internal Khronos Subversion infrastructure to the public registry.

Ideally we could make a subset of the tree publically accessible, but I don’t think the web infrastructure is ready for that yet - lots of behind the scenes work going on with and at present.

The partitioning of enum.spec / enumext.spec is because they serve different purposes - enum.spec is the official registry of what enum blocks are assigned to what vendors, while enumext.spec groups the tokens by the extension they belong to rather than by their numeric value. enumext.spec exists only to generate glext.h at the moment. In happy future XMLized land, there would be a single file containing the entire API registry, and some XSLT or other processing script that can pick off the right elements and sort / combine them as needed for different purposes. But we’re a long way away from that.