[m-users.] Lessons to learn from that supposed compiler bug

Hi.

What happened? I got the following from the compiler. It looked like a
compiler bug:

Mercury/cs/worker.c:236:1: error:
‘mercury_data_thread__semaphore__type_ctor_info_9_0’ undeclared here (not in
a function); did you mean
‘mercury_data_thread__semaphore__type_ctor_info_semaphore_0’?

I had this in a different one of my modules, which was imported by the first
one:

:- pragma foreign_decl("C", "
#define regular_file     1
#define directory        2
#define symbolic_link    3
#define named_pipe       4
#define socket           5
#define character_device 6
#define block_device     7
#define message_queue    8
#define semaphore        9
#define shared_memory    10
#define unknown          11
").

The reason of the problem was, that the definition of "semaphore" interfered
with what the compiler was doing.

After I changed it to the following, the supposed compiler bug went away
(thanks to Zoltan!):

:- pragma foreign_decl("C", "
enum {
    regular_file     = 1,
    directory        = 2,
    symbolic_link    = 3,
    named_pipe       = 4,
    socket           = 5,
    character_device = 6,
    block_device     = 7,
    message_queue    = 8,
    semaphore        = 9,
    shared_memory    = 10,
    unknown          = 11
};
").

What should be learned from this?

- Don't use macros for enumerations! Unfortunately, it's common to do so.
For instance, the ODBC standard defines a large number of macros for things
like return codes, SQL data type numbers and such. Use an "enum {...}"
instead. 

- Avoid macros when possible (for enumerations or otherwise). When you must
use macros, write them in capital letters and add a prefix.

- More?

Regards,
Volker
_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users