how to get binary representation of c objects ?

[Richard Heathfield]

CBFalconer said:

A failure. It should output the string "b", followed by a newline,
and should ignore the "12345". See the C standard for this correct
performance.

Wrong. "If a conversion specification is invalid, the behavior is
undefined." - C89, 4.9.6.1; C99, 7.19.6.1(9) - same wording in each.
Therefore, neither the de jure nor the de facto C standard imposes any
requirements whatsoever on a program containing a %b format specifier in a
call to any of the *printf standard library functions, and they certainly
do not impose the behaviour you specify.

 

[Kelsey Bjarnason]

Nope. The beatings will continue until morale improves...

You say that as if it's ironic or something.

 

[Kelsey Bjarnason]

[snips]

I am bad bad bad...



Satisfied?

Not really. Then again, I don't really expect you to stop flogging the
thing here; you have a financial incentive to do so, whether it's
fundamentally broken, partially broken, absolutely perfect or otherwise.

 

[Philip Potter]

jacob navia wrote:
... snip ...

A failure. It should output the string "b", followed by a newline,
and should ignore the "12345". See the C standard for this correct
performance. This does not allow this extension.

My C draft states that this is UB. n1256 7.19.6p9. If you're going to
cite the C Standard, you should check it first!

I don't see anything which prevents implementations from providing this
extension - it just warns implementors that their extension may clash
with future versions of the C Standard, at which point the extension
becomes invalid.

I suppose that you could interpret 7.26.9 as reserving "%b" in the same
way that the other subsections within 7.26 reserve the strxxx, toxxx,
isxxx and EXXX identifiers, but it doesn't explicitly say this.

[Having said that, it would be bad practise for an implementation to use
%b rather than %B, even if it is (possibly) allowed.]

Phil

 

[Richard Bos]

I think that's the point: the standard says "x is reserved" so you merrily
go and use it anyways, which is directly contradictory to the requirements
imposed by the standard... so if you're not using the standard to develop
your implementation, what *are* you using? Tea leaves?

Psychorectal extraction.

Of course, that sort of thing would be fine if you're writing, oh, a BASIC
implementation,

It wouldn't, actually. There is an ISO Standard for BASIC, as well.

Richard

 

[Philip Potter]

My C draft states that this is UB. n1256 7.19.6p9. If you're going to
cite the C Standard, you should check it first!

Sorry, 7.19.6.1p9.

 

[CBFalconer]

CBFalconer said:

Wrong. "If a conversion specification is invalid, the behavior is
undefined." - C89, 4.9.6.1; C99, 7.19.6.1(9) - same wording in each.
Therefore, neither the de jure nor the de facto C standard imposes
any requirements whatsoever on a program containing a %b format
specifier in a call to any of the *printf standard library functions,
and they certainly do not impose the behaviour you specify.

Oh well. At least I supplied the world an accurate pbin() routine
(which you snipped) which will avoid the need for any such
misconstruing of the standard in the future. In fact it can
be called from the printf code when so signalled by a future %B
specification.

 

[Ben Bacarisse]

Oh well. At least I supplied the world an accurate pbin() routine
(which you snipped) which will avoid the need for any such
misconstruing of the standard in the future. In fact it can
be called from the printf code when so signalled by a future %B
specification.

I doubt it! You routine does not have any way to control the output
width or padding and it prints a leading 0 for every number. It is
not a natural choice for a printf implementer.