0

Hello currently im trying to make a gaussian function in NASM, but when I try to compile it so I can use this function in C, I get an error..

The error I get:

ISO C does not support the 'I64' ms_printf length modifier [-Wformat=]

My NASM code:

global gauss
section .text
gauss:
        mov rax, rdi
        imul rax, rax
        add rax, rdi
        mov dl, 2
        div dl
        ret

My gauss.c file:

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <inttypes.h>

#define RED     "\033[31m"
#define DEFAULT "\033[39m"

#define BOLD    "\033[1m"
#define RESET   "\033[0m"

extern uint64_t gauss(uint64_t n);

int main(int argc, char* argv[]) {
    if(argc < 2) {
        fputs(BOLD RED "Not enough arguments!\n" RESET, stderr);
        return EXIT_FAILURE;
    }

    char* test = NULL;
    uint64_t val = strtoull(argv[1], &test, 10);
    if(*test) {
        fprintf(stderr, BOLD RED "Invalid Argument: %s\n" RESET, argv[1]);
        return EXIT_FAILURE;
    }

    uint64_t res = gauss(val);
    printf("gauss(%"PRIu64") = %"PRIu64"\n", val, res);

    return EXIT_SUCCESS;
}

The commands I typed in:

> nasm -f elf64 gauss.asm
> gcc -std=c11 -Wall -Wextra -pedantic -O2 -o prog gauss.c
gauss.o
Michael Petch
  • 46,082
  • 8
  • 107
  • 198
reByte
  • 83
  • 7
  • Are you sure that's the right `printf` placeholder notation? – tadman Nov 02 '17 at 17:12
  • WHat version of GCC are you using/ Is this MinGW? – Michael Petch Nov 02 '17 at 17:20
  • tried on my Fedora 26 x64, works (gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) – OznOg Nov 02 '17 at 17:22
  • 2
    My guess this is on Windows with a GCC that is using MSVCRT (microsoft C runtime) which is only C89 compliant. The usage of PRIu64 is not available in that library so the compiler is warning. I would suggest trying `%I64u` instead. – Michael Petch Nov 02 '17 at 17:25
  • your are probably right see https://stackoverflow.com/questions/44382862/how-to-printf-a-size-t-without-warning-in-mingw-w64-gcc-7-1 that prints the same error – OznOg Nov 02 '17 at 17:31
  • 1
    You realize the issue is not in the assembly part, right? Your whole title and question is misleading. – Jester Nov 02 '17 at 17:33
  • @MichaelPetch I think the problem is the reverse, the code is using msvcrt specific format but OP is using linux. Notice the `-f elf64` and also your linked duplicate says how you should use the `PRIu64` instead of `zu` when on mingw. So the solution is to use `zu` :) – Jester Nov 02 '17 at 17:44
  • @Jester might want to look at the additions as of C99: http://en.cppreference.com/w/c/types/integer (under Format constants for the fprintf family of functions) . He's using C11 which these format specifiers should exist in, but the compiler is warning him that the microsoft C runtime probably doesn't support it. – Michael Petch Nov 02 '17 at 17:45
  • I will agree the duplicate I gave is not quite the same so removed it. However the formatting he is using is C11 conforming. – Michael Petch Nov 02 '17 at 17:52
  • Anyway, OP may still be on windows because the `-f elf64` would only error during linking and he is not there yet. PS: it's very bad idea to name both files `gauss` as the object file names will be the same. – Jester Nov 02 '17 at 17:52
  • 1
    @Jester : See my comment above your about the dupe – Michael Petch Nov 02 '17 at 17:52
  • 1
    If you want to avoid using MSVCRT you could also place this above all includes in your file: `#define __USE_MINGW_ANSI_STDIO 1` This should force MinGW to use its own stdio which supports the format specifiers you are expecting.You could also compile with the option `-D__USE_MINGW_ANSI_STDIO=1` instead. – Michael Petch Nov 02 '17 at 18:00
  • 1
    As Jester points out using `-felf64` will not work as MinGW doesn't understand elf objects. You can use `-fwin64` and then link against `gauss.obj` . – Michael Petch Nov 02 '17 at 18:57
  • @reByte: you probably want `shr rax,1` to divide RAX by 2. I assume you don't actually want to set `al = ax/2` and `ah = ax%2` (and fault with #DE if `AX/2 > 255`), all of this while leaving the upper 48 bits of RAX unmodified. – Peter Cordes Nov 02 '17 at 19:40

0 Answers0