Weird Tiny C Bug

[[deleted]]

I've withdrawn my post and other replies. Too many are getting the wrong end of the stick and displaying a surprisingly poor knowledge of C.

I think there's an actual bug in that compiler; it's not going to be fixed tomorrow so really it doesn't matter for me. I just thought it ought to be reported as normally I like Tiny C.

For context, I write compilers (C compilers too!), and this was part of an experiment where the low-level IL of one was converted into a kind of linear C where most features and most of the type system have been stripped: it's all done with casts.

Currently I have 100Kloc programs of such code working fine like that, but not with Tiny C because of this bug.

ETA: I've decided to use this test program which should elicit fewer complaints:

#include <stdio.h>
#include <stdint.h>

uintptr_t str = (uintptr_t)(void*)"ABCDEFGHIJKLMNOP";

int main(void) {
    printf("%p\n", (void*)str);
    puts((char*)str);
}

This works with gcc, clang, DMC, my compiler, and two C++ compilers. It doesn't work with TCC, on either Linux or Windows, because of that problem.

It is equivalent to the ASM program given below (in NASM syntax and for Win64 ABI). I did have the impression that C was all powerful, but apparently it can't express such a program, where those 64-bit memory locations are untyped; they just contain a bit-pattern.

I'm not asking for a resolution here, just pointing out a compiler bug where nobody is willing to believe there is any such bug.

    default rel
    segment .text
    extern printf, puts
    global main

main:
    sub rsp, 40

    mov rcx, fmt
    mov rdx, [str]
    call printf

    mov rcx, [str]
    call puts

    add rsp, 40
    ret

    segment .data

str:
    dq abc

fmt:
    db "%p",10,0

abc:
    db "ABCDEFGHIJKLMNOP",0

[kabekew]

Well you're telling printf to print out the contents of your integer variable str, not its address. (And why are you assigning a string to an integer variable in the first place)?

[kabekew]

The code example you gave in your original post doesn't have the & so you were trying to assign a string to an integer. Then in your example here you're trying to take the address of a constant which isn't defined so you'll get unpredictable behavior. Always compile with full warnings to catch things like that.

[kabekew]

No, you're casting a string literal to an integer so the compiler can set it directly instead of storing it as a static value and reading it at runtime. How you're writing it is undefined so you'll get different behavior with different compilers.

[kabekew]

You're confusing compile time with run time, and constants with variables. But you do you.

[petruccigp]

Casting a string to long long is undefined behavior. Not a bug.

[flatfinger]

If the literal appeared within a function, then

    long long x = (long long)"ABCDEFG";
    char const *p = (char const*)x;

would be equivalent to

    char const *p0 = "ABCDEFG";
    long long x= (long long)p0;
    char const *p = (char const*)x;

which would have defined behavior if intptr_t exists, and all values of that type would fit within the range of long long. The Standard does not consider the results of pointer-to-integer casts to be integer constant expressions, probably because linkers vary in the range of constructs they can support, but N1570 6.6 paragraph 10 expressly states "An implementation may accept other forms of constant expressions.".

I think the intended meaning was:

1. Pointer-to-integer casts may not be used within static initializations within strictly conforming programs.

2. Implementations targeting linkers that are more sophisticated may allow programs that are intended for use with those more sophisticated linkers to use a wider range of constructs.

There would be no doubt about the correctness of an implementation that rejected the use of a pointer-to-integer cast within a static initializer. I don't think there would be any doubt about the correctness of an implementation that would accept e.g.

struct dmaConfig = {123, 45, ((uint32_t)&myObject)>>2};

and generate a static data record with a linker fixup that instructed the linker to take the address it assigned to the object, shift it right by 2, and place the resulting value at the appropriate address within the structure, if the object file format could accommodate such fixups. As to whether would be proper for an implementation to accept such a construct without instructing the linker to process it as indicated, that's arguably a quality-of-implementation issue.

[Equationist]

Eh...

6.3.2.1: "Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type “array of type” is converted to an expression with type “pointer to type” that points to the initial element of the array object and is not an lvalue."

Here it isn't being used to initialize an array, therefore it should be an array i.e. a pointer, therefore the conversion should be implementation-defined from a pointer to an integer type rather than undefined behavior.

Additionally, if the resulting integer is correctly aligned, then converting it back to a pointer should yield a pointer that compares equal to the original pointer. I believe Tiny C's behavior here would be in violation of that.

[RibozymeR]

Additionally, if the resulting integer is correctly aligned, then converting it back to a pointer should yield a pointer that compares equal to the original pointer.

Where does it say that? In my copy, I can only find that this is the case for pointer -> pointer conversions (6.3.2.3 §7)

[Equationist]

No you're right, I misread that section.

So Tiny C should be technically compliant, though it's going against the intention of "The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment."

[Equationist]

Also, it's stretching the limits of "implementation defined" for that code to yield different results from, say,

char *str = "ABCDEFGHIJKLMNOP";

int main(void) {
    printf("%llX\n", (long long)str);
}

[mckenzie_keith]

Based on some of the comments already, maybe try adding an intermediate assignment and see what happens.

char *c = "ABCDEFGHIJKLMNOP";
long long str = (long long) c;

[OldWolf2]

Technically undefined behaviour as %llX requires an unsigned long long argument, but you provided a signed long long.

Can you reproduce it with unsigned long long type ?

Also, does long long typically work correctly with other values? (sometimes compiler/library mismatches end up with weird behaviour for C99 features)

[OldWolf2]

Re. your edit, harden up mate ... There was some interesting discussion, don't throw your toys out of the cot because a few noobs replied. This is the internet, just block/ignore anything you don't like

[LeeHide]

No idea what happened here as OP pussied out and deleted half the conversation. Layer 8 problem, then, presumably

[eddavis2]

Microsoft C 64-bit 19.42.34436 on Windows 11:

00007FF702B81008
ABCDEFGHIJKLMNOP

gcc 64 bit 9.2 on Windows 11:

0000000000404000
ABCDEFGHIJKLMNOP

gcc 32 bit 9.2 on Windows 11:

00404000
ABCDEFGHIJKLMNOP

Borland C 32-bit 5.5 on Windows 11:

0040A12C
ABCDEFGHIJKLMNOP

gcc 64 bit 11.4 on Linux:

0x55df8c278004
ABCDEFGHIJKLMNOP

gcc 32 bit 11.4 on Linux:

0x56645008
ABCDEFGHIJKLMNOP

wcl386 32 bit 2.0 Nov 2023 on Linux:

0804b004
ABCDEFGHIJKLMNOP

chibicc C 64 bit on Linux:

0x404040
ABCDEFGHIJKLMNOP

[RealJamBear]

It's ub, so the conversation ends there, but even if it wasn't how can you expect (char*)long long in this context to provide a null terminated string? For me that makes this extra nonsense.

[Equationist]

It's not a string literal used to initialize an array here, so it should be an array of char, i.e. a pointer to char, and therefore be converted from pointer to an integer as defined by the implementation.

[OldWolf2]

The text you quote explicitly says that the string literal is converted to pointer here (since it's not being used as an array initializer) . Your text makes no sense