search for: jerker

> Err, no it wouldn't. In fact this example you gave only confuses > the matter. ? What do you mean? typedef struct { FLAC__uint32 length; FLAC__byte *entry; } FLAC__StreamMetadata_VorbisComment_Entry; Can you confirm that the entry member is a pointer and not a byte array? In that case: What happens if the compiler expands the size of the structure twice (8=>16 bytes)? I

Hello all, I get unresolved external symbol __muloti4 when attempting to compile GNU m4 for Windows commandline. See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22 Looking into this, I see that some parts of compiler-rt are disabled for Windows due to the __LP64__ define. The code seem not portable as is to the MS compiler, but according to my tests the code compiles and links

...(understood by most compilers) #pragma pack(push,4) FLAC_structures ... #pragma pack(pop) That is, retain 32-bit packing of structures even on 64-bit. But I wonder if this is enough to keep compatibility with FLAC files created in 32-bit, 64-bit pointers are still 8-bit. Ideas, anyone? Cheers Jerker

Erik, thanks for the swift answer. Your right, I haven't seen any issues yet. But it a thought stroke me when implementing edit capabilities of FLAC vorbis comments. I've already implemented reading vorbis comments from FLAC files in 64-bit and it works without any issues. This now leave me a bit confused, since it should have issues(!). Using the MS 64-bit compiler on Windows 7/2008R2

I know that this is not the appropriate place :). You know someone can alternative to gluserfs ?:) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090107/63b68a0d/attachment.html>