c - 是否允许这种枚举构造和赋值？

Question

这能在 Linux GCC 下编译并工作吗？

在 Github 托管的 LoRa 网关堆栈中，我在 loragw_hal.h 中发现了以下构造

enum lgw_radio_type_e {
    LGW_RADIO_TYPE_NONE,
    LGW_RADIO_TYPE_SX1255,
    LGW_RADIO_TYPE_SX1257
};

#define LGW_RF_CHAIN_NB     2   /* number of RF chains */

然后在 loragw_hal.c

static enum lgw_radio_type_e rf_radio_type[LGW_RF_CHAIN_NB];

编辑:数组未在代码中的任何位置初始化

然后在函数中

setup_sx125x(uint8_t rf_chain, uint32_t freq_hz)

以下 switch 语句用于根据 rf_chain 参数选择 rf 链

switch (rf_radio_type[rf_chain]) {
    case LGW_RADIO_TYPE_SX1255:
        // some code
        break;
    case LGW_RADIO_TYPE_SX1257:
        // some code
        break;
    default:
        DEBUG_PRINTF("ERROR: UNEXPECTED VALUE %d FOR RADIO TYPE\n", 
        rf_radio_type[rf_chain]);
        break;
}

当函数被调用时，rf_chain 参数设置为 1，当然它会选择默认的错误“unexpected rf chain”。

版权所有者 Semtech Inc. 支持，如果您对其产品有任何问题，始终指向此代码，作为引用。

但我有一种感觉，如果不进行任何修改，这段代码无论如何都不会运行。

所以我对论坛的问题是，除了上面的这个构造没有真正意义之外，这不是一个错误的构造吗？

这能在 Linux GCC 下编译并工作吗？

我尝试在 GCC ARM 下使用此代码，但它没有像计划的那样工作。

Answer 1

您似乎试图引起人们的注意:

enum lgw_radio_type_e {
    LGW_RADIO_TYPE_NONE,
    LGW_RADIO_TYPE_SX1255,
    LGW_RADIO_TYPE_SX1257
};

#define LGW_RF_CHAIN_NB     2   /* number of RF chains */

[...]

static enum lgw_radio_type_e rf_radio_type[LGW_RF_CHAIN_NB];

[...] the array is not initialized at any place in the code

数组未显式初始化并不是一个特殊的问题。如果未提供显式初始化程序，文件范围变量(和 static block 范围变量)将受到默认初始化的影响。在这种情况下，数组声明相当于

static enum lgw_radio_type_e rf_radio_type[2] = {
        LGW_RADIO_TYPE_NONE, LGW_RADIO_TYPE_NONE
    };

这本身似乎是很明智的。

你接着说，

[...] when the function is called, and it selects the default Error 'unexpected rf chain' of course.

我没有看到任何理由期望选择不同的案例，但我也没有看到任何理由假设不会选择不同的案例。也不清楚在什么情况下switch本身完全被执行。

人们通常会期望 rf_radio_type 中的一个或两个元素如果实际上存在相应的硬件，则在驱动程序初始化期间设置。如果整体代码(不仅仅是您提供的部分)是正确的，那么它可能不会执行提供的 switch当rf_radio_type[rf_chain]具有与 LGW_RADIO_TYPE_SX1255 不同的值和LGW_RADIO_TYPE_SX1257 。另一方面，打印错误消息本身本质上是无害的；如果驱动程序打印它，那么这可能只是一个实现质量问题，而不是功能缺陷。

So my question to the forum here is, aside from that this construct above makes not really sense, is that not a faulty construct anyway ?

不，不是。据我所知，所有提出的结构在脱离上下文时都具有预期的意义。

Will this compile and work as meant under Linux GCC ?

您提供了几个单独有效的 C 片段，但它们不能一起构成有效的翻译单元。可以形成一个完整、有效的翻译单元，其中包含所有那些将成功编译并绝对可以执行任何操作的片段。这些片段本身不会干扰编译，也不一定会导致故障。

I try to use this code under GCC ARM and it does NOT work as it seems to be planned.

我发现您对整个代码的预期行为的评估显然有信心有点乐观。