conversion to binary in printf()

[David Marsh]

I accidentally typed %b instead of %d in a printf format string
and got a binary representation of the number. Is that standard C
or a compiler extension?

 

[Robert Gamble]

I accidentally typed %b instead of %d in a printf format string
and got a binary representation of the number. Is that standard C
or a compiler extension?

%b is not a Standard conversion specifier.

Robert Gamble

 

[jacob navia]

David Marsh a écrit :

I accidentally typed %b instead of %d in a printf format string and got
a binary representation of the number. Is that standard C or a compiler
extension?

It is used in the lcc-win32 compiler system for binary representation

Maybe other printfs do that too.

 

[Keith Thompson]

I accidentally typed %b instead of %d in a printf format string and
got a binary representation of the number. Is that standard C or a
compiler extension?

It's an extension. It's not likely to be a *compiler* extension,
though; printf is part of the runtime library. This is an important
distinction; gcc, for example, uses whatever runtime library is
available on the system.

 

[santosh]

I accidentally typed %b instead of %d in a printf format string
and got a binary representation of the number. Is that standard C
or a compiler extension?

The standard doesn't define this conversion specifier for printf(), so
it's a local extension.

 

[CBFalconer]

David Marsh a écrit :


It is used in the lcc-win32 compiler system for binary
representation

Unless you have means to disable it, that is another variation from
the standard and a hindrance to creating portable code.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Flash Gordon]

CBFalconer wrote, On 21/01/07 23:37:

Unless you have means to disable it, that is another variation from
the standard and a hindrance to creating portable code.

Be fair Chuck, it does not break and standard code so it does not get in
the way. Although I would not use it myself even if it was available in
a compiler I use.

 

[Kenny McCormack]

"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

Indeed. And this is why I wouldn't *dream* of killfiling you.

 

[Yevgen Muntyan]

Unless you have means to disable it, that is another variation from
the standard and a hindrance to creating portable code.

Standard says it's UB. Printing a binary representation is not much
worse than nasal daemons, is it?

Yevgen

 

[Keith Thompson]

Unless you have means to disable it, that is another variation from
the standard and a hindrance to creating portable code.

C99 7.19.6.1p9:

If a conversion specification is invalid, the behavior is
undefined.

An implementation may define the behavior for things that the standard
says are undefined behavior (many valid extensions are implemented
this way).

It might be nice to be able to turn this extension off and have "%b"
cause a runtime failure (and/or a compile-time warning if the format
is a string literal), to detect programs that depend on it, but the
standard doesn't require it.

 

[Peter Nilsson]

C99 7.19.6.1p9:

If a conversion specification is invalid, the behavior is
undefined.

An implementation may define the behavior for things that the standard
says are undefined behavior (many valid extensions are implemented
this way).

Yes, however lowercase letters are reserved for future use as
conversion
specifiers (7.26.9). So, an implementation should choose (say) B
instead
of b to support binary output. Otherwise, the implementation is
potentially
allowing (and encouraging) a practice that may one day conflict with
the
C standard.

[Jacob has been told this in the past (in csc) in relation to
supporting
non-standard conversion specifiers.]

 

[JimS]

David Marsh a écrit :

It is used in the lcc-win32 compiler system for binary representation

Maybe other printfs do that too.

OpenWatcom does it too.

Jim

 

[CBFalconer]

CBFalconer wrote, On 21/01/07 23:37:

Be fair Chuck, it does not break and standard code so it does not
get in the way. Although I would not use it myself even if it was
available in a compiler I use.

The point is that having such non-standardisms encourages the
unaware to use them, with no indication that they are building
non-portable code. Around here I run gcc through an alias that
maximizes my protection. If I need something else (unusual) I have
to think about it. Similarly my Pascal compiler is set to reject
anything outside ISO 7185.

The general reaction from the newbie is: "great, I can use this"
and he never realizes the penalties until much too late. A
non-standard specifier in a format string is especially likely to
create baffling problems later, because it is library dependant.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Guest]

The point is that having such non-standardisms encourages the
unaware to use them, with no indication that they are building
non-portable code. Around here I run gcc through an alias that
maximizes my protection. If I need something else (unusual) I have
to think about it. Similarly my Pascal compiler is set to reject
anything outside ISO 7185.

The general reaction from the newbie is: "great, I can use this"
and he never realizes the penalties until much too late. A
non-standard specifier in a format string is especially likely to
create baffling problems later, because it is library dependant.

Assuming it's clearly documented as an extension (as required), the
newbie's problem is that he didn't read the documentation. That's not a
compiler problem.

 

[John Smith]

Unless you have means to disable it, that is another variation from
the standard and a hindrance to creating portable code.

I suppose you could use that logic to argue against *any*
extension. Isn't it the programmer's job to understand that it's
non-standard and avoid it in code intended to be portable?

David

 

[Flash Gordon]

John Smith wrote, On 22/01/07 15:04:

I suppose you could use that logic to argue against *any* extension.
Isn't it the programmer's job to understand that it's non-standard and
avoid it in code intended to be portable?

It is also the implementers job to make a clear distinction between what
is standard and what is an extension. One problem is that Jacob as an
implementer often fails to make this distinction, although in this
particular case it could be argued that by saying "It is used in the
lcc-win32 compiler" he *is* saying it is specific to his compiler. I
suspect that were it not for his track record the post would have been
less likely lead to Chuck making the comment, or at least that he might
have phrased it differently.

Of course, it would be nice if in standards compliant mode it produced a
diagnostic (or run time message) for it, but that is something that
probably a lot of implementers would not bother with. After all, there
is no *requirement* in the standard to diagnose format specifiers not in
the standard, and in some situations it can only be detected at run time
in any case.