C's 'printf'

[sal55]

(Content deleted)

[jahboater]

You're mixing up the two pieces of information that 'printf' functions need to know for each argument: the type of the thing to be printed, and optional formatting information that affects its appearance.

I know how printf works, I have been using it for 40 years or so!

although it's apparently not bothered about mixing up %d and %u).

GCC does complain about that.

There's also a problem in printing types such as int64_t, since the format may be either %ld or %lld depending on platform, or you have instead to use ugly string macros such as PRI64d.

Yes, that (PRId64 etc) is little messy, but it works fine, is precise, and is portable.

This is where, when the format string is constant (as it nearly always is), it would be easy to support a format such as %? which tells the compiler to fill in the default type format depending on argument.

Sounds like good idea. But not for me. I like C because I always know exactly what scalar types I am using at all times (so choosing a printf conversion specifier is pretty easy). Although decent modern compilers deal with printf() and its formats specially, I suspect that many simpler compilers do not and the format is just a string.

C's problem is its long history and its vast software base. Add to that its portability over a divers range of platforms, and the requirement to run efficiently on very slow hardware.
Modern languages such as D or Rust do not have these problems, in particular they have no requirement for backwards compatibility with a very large existing software base. New features in C have to be added in such a way that existing programs will still work. For example in C99 when they introduced bool, a new keyword _Bool was introduced and a header file had to be included to get bool, true, false. This means that the huge number of existing programs that declared their own "bool" type will still compile cleanly.
The same backwards compatibility also led to PRId64 etc (I think).

In the early days there was a clear demarcation between the compiler and the run time library.
Printf is a library function and cannot know its argument types or count. It relies on the format. Of course nowadays compilers examine the format and check it (which is great) or optimize it, for example changing printf( "Hello, world\n" ) into puts( "Hello, world" ), but in the early days of C, it was "just a function".

'print a, b, c' is one of the most basic features of a programming language, yet both C and C++ seem to make a meal of it.

I guess you are saying that your language has a formatted I/O facility that is more powerful, more flexible, and more portable than printf() - yet is simple and clean?

[PeterO]

It's a library function, if it doesn't do what you want write something else.....
I suggest you take your thread to JTC1/SC22/WG14 - C .
PeterO

[sal55]

(Content deleted)

[jamesh]

The definitions of the formatters ar simple - here's an example. You would simply define the correct ones for your architecture.

Code: Select all

#define PRId8     "hhd"
#define PRId16    "hd"
#define PRId32    "ld"
#define PRId64    "lld"

Not too much of a hardship. Unlike using a non-standard output system when you want to move to a different platform...

[sal55]

(Content deleted)

[PeterO]

It's a library function, if it doesn't do what you want write something else.....

Not true.

I'm at a loss to understand what is stopping you from writing your own functions ?

You can make it do what you want by modifying its inputs. But doing that directly in C is fiddly and error prone.

What are you on about. Of course you change its behaviour by changing its inputs
So you consider writting C code to be "fiddly and error prone" ? Then use something else...
If you don't like the way C does things then use something else .... Your moaning here is achieving nothing.
PeterO

[Heater]

There is no problem with C. It is small and perfectly formed. Compilers may be huge and complex but the language is not. C does what it was built to do perfectly, nothing more, nothing less. One man can write a C compiler in reasonable time.

Experience shows that attempts to "improve" C can only make it worse, c++ough.

Given the nature of C, it's undefined behaviors and so on, it does not make a good candidate for extending into a higher level language, as we have seen, c++cough.

If you want a better different, "better", language then create one. Better tackle all these UB's first else you are building you house on sand. At that point you have a very different language no longer backward compatible with C source. See Javascript, Java, C#, Rust etc.

When I recall the many happy (and frustrating) hours I spent getting my first ALGOL programs to work as a teenager I don't think the foibles of printf() are a big deal. You soon grasp how the simple case work and that is good enough to get you along way before you feel the need for something more complicated.

[jahboater]

Yes, that (PRId64 etc) is little messy, but it works fine, is precise, and is portable.

Only from inside C. I've generally called routines such as printf as foreign functions from other languages

Can I ask why? Do these other languages not have their own formatted I/O? or is their I/O not as capable as printf?

[sal55]

PeterO wrote:↑
18 Oct 2019 13:00
I'm at a loss to understand what is stopping you from writing your own functions ?

You can't write functions that work better than printf, because it needs language support. For example, consider a function that is called as:
Code: Select all

Code: Select all

print(a, b, c);

which prints an arbitrary sequence of expressions of arbitrary type. It can't be done in a low-level language without a raft of extra features, when you might as well just fix the print facility.

If you don't like the way C does things then use something else .... Your moaning here is achieving nothing.

I do. But other people use C (and this started in a thread about C for beginners) and highlighting the problems can be useful, as well as looking at workarounds. (Actually, I improved the way printf could be used, inside one C compiler, by allowing the compiler to fill in the format codes. That shows what can be achieved, even if it's never going to be a standard feature.)

[content restored]

[PeterO]

I'm at a loss to understand what is stopping you from writing your own functions ?

You can't write functions that work better than printf, because it needs language support. For example, consider a function that is called as:

Code: Select all

print(a, b, c);

which prints an arbitrary sequence of expressions of arbitrary type. It can't be done in a low-level language without a raft of extra features, when you might as well just fix the print facility.

So as we suspected you're not moaning about printf at all, just your general dislike of C. It's hard to understand why you use it at all.

If you don't like the way C does things then use something else .... Your moaning here is achieving nothing.

I do.

SO why are you still moaning about something you don't use ?

But other people use C (and this started in a thread about C for beginners)

So this is all just concern trolling then ?

PeterO

[LdB]

I am with Peter O you aren't highlighting a problem ... you are making one up.

As others have said the C standard for the function is basically set in stone and we don't care that you want to change it ... never going to happen.

The facts are simple
1.) If you don't meet the C standard library specification your compiler libraries are non compliant
2.) The backlash from large historic code base would be brutal
3.) The number of actual programs that use printf for anything other than debugging is not large.
4.) There is nothing stopping you writing your own library with your own printf
PS it's not hard here is my embedded version .. write your own
printf starts line 699
https://github.com/LdB-ECM/Raspberry-Pi ... mb-stdio.c

There simply is nothing to be gained by changing it and you have made no actual argument why it needs to be changed.

[sal55]

(Content deleted)

[sal55]

It seems people are very touchy about their C language. It seems also that they don't understand what the problems are with 'printf', despite the examples I posted earlier. For example, what format code goes here:

Code: Select all

T a;
printf("%...", a);

In any modern language you just say 'print a'. In my modified C compiler you can also just say 'printf("%?", a);', and that is compatible with existing printf libraries. It was done to prove a point elsewhere, but I will keep the feature because it's handy.

However, I won't push things any further here.

[LdB]

It's C not GWBasic, types are a feature of the language not a problem and if you don't know what type T is then you really shouldn't be programming in C

People aren't being touchy about C ... your argument is stupid.

[sal55]

If you want a better different, "better", language then create one. Better tackle all these UB's first else you are building you house on sand. At that point you have a very different language no longer backward compatible with C source. Javascript, Java, C#, Rust etc.

I've done several, all used as private in-house languages, and long before I came across C. So my perspective is somewhat different.

But even with the very first one, you could just say 'print x'. It never occured to me to require the programmer to TELL the compiler what type x was!

When I recall the many happy (and frustrating) hours I spent getting my first ALGOL programs to work as a teenager I don't think the foibles of printf() are a big deal. You soon grasp how the simple case work and that is good enough to get you along way before you feel the need for something more complicated.

Of course I can use printf. But it's a pig. Especially when you are terrible typist and you are writing dozens of temporary printfs for debugging.

[LdB]

Stop and consider your moaning about a 47 year old strict type-based language and your complaint is that your shouldn't have to know the type

Perhaps take up another language.

[sal55]

It's C not GWBasic, types are a feature of the language not a problem and if you don't know what type T is then you really shouldn't be programming in C

People aren't being touchy about C ... your argument is stupid.

You're goading me into a reply now. You may not know what T is because it's not your type, if it's from imported code. Or it's not visible, or hidden behind macros. Or it's used in an expression which mixes types like this: T*U+V', and you want to print that value; what type is the result? Because you need to know the result type to get the right format code.

Or you know what T is, know the exact format code, and embed that in 300 printf statements. Then you change the type of T; it might still be numeric, but now you have to find and update 300 printf formats because they have to be exactly right.

I don't know if people really can't see this, or just trying to defend their language.

[Heater]

I don't know. It's a valid point.

When you want to introduce somebody who has never programmed to programming you want to start with something really simple, like gettig them to print their name or the result of some simple arithmetic.

In C there is a lot of boiler plate cluttering things up which is mysterious and confusing and gets in the way of what you want to do. All that "#include stdio.h" stuff, and "int main (int argc, char* argv[])" and squiggly brackets. Never mind the secret incantations of "printf".

Of course it's even worse with languages like Java and C# where you need all that weird ass class boiler plate before you even get started.

Which is why they invented BASIC and why Python is so popular. So easy to get started with.

I have used C for decades and I love it. So I reserve the right to also criticize and complain about it if I want to. However if I were wanting to improve C I would want to address a hundred other complaints I have about it before worrying about printf. Like fixing it's type system, fixing it;s undefined arithmetic, fixing it's laxity with array bounds, use of uninitialized variables, null pointers, etc, etc, etc.

Oh and how come after all this time getting the frikken carry flag/overflow flags is so hard?

At the end of the day, actually printing stuff with printf is a very small part of what most of the code I write does.

[Heater]

LdB,

Stop and consider your moaning about a 47 year old strict type-based language and your complaint is that your shouldn't have to know the type

Stop and consider that the Rust language is even more strictly typed than C (Actually I would not call C strictly typed but that is another story) but in Rust you can do this:

Code: Select all

$ cat hello.rs

fn main () {
    let x: i32 = 10;
    let y: f32 = 3.14159;
    let z = "Hello";

    println!("x = {}, y = {}, z = {}", x, y, z);
}

$ rustc hello.rs
$ ./hello
x = 10, y = 3.14159, z = Hello

Where x, y and z can be integers, floats, strings, arrays and pretty much anything else. The compiler figures out how to print them, you don't have to tell it.

The actual code generated to do that is pretty much the same as using printf in C.

So we see that what sal55 is saying is not unreasonable or beyond the bounds of possibility, it's been done.

[PeterO]

So we see that what sal55 is saying is not unreasonable or beyond the bounds of possibility, it's been done.

By creating a whole new language... Which is not what sal55 thinks is the solution to his "problem"
PeterO

[jahboater]

fixing it;s undefined arithmetic,

In C2x I believe.

So we see that what sal55 is saying is not unreasonable or beyond the bounds of possibility, it's been done.

Its been done in an entirely new language, and I think Algol68 did it a very long time ago.
/* edit: sorry PeterO, you got there first! */
Also of course available in C++, but people still use printf sometimes because of its extra capability.

Challenge! without looking it up, whats the conversion specifier for size_t ?

[jahboater]

Oh and how come after all this time getting the frikken carry flag/overflow flags is so hard?

That's easy, but its a GCC extension.

Obviously not truly portable, but then GCC is available on so many platforms, and I bet Clang can do it too.

[Heater]

Yes of course with a new different language. I did not suggest "fixing" C. I don't believe sal55 meant that either.

The genes of ALGOL are in most languages we use today.

[Heater]

jahboater,

That's easy, but its a GCC extension.

That's great and all but it's not C. It's a new different language.