The suffix .s is the default extension for assembly code used by the GNU tool-chain. GCC outputs foo.s out of foo.c if the command-line option -S is selected. The GNU Assembler (GAS), which reads the .s file as input, expects Python-style comments (in x86 platform). Also, GAS manual recommends .s (lowercase) for compiler-generated code, and .S (uppercase) for human-written code.
On the other hand, the suffix .asm is commonly used for assembly code meant for the NASM assembler, which uses Lisp-style comments.
Currently, reuse treats .s files as if they were in NASM syntax, and by add lisp-style comments, causes projects that rely on the GNU tools fail to build.
Suggestion: it might be more intuitive and practical for most programmers if
.s and S were reserved for GCC/GAS asembly (usually AT&T syntax), Python-style comment
.asm were reserved for NASM assembly code (Intel syntax), Lisp-style comment
The suffix
.s
is the default extension for assembly code used by the GNU tool-chain. GCC outputsfoo.s
out offoo.c
if the command-line option-S
is selected. The GNU Assembler (GAS), which reads the.s
file as input, expects Python-style comments (in x86 platform). Also, GAS manual recommends.s
(lowercase) for compiler-generated code, and.S
(uppercase) for human-written code.On the other hand, the suffix
.asm
is commonly used for assembly code meant for the NASM assembler, which uses Lisp-style comments.Currently,
reuse
treats.s
files as if they were in NASM syntax, and by add lisp-style comments, causes projects that rely on the GNU tools fail to build.Suggestion: it might be more intuitive and practical for most programmers if
.s
andS
were reserved for GCC/GAS asembly (usually AT&T syntax), Python-style comment.asm
were reserved for NASM assembly code (Intel syntax), Lisp-style comment