How is printf auto-static yoinking of symbols supposed to interact with things like function pointers ?

[GabrielRavier]

Having spent a little while studying how the auto-linking in printf works, I'd like to ask if the fact that it simply doesn't work with function pointers is deliberate behavior or effectively a bug.

In particular, a program such as this:

#include <stdio.h>

void use_printf_through_function_pointer (int (*printf_ptr)(const char *, ...))
{
    printf_ptr("%f\n", 12.75);
}

int
main (void)
{
    use_printf_through_function_pointer(printf);
    return 0;
}

simply doesn't work under cosmopolitan because it never links in __fmt_dtoa, as the invocation of printf_ptr cannot be scanned for that purpose. That appears to be deliberate (at least, blog posts such as this one directly indicate that non-direct invocations of printf disable the auto-STATIC_YOINK mechanism), but I'm wondering if there's any way of disabling that behavior, through a command-line switch to gcc when compiling or something like that.

In particular, I'm asking this because I'm currently developing a libc testsuite over here (that's why I've filed 17 bug reports in just a few days), and tests such as this one explicitly test that printf works properly when called through a function pointer.

Right now it's not too much hassle to add in a

#ifdef __COSMOPOLITAN__
STATIC_YOINK("__fmt_dtoa");
// etc.
#endif

but it feels a bit weird to do so, especially as this still means perfectly standards-conforming programs still fail to run properly unless the manual STATIC_YOINK is present.

I suppose that could just be added to the list of ways in which cosmopolitan deliberately deviates from the standard, but for this in particular it seems odd that there is no way of disabling this behavior.

[G4Vi]

I haven't tried this, you may be able to force gcc to link the necessary symbols with the link option -u symbol. For example, -u __fmt_dtoa.

The only official cosmopolitan method I know of is building with MODE=ansi:

cosmopolitan/build/config.mk

Lines 365 to 397 in f7ff77d

	# ANSI Mode
	#
	# These flags cause GCC to predefine __STRICT_ANSI__. Please be warned
	# that Cosmopolitan headers are written to comply with that request if
	# it's possible to do so. Consider the following example:
	#
	# make -j12 -O o//tool/viz/printvideo.i
	# clang-format-10 -i o//tool/viz/printvideo.i
	# less o//tool/viz/printvideo.i
	#
	# You'll notice functions like memcpy(), ioctl(), etc. get expanded into
	# wild-eyed gnu-style performance hacks. You can turn it off as follows:
	#
	# make -j12 -O MODE=ansi o/ansi/tool/viz/printvideo.i
	# clang-format-10 -i o/ansi/tool/viz/printvideo.i
	# less o/ansi/tool/viz/printvideo.i
	#
	# Here it becomes clear that ANSI mode can help you decouple your source
	# from Cosmopolitan, by turning it into plain ordinary textbook C code.
	#
	# Another potential use case is distributing code to folks using tools
	# such as MSVC or XCode. You can run your binary objects through a tool
	# like objconv to convert them to COFF or MachO. Then use ANSI mode to
	# rollup one header file that'll enable linkage with minimal issues.
	ifeq ($(MODE), ansi)
	CONFIG_CFLAGS += -std=c11
	#CONFIG_CPPFLAGS += -ansi
	CONFIG_CXXFLAGS += -std=c++11
	TARGET_ARCH ?= -msse3
	endif

When building with __STRICT_ANSI__, _weaken is set as follows: #define _weaken(symbol) symbol https://github.com/jart/cosmopolitan/blob/6f7d0cb1c3962f7cb474b04de75df7cd82a3e5d3/libc/intrin/weaken.h

[GabrielRavier]

Ah, nice, I guess that's probably a much better configuration to test conformance on than MODE=dbg (although that means it doesn't have all the debugging stuff, but adding ansidbg should be trivial)

[GabrielRavier]

...The part where MODE=ansi just doesn't compile is pretty unhelpful, though.

[GabrielRavier]

Is MODE=ansi something that's supposed to be capable of working with cosmopolitan as a whole ? The amount of build errors is humongous and it seems like something that'd take hours, if not days, to fix up...

[G4Vi]

I'd assume it's supposed to be work, but I don't think there's been a persistent effort to maintain it. I haven't tried a MODE=ansi build until today and the CI doesn't build it.

It may be helpful to discuss your libc test suite and cosmopolitan in our discord server, link if you haven't joined: https://discord.gg/7FZGecjP Other collaborators or discord members may have a better idea of what works or doesn't work with MODE=ansi or how we may be able to accommodate your efforts. I greatly appreciate all the discoveries and fixes you've made on our format string functionality.

[jart]

Yeah I haven't used MODE=ansi in the longest time. IIRC it was only ever good for making the headers? Don't remember.