Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #400266 > unrolled thread

Re: Expression statements (was Re: Meaning of "expression")

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
    Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
      Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
        Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
          Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
            Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
              Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 08:32 -0700
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:09 -0700

#400266 — Re: Expression statements (was Re: Meaning of "expression")

On 2026-06-12 02:41, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>> Oh, actually I indeed thought that printing a constant string would not
>> create any error that would then be indicated by printf's return value.
> 
> Linux has a device called "/dev/full".  It acts like it has no data
> on input, and like it's full on output.  You can redirect a program's
> stdout to /dev/full.  It's useful for testing, and much easier than
> finding a writable filesystem with no remaining space.  (/dev/null
> accepts and discards as much intput as you send to it.)

I've never stumbled across /dev/full before. Thanks for that hint.

> [...]
> 
>> I'd indeed also expected that, say, printing a string value with a '%d'
>> specifier would produce an error, but I saw that it doesn't; while the
>> compiler creates just a warning, execution provides some random output
>> and a _non-negative_ string-length value as printf's return value. Not
>> exactly what I'd expect from a language.
> 
> Calling printf with a mismatch between the format string and
> an argument has undefined behavior.  Some compilers will warn
> about this in most cases, but in general the format string is not
> necessarily known at compile time. 

Well, yes. But therefore I imagined that at runtime an rc<0 could have
indicated such a mismatch.

(BTW, only after my post I noticed that my example scenario ("printing
a string value with a '%d'") a string is actually passed as a pointer
value, so is a type similar to an integer, which might make it easier
to spot at compile time than at runtime? Anyway; this is something I'd
like to be detected.)

> No diagnostic or other error indication is required.

Well.

>> [...]
>>
>> Obviously (because of that?) I've never seen anyone test such a call
>> by, say,
>>
>>    int rc = printf("Hello, world\n");
>>    if (rc < 0) {
>>       /* umm.. */
>>    }
> 
> Quick-and-dirty programs like the classic "hello, world" often don't
> bother to check.  The above could print an error message to stderr and
> call exit(EXIT_FAILURE).  Even if stdout and stderr both produce errors,
> the caller should be able to detect the error status.  (I've configured
> my shell to print a message when a program dies with an error status.)
> 
> But most production programs don't just blindly print stuff to stdout.
> [...]
> 
>> Are you - plural, all CLC audience - writing such code with 'printf()',
>> honestly? - Same question with 'int rc = fclose (...);' - what can one
>> do about that, then? (Write a logfile entry, maybe? - and then?)
> 
> Write the error message to stderr, optionally log it somewhere,
> and exit with an error code.

Just note that generally a terminal might not be connected. As I wrote,
logging was what we've done, so I'm with you here. An exit, OTOH, was in
our server applications not an option.

Janis

[toc] | [next] | [standalone]

#400268

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-12 02:41, Keith Thompson wrote:
[...]
>> Calling printf with a mismatch between the format string and
>> an argument has undefined behavior.  Some compilers will warn
>> about this in most cases, but in general the format string is not
>> necessarily known at compile time. 
>
> Well, yes. But therefore I imagined that at runtime an rc<0 could have
> indicated such a mismatch.

That would be nice, but it's just one of the infinitely many possible
results of undefined behavior.

For example, this program:

#include <stdio.h>
int main(void) {
    const int result = printf("%ld\n", 0.3);
    printf("printf returned %d\n", result);
}

on my system prints:

140732048673560
printf returned 16

gcc and clang warn about the format string.  tcc doesn't.

The (first) printf call was apparently successful because printf
has no way to know that the argument was of an incorrect type
(types don't really exist at run time).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#400274

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

> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 2026-06-12 02:41, Keith Thompson wrote:
>
> [...]
>
>>> Calling printf with a mismatch between the format string and an
>>> argument has undefined behavior.  Some compilers will warn about
>>> this in most cases, but in general the format string is not
>>> necessarily known at compile time.
>>
>> Well, yes.  But therefore I imagined that at runtime an rc<0
>> could have indicated such a mismatch.
>
> That would be nice, but it's just one of the infinitely many
> possible results of undefined behavior.
>
> For example, this program:
>
> #include <stdio.h>
> int main(void) {
>     const int result = printf("%ld\n", 0.3);
>     printf("printf returned %d\n", result);
> }
>
> on my system prints:
>
> 140732048673560
> printf returned 16
>
> gcc and clang warn about the format string.  tcc doesn't.
>
> The (first) printf call was apparently successful because printf
> has no way to know that the argument was of an incorrect type
> (types don't really exist at run time).

printf() could know if an argument were of an incorrect type, if
an implementation chose to do so.

[toc] | [prev] | [next] | [standalone]

#400278

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> For example, this program:
>>
>> #include <stdio.h>
>> int main(void) {
>>     const int result = printf("%ld\n", 0.3);
>>     printf("printf returned %d\n", result);
>> }
>>
>> on my system prints:
>>
>> 140732048673560
>> printf returned 16
>>
>> gcc and clang warn about the format string.  tcc doesn't.
>>
>> The (first) printf call was apparently successful because printf
>> has no way to know that the argument was of an incorrect type
>> (types don't really exist at run time).
>
> printf() could know if an argument were of an incorrect type, if
> an implementation chose to do so.

Sure.  I did write "on my system", where printf has no way to know
that the argument was of an incorrect type.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#401180

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:
>
> [...]
>
>>> For example, this program:
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>>     const int result = printf("%ld\n", 0.3);
>>>     printf("printf returned %d\n", result);
>>> }
>>>
>>> on my system prints:
>>>
>>> 140732048673560
>>> printf returned 16
>>>
>>> gcc and clang warn about the format string.  tcc doesn't.
>>>
>>> The (first) printf call was apparently successful because printf
>>> has no way to know that the argument was of an incorrect type
>>> (types don't really exist at run time).
>>
>> printf() could know if an argument were of an incorrect type, if
>> an implementation chose to do so.
>
> Sure.  I did write "on my system", where printf has no way to know
> that the argument was of an incorrect type.

The "on my system" applies to what the program prints.

The paragraph that says "printf has no way to know" is a general
statement, for any implementation of printf().  If you had meant it
to apply only to your system, you should have said something like
"because that printf had no way to know".  Without any qualifying
adjective or other indicator the statement is generic, not
specific.

[toc] | [prev] | [next] | [standalone]

#401187

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> 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:
>> [...]
>>
>>>> For example, this program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>>     const int result = printf("%ld\n", 0.3);
>>>>     printf("printf returned %d\n", result);
>>>> }
>>>>
>>>> on my system prints:
>>>>
>>>> 140732048673560
>>>> printf returned 16
>>>>
>>>> gcc and clang warn about the format string.  tcc doesn't.
>>>>
>>>> The (first) printf call was apparently successful because printf
>>>> has no way to know that the argument was of an incorrect type
>>>> (types don't really exist at run time).
>>>
>>> printf() could know if an argument were of an incorrect type, if
>>> an implementation chose to do so.
>>
>> Sure.  I did write "on my system", where printf has no way to know
>> that the argument was of an incorrect type.
>
> The "on my system" applies to what the program prints.
>
> The paragraph that says "printf has no way to know" is a general
> statement, for any implementation of printf().  If you had meant it
> to apply only to your system, you should have said something like
> "because that printf had no way to know".  Without any qualifying
> adjective or other indicator the statement is generic, not
> specific.

You're quibbling about something I wrote nearly two months ago.

Certainly printf has no way defined by the language to know whether
its arguments are of the correct types.  An implementation could
provide that information via some system-specific method, but I know
of no implementations that do so, and I'd be surprised if any such
implementations exist.  What I wrote was true on my system and is
very likely true on all real-world systems.

If you have something to say about whether any such implementations
exist, I invite you, but do not expect you, to share it.  That might
actually be interesting.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#401328

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:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>> For example, this program:
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>>     const int result = printf("%ld\n", 0.3);
>>>>>     printf("printf returned %d\n", result);
>>>>> }
>>>>>
>>>>> on my system prints:
>>>>>
>>>>> 140732048673560
>>>>> printf returned 16
>>>>>
>>>>> gcc and clang warn about the format string.  tcc doesn't.
>>>>>
>>>>> The (first) printf call was apparently successful because printf
>>>>> has no way to know that the argument was of an incorrect type
>>>>> (types don't really exist at run time).
>>>>
>>>> printf() could know if an argument were of an incorrect type, if
>>>> an implementation chose to do so.
>>>
>>> Sure.  I did write "on my system", where printf has no way to know
>>> that the argument was of an incorrect type.
>>
>> The "on my system" applies to what the program prints.
>>
>> The paragraph that says "printf has no way to know" is a general
>> statement, for any implementation of printf().  If you had meant it
>> to apply only to your system, you should have said something like
>> "because that printf had no way to know".  Without any qualifying
>> adjective or other indicator the statement is generic, not
>> specific.
>
> [...]  Certainly printf has no way defined by the language to know
> whether its arguments are of the correct types.  An implementation
> could provide that information via some system-specific method,
> [...]

I'm glad to know we are in agreement.

[toc] | [prev] | [next] | [standalone]

#401340

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> I'm glad to know we are in agreement.

We're not.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web