BYTE is predefined by some compiler #258

New issue

Closed

opened 2019-09-26 11:25:13 -05:00 by svorkoetter · 4 comments

svorkoetter commented

2019-09-26 11:25:13 -05:00

(Migrated from github.com)

One of the targets with which we wish to use xxHash requires compilation with a very old version of MSVC++ (Visual Studio 6), which defines a type named BYTE. This conflicts with xxHash. I've gotten around it for now by renaming xxHash's BYTE to XXBYTE. Perhaps this can be addressed officially in the sources?

Also, _byteswap_ulong is not supported by that version of MSVC++ either.

👍 1

Cyan4973 commented

2019-09-26 11:56:49 -05:00

(Migrated from github.com)

Is the build macro XXH_INLINE_ALL used ?

Is the build macro `XXH_INLINE_ALL` used ?

svorkoetter commented

2019-09-26 14:19:42 -05:00

(Migrated from github.com)

Yes. I've only tried XXH_INLINE_ALL.

👍 1

easyaspi314 commented

2019-09-26 20:58:03 -05:00

(Migrated from github.com)

What about U8?

I mean, it is more consistent.

typedef uint64_t U64; /* duck */
typedef uint32_t U32; /* duck */
typedef uint8_t BYTE; /* goose */

What about `U8`? I mean, it *is* more consistent. ```c typedef uint64_t U64; /* duck */ typedef uint32_t U32; /* duck */ typedef uint8_t BYTE; /* goose */ ```

Cyan4973 commented

2019-09-26 23:15:44 -05:00

(Migrated from github.com)

The problem now is the genericity of some names.
Not just BYTE or U8 by the way, but also U32 and U64.

While these names were in use within xxhash.c which was compiled separately, there was no issue.
But now that the tendency is to rather inline it, too generic names increase risks of name collisions.

So we need names which have less chances to be also present in host's code.
Maybe xxu8, xxu16, etc.

note : also use this opportunity to properly link with types already declared in xxhash.h: XXH32_hash_t and XXH64_hash_t.

The problem now is the genericity of some names. Not just `BYTE` or `U8` by the way, but also `U32` and `U64`. While these names were in use within `xxhash.c` which was compiled separately, there was no issue. But now that the tendency is to rather inline it, too generic names increase risks of name collisions. So we need names which have _less_ chances to be also present in host's code. Maybe `xxu8`, `xxu16`, etc. note : also use this opportunity to properly link with types already declared in `xxhash.h`: `XXH32_hash_t` and `XXH64_hash_t`.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Cyan4973/xxHash#258

No description provided.

Rows
Columns