Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: printf and time_t
Date: Tue, 17 Feb 2026 23:11:36 -0800
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <86342yh6fr.fsf@linuxsc.com>
References: <10jfol6$2u6r8$1@news.xmission.com> <87bjj5gei4.fsf@example.invalid> <20260108023846.0000260c@yahoo.com> <10jpi8h$15aea$1@dont-email.me> <20260109141859.00004f22@yahoo.com> <10jv3rb$15aea$2@dont-email.me> <20260111132015.000026ad@yahoo.com> <86zf6kkjw0.fsf@linuxsc.com> <20260111235104.00001463@yahoo.com> <86ms1pj0bc.fsf@linuxsc.com> <10ltjjt$1o4pk$1@dont-email.me> <865x8cio5y.fsf@linuxsc.com> <10lvt1s$2fu8f$1@dont-email.me> <10lvul0$2gps1$1@dont-email.me> <10m024m$2hqvi$1@dont-email.me> <10m091i$2kiff$1@dont-email.me> <10m0b0g$2l6li$1@dont-email.me> <10m1vl7$35irp$1@dont-email.me> <87wm0r80zj.fsf@example.invalid> <86wm0qgmtm.fsf@linuxsc.com> <87a4xm82a5.fsf@example.invalid>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 18 Feb 2026 07:11:39 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="af48cdabb06ae819f4a3a3add330f31d"; logging-data="2560001"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+VWljweQTMf/zf9HVxbB8BOh8r1cHjK7U="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:+VpYFYdyqzgSg5iHrq7cfCVlKaQ= sha1:Q2IaJyjiuKrGHQKfCPhAHW/JULA=
Xref: csiph.com comp.lang.c:396672

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>>> I recently played around with an attempted framework using _Generic.
>>> The goal was to be able to write something like
>>>
>>>     print(s(x), s(y), s(z));
>>>
>>> where x, y, and z can be of more or less arbitrary types (integer,
>>> floating-point char*).  The problem I ran into was that only one of
>>> the generic associations is evaluated (which one is determined at
>>> compile time), but *all* of them have to be valid code.
>>
>> That is annoying but it shouldn't be too hard to work around
>> it.  To verify that hypothesis I wrote this test case:
>>
>>
>>         #include <stdio.h>
>>         #include <time.h>
>>         #include <stdint.h>
>>
>>         #include "h/show.h"
>>
>>         int
>>         main(){
>
> [30 lines deleted]
>
>>             show(
>>                 uc,sc,us,ss,ui,si,ul,sl,ull,sll,
>>                 c,f,d,ld,yes,no,u16,s16,uge32,sge32,
>>                 runtime,now,offset,uf32,sf32,
>>                 c * now / 1e8 * ld,
>>                 foo, bas
>>             );
>>             printf( "\n" );
>>
>>             return  0;
>>         }
>>
>> which compiles under C11 and (along with the show.h include file)
>> produces output:
>>
>>                   uc = 255
>>                   sc = -1
>>                   us = 65535
>
> [23 lines deleted]
>
>>                  foo = "foo"
>>                  bas = (const char *) "bas"
>
> Were you planning to show us what show.h looks like?

I posted what I thought showed the essential elements of what I
was trying to convey.  I don't want to get dragged into a
discussion of irrelevant tangents.

What would be more interesting is if you would post some of your
efforts showing what sort of problems you ran into.  What made
those happen?  What are the contours of the problem you were
trying to solve?  Were those contours too large, or might the
full problem be solvable using a modified approach?  It would be
good to see a discussion of exactly what problems there were and
what sort of approaches might address them.