[m-users.] Lessons to learn from that supposed compiler bug
Volker Wysk
post at volker-wysk.de
Wed Jan 10 21:01:22 AEDT 2024
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
More information about the users
mailing list