Amiga C - BPTR vs. int32_t - different results regarding size of variable

[Apollo]

hello,
well I could probably ignore this since I know how to get around this but I really want to understand what is happening here. I guess I am doing things wrong but I'm really not sure where.
I made up a small example showing my issue. Let's assume we have 3 files


main.c

#include <proto/exec.h>
#include <proto/dos.h>
#include "types.h"

#define __NOLIBBASE__
struct Library *DOSBase;

extern BPTR con;
extern void init_con(void);

__saveds
int main (void){
    if (DOSBase =  OpenLibrary ("dos.library",0L)){
        init_con();
        Write(con,"Hello, world!\n",14); 
        CloseLibrary (DOSBase);
    }

    return (RETURN_OK);
 }

dos.c

#include <proto/dos.h>
#include "types.h"

BPTR con;

void init_con(void)
{
    con = Output()
 }

and the include "types.h"

typedef unsigned int uint32_t;
typedef signed int int32_t;

both files will be compiled using a Makefile which executes the following commands

/opt/vbcc/bin/vc +kick13sm -g -sc -sd -c99 -I/opt/NDK_3.9/Include/include_h -o "build/dos.o" -c dos.c
/opt/vbcc/bin/vc +kick13sm -g -sc -sd -c99 -I/opt/NDK_3.9/Include/include_h -o "build/main.o" -c main.c

we're in small code and small data model and C99 mode
the C compiler is vbcc V0.9g


in my project I started using the portable data types like 'uint16_t' etc. When I compile the above example with

int32_t con;

the resulting executable will store the result of the DOS call Output() as a word ('move.w d0,_con(a4)'). As well as accessing the variable 'con' will be a 16-bit access in this case.
When I declare 'con' as a BPTR (which is in dos.h a 'typedef long BPTR;') then the result is a 32 bit access in storing and loading (as expected).

BPTR con;

One could argue that I should declare the console handler as a 'BPTR' anyway. Besides that I do not get my head around why a variable declared as a int32_t (which is a 'signed int') will result in a 16 bit integer where a 'long' will result in a 32 integer since both are 32 bit wide (according to vbcc's manual).

[jotd]

with "stdint.h" included (and not a custom types.h file), int32_t is guaranteed to be 32 bits. So if the compiler produces a move.w from that, then there's a problem!

I suspect that "int" is 16 bit. Then your definitions are wrong

typedef unsigned int uint32_t;
typedef signed int int32_t;

You can't assume the lengths of int/long/... in this case int is probably 16 bits (like old Borland compilers which tried to save memory). That's why stdint.h was created and depends on the compiler.

If stdint.h isn't available, try to print sizeof(int) and sizeof(long). Then maybe change int by long and you're okay (create your own version of stdint.h after having checked what the compiler does)

[patrik]

vc +kick13s/kick13sm gives 16-bit int, so as already said, the definitions for uint32_t and int32_t is wrong.

[Apollo]

Thank you, guys. Learned more than I was asking for. I was mislead by this table here (ABI 4.2, down to the end of the chapter).

[phx]

I admit it is confusing, and this is certainly my fault.

From Apollo's reaction I assume that he didn't expect the

kick13sm

config file to enable 16-bit int. He probably thought that the 's' stands for small code/data, which is also used here.

It adds to the confusion that small data linker libs have an 's' appended:

vcs.lib

,

amigas.lib

,

m881s.lib

.

But for the config files the 's' stands for "short int" (16-bit), as the 16-bit version of the m68k compiler backend is also called

vbccm68ks

instead of

vbccm68k

(default, 32 bit int).

The choice of the data model doesn't need a different config file. Just add

-sc

and/or

-sd

as you need it. But for small-data don't forget to link with the correct libraries:

-lvcs

is required to override the

-lvc

from the config file.

At last: As you already enabled C99, please feel free to include

<stdint.h>

which might replace your own

types.h

.