LZ4 can't support HP arch

[GoogleCodeExporter]

1. LZ4 can't be compiled on a HP machine, I changed the code with define inline 
to NULL and use typedef instead of define BYTE or U16.
for example:
typedef unsigned char BYTE instead of the define for only GNU compilers.
2. When use compress function to compress the buffer, the program crashed.
Any suggestion?

Original issue reported on code.google.com by shangqin...@gmail.com on 6 Mar 2013 at 1:16

[GoogleCodeExporter]

There are way too many possibilities.
I think your report needs to show the full list of errors/warnings to help you 
meaningfully.

Original comment by yann.col...@gmail.com on 6 Mar 2013 at 2:24

[GoogleCodeExporter]

for type usage, following defination can't work on HP machine, because HP's cc 
has no uint8_t data type.
#else
#  include <stdint.h>
#  define BYTE  uint8_t
#  define U16       uint16_t
#  define U32       uint32_t
#  define S32       int32_t
#  define U64       uint64_t
#endif

uppers should be take instead of by typedef types.

2. after I make the upper change, program crashed at  file lz4.c:569 line.

569         if unlikely(op + length + (2 + 1 + LASTLITERALS) + (length>>8) > 
oend) return 0;        // Check output limit
570 #ifdef _MSC_VER
571         if (length>=(int)RUN_MASK)
572         {

the reason for crashing is that the pointer are not align used.
Then I google the web, found someone has solved bye use the HP cc's unalign 
library(-lunalign).
It really works, but unfortunately the program become so slowly.
It will take 3 seconds on compressing 32M data.
It only takes 1/10 seconds if normal.(at speed of 300M/s)

As a result, I have to use fastlz to take instead of lz4 on HP machine.
Still thanks your great lz4 compress method, looking forward ur letter.

Original comment by shangqin...@gmail.com on 8 Mar 2013 at 3:51

[GoogleCodeExporter]

The issue reported is a bit strange.

> program crashed at  file lz4.c:569 line.

Line 569 is a comparison operation, between 2 pointer addresses.
Even if they were pointing into a NULL area or outside of allocated memory 
area, it should work appropriately, since no operation is done (neither read 
nor write) on the content being pointer at.
Therefore, even if the pointer are not aligned, the pointer comparison should 
happen appropriately.

Original comment by yann.col...@gmail.com on 14 Mar 2013 at 10:19

[GoogleCodeExporter]

The following release candidate is expected to help compiling and running on 
HP-UX systems. Basic Types definition is a bit cleaner, and unaligned memory 
access is now compatible with older GCC versions.

Original comment by yann.col...@gmail.com on 16 May 2013 at 9:13

Attachments:

• lz4rc.zip

[GoogleCodeExporter]

Right, thanks Arseny. I'm amazed this warning did not show up in any of my 
compiler settings up to now. Maybe I need to increase the warning level.

Original comment by yann.col...@gmail.com on 16 May 2013 at 8:03

• Changed state: Accepted
• Added labels: Priority-Medium
• Removed labels: Priority-minor

[GoogleCodeExporter]

Supposed to be corrected into r95 (but a real test would have helped)

Original comment by yann.col...@gmail.com on 17 May 2013 at 6:47

• Changed state: Fixed