ByteOrder C2131 compile error

Windows
1

I just updated my JUCE code to include this commit:

and I’m getting a compile time error I wasn’t getting before with Visual Studio 2015 (XCode is fine)…

1>c:\users\railjonrogut\documents\juceprojects\railfork2\jucelibrarycode\modules\juce_core\memory\juce_byteorder.h(203): error C2131: expression did not evaluate to a constant
1>  c:\users\railjonrogut\documents\juceprojects\railfork2\jucelibrarycode\modules\juce_core\memory\juce_byteorder.h(203): note: failure was caused by out of range index 5; allowed range is 0 <= index < 5
1>c:\users\railjonrogut\documents\juceprojects\railfork2\jucelibrarycode\modules\juce_core\memory\juce_byteorder.h(204): error C2131: expression did not evaluate to a constant
1>  c:\users\railjonrogut\documents\juceprojects\railfork2\jucelibrarycode\modules\juce_core\memory\juce_byteorder.h(204): note: failure was caused by out of range index 7; allowed range is 0 <= index < 7

Possibly related to:

https://developercommunity.visualstudio.com/content/problem/171482/c2131-error-when-defining-struct-inline-with-const.html

Rail

1 Like
2

That does look like a compiler bug to me!

Is it being triggered in your code because you’ve got a constexpr value somewhere that uses littleEndianInt64?

3

I’ll see if I can isolate where it’s being called… I verified it also happens in VS 2017 BTW.

Cheers,

Rail

4

Yes, It’s being used in my custom audio file FlaxAudioFormat.cpp

namespace FlaxAudioFormatHelpers
{
    static const char* const name       = "FLAX file";
    static const char* const extension  = ".flax";
    static const int64 fileHeader       = (int64) ByteOrder::littleEndianInt64 ("flaX");
    static const float flaxVersion      = 1.1f;
}

and also:

namespace FloatAudioFormatHelpers
{
    static const char* const name       = NEEDS_TRANS ("RawFloat file");
    static const char* const extension  = ".rawfloat";
    static const int64 fileHeader       = (int64) ByteOrder::littleEndianInt64 ("RAWFLT");
}

Rail

5

Well that’s actually a legitimate error then!

To make a 64-bit integer, it obviously expects an 8-byte block of memory, but you’re only giving it a 5-byte literal, so the compiler’s totally correct about it being wrong!

Are you sure other compilers don’t also throw an error??

6

changing

static const int64 fileHeader       = (int64) ByteOrder::littleEndianInt64 ("RAWFLT");

to

auto fileHeader       = (int64) ByteOrder::littleEndianInt64 ("RAWFLT");

fixes the problem.

I noticed the FLAX issue… but I’m not using the header variable in the code, so I dropped that from the code – changing it to an int and using littleEndianInt() gave the same issue BTW. I had no issues with Xcode.

Rail

7

Well, I’ve no idea why ‘auto’ would make any difference there!

The correct fix would be to do something like

ByteOrder::littleEndianInt64 (“flaX\0\0\0\0”)

(or put the zeros at the start, depending on what you actually want the data to look like)

8

Yeah… I tried “flaX____” and it gave the same error (where I used spaces to make it 8 characters)

Rail

9

Hmm, I’m sceptical about that. The error is very clearly saying that you’ve given it too little data. Maybe you fixed one place where you did this, but still had others in your codebase which also triggered the same thing?

10

Right – I did a clean and added the “flaX…” back in and it compiles fine.

This is a separate JUCE project in the solution and is used in my custom module… I searched the code for all occurrences… and when I dropped the flaX line and switched the other to auto it compiles without error.

I’m not actually using the FloatAudioFormat in my plug-in… so changing the line to auto will let me compile, but I won’t be able to ascertain if there are any ill affects right away. I suspect I’ll need to add spaces for the (int64) ByteOrder::littleEndianInt64 (“RAWFLT…”) too.

Cheers,

Rail

11

TBH the fact that it compiles with auto really sounds like a compiler bug to me - if you’re passing it “RAWFLT” then it really should fail…

12

Agreed. I’ll change the header to 8 characters… since it’s not anything I’m actively using, the change will be fine.

Thanks,

Rail