468,503 Members | 2,147 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,503 developers. It's quick & easy.

how to get binary representation of c objects ?

Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

But i couldn't find a control letter for binary output.

Thanks
Jan 14 '08 #1
42 4887
da*********@gmail.com wrote:
Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

But i couldn't find a control letter for binary output.
See Question 20.10 in the comp.lang.c Frequently Asked
Questions (FAQ) list at http://www.c-faq.com/.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jan 14 '08 #2
On Jan 14, 3:39 pm, davidCom...@gmail.com wrote:
Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

But i couldn't find a control letter for binary output.
That's because there is no conversion format to output in base 2.
Jan 14 '08 #3
da*********@gmail.com wrote:
) Hi all:
)
) char c = 'a';
)
) To get the hex version of the byte c, i can simply use:
)
) printf( " %x ",c);
)
) But i couldn't find a control letter for binary output.

As far as I know, there isn't one. Maybe there are some
implementations that have binary as an extension, but I don't know any.

You're going to have to roll your own if you really want binary output.

Here's a gratuitous example of how not to do it:

int print_bin(unsigned long num, int size)
{
return (size == 1)
? printf("%d", (num & 1))
: print_bin(num >(size/2), size - size/2)
+ print_bin(num, size/2);
}
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Jan 14 '08 #4
<da*********@gmail.comwrote in message news
>
char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

But i couldn't find a control letter for binary output.
Binary output isn't used often enough to have its own format.
You can convert from hex because each hex digit has 4 corresponding binary
bits

eg F1ED = | 1111 | 0001 | 1110 | 1101

In fact the hex form is far more readable.

It is easy enough to write a dump routine. Use the AND. OR and bitshift
operators to extract the bits for each char. Any object can be treated as an
array of unsigned chars.
For extra brownie points remember that char is not always 8 bits.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Jan 14 '08 #5
da*********@gmail.com wrote:
Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);
No, you can't. c may be signed. If c were declared as unsigned char,
then you could do that.
But i couldn't find a control letter for binary output.
There isn't one. There are almost no real uses for one, other than as
an elementary programming exercise. Learn to recognize bit patterns
3-bits-at-a-time with octal or 4-bits-at-a-time with hex.
Jan 14 '08 #6
da*********@gmail.com wrote:
Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

But i couldn't find a control letter for binary output.

Thanks
If you are using lcc-win you can write
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}
Output:
11000000111001

P.S. flames >/dev/null

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 14 '08 #7
Willem wrote:
da*********@gmail.com wrote:
) Hi all:
)
) char c = 'a';
)
) To get the hex version of the byte c, i can simply use:
)
) printf( " %x ",c);
)
) But i couldn't find a control letter for binary output.

As far as I know, there isn't one. Maybe there are some
implementations that have binary as an extension, but I don't know any.
lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}
Output:
11000000111001

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 14 '08 #8
On Mon, 14 Jan 2008 17:12:08 -0500, Martin Ambuhl wrote:
da*********@gmail.com wrote:
>Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

No, you can't. c may be signed. If c were declared as unsigned char,
then you could do that.
unsigned char usually promotes to signed int, so you'd be left with the
exact same problem. C99 allows you to use %hhx to print an unsigned char
as a hexadecimal number, but in C90, you need a cast.

Alternatively, you could rely on the almost guaranteed behaviour of
printing a signed int using a format specifier for unsigned int, exactly
as done in the above code. While it _is_ invalid, it's considerably more
complicated to create a conforming implementation where it won't work,
than one where it will, and I don't believe it's been done so far.
Jan 14 '08 #9
jacob navia wrote:

[advertisement for proprietary software snipped]

Please grow up.
Jan 14 '08 #10
jacob navia wrote:

[advertisement for expropriators software snipped]

Please grow up.
Jan 14 '08 #11
jacob navia <ja***@nospam.comwrites:
lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}
The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Jan 14 '08 #12
In article <5v*************@mid.individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>jacob navia wrote:
>[advertisement for proprietary software snipped]
>Please grow up.
I think that remark is unfair to Jacob. William had specifically
said that he did not know of any systems that implement a
binary format specifier extension, and Jacob replied showing one
such system. His reply was direct and to the point William had made;
I would not consider it an "advertisement" at all.

The fact that Jacob's software is proprietary is irrelevant to the
question: William did not say that he did not know of any "open source"
or "freeware" systems that implement the extension, he said that
he didn't know of *any* systems that had it. If I pointed out
that SGI IRIX's compiler has a %b extension as well, then would
you have said that my reply was an "advertisement for proprietary
software" ?

(IRIX does have a %b format extension; it just
happens to mean something completely different: it produces
a formatted byte count (e.g., %0.3b would convert 1024 to "1.000kb"))

--
"History is a pile of debris" -- Laurie Anderson
Jan 14 '08 #13
Ben Pfaff wrote:
jacob navia <ja***@nospam.comwrites:
>lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}

The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?
Obvious: I did not know that. Since this is a very minor extension
maybe I can just change it, but if people use it they will complain

Stupid error from my part.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 14 '08 #14
David:
Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

But i couldn't find a control letter for binary output.

Thanks


I suppose you could do something like:

#include <limits.h>

void GetByteAsBinaryString(char unsigned const x,char *p)
{
char unsigned mask = 1;

do *p++ = x & mask ? '1' : '0';
while (mask <<= 1);

*p = 0;
}
(See the conditional expression for the do-while loop, I realise that if
the operator were << then the resultant expression would have the type
of the promoted-to type. However, with <<=, will it have the promoted-to
type or will it have the original type? The reason I ask is because this
code could malfunction if <<= didn't yield an expression of the original
type)

--
Tomás Ó hÉilidhe
Jan 15 '08 #15
Tomás Ó hÉilidhe:
#include <limits.h>

I had originally intended to use CHAR_BIT but didn't end up using it.

--
Tomás Ó hÉilidhe
Jan 15 '08 #16
Harald van Dijk <tr*****@gmail.comwrites:
On Mon, 14 Jan 2008 17:12:08 -0500, Martin Ambuhl wrote:
>da*********@gmail.com wrote:
>>Hi all:

char c = 'a';

To get the hex version of the byte c, i can simply use:

printf( " %x ",c);

No, you can't. c may be signed. If c were declared as unsigned char,
then you could do that.

unsigned char usually promotes to signed int, so you'd be left with the
exact same problem. C99 allows you to use %hhx to print an unsigned char
as a hexadecimal number, but in C90, you need a cast.

Alternatively, you could rely on the almost guaranteed behaviour of
printing a signed int using a format specifier for unsigned int, exactly
as done in the above code. While it _is_ invalid, it's considerably more
complicated to create a conforming implementation where it won't work,
than one where it will, and I don't believe it's been done so far.
Furthermore, the value of 'a' is guaranteed to be positive, even if
plain char is signed.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 15 '08 #17
jacob navia wrote:
Ben Pfaff wrote:
>jacob navia <ja***@nospam.comwrites:
>>lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}

The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?

Obvious: I did not know that. Since this is a very minor extension
maybe I can just change it, but if people use it they will complain
For a start emit a warning which tells that %b will get removed and that
(e.g.) %B should be used instead

By, Jojo
Jan 15 '08 #18
jacob navia wrote:
Ben Pfaff wrote:
>jacob navia <ja***@nospam.comwrites:
>>lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}

The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?

Obvious: I did not know that.
On what basis did you develop your compiler and library system, if you
can't use the standard?
Jan 15 '08 #19
Mark Bluemel wrote:
jacob navia wrote:
>Ben Pfaff wrote:
>>jacob navia <ja***@nospam.comwrites:

lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}

The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?

Obvious: I did not know that.

On what basis did you develop your compiler and library system, if you
can't use the standard?
presumably on the basis of existing code, lcc.

Bye, Jojo
Jan 15 '08 #20
Joachim Schmitz wrote:
Mark Bluemel wrote:
>jacob navia wrote:
>>Ben Pfaff wrote:
jacob navia <ja***@nospam.comwrites:

lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}
The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?
Obvious: I did not know that.
On what basis did you develop your compiler and library system, if you
can't use the standard?
presumably on the basis of existing code, lcc.

Bye, Jojo

I wrote the whole library, the linker,
the debugger, etc. lcc has no assembler, no linker,
no optimizer, no debugger,
no long long/complex/long double/boolean

Mistakes in lcc-win are mine.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 15 '08 #21
Mark Bluemel wrote:
jacob navia wrote:
>Ben Pfaff wrote:
>>jacob navia <ja***@nospam.comwrites:

lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}

The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?

Obvious: I did not know that.

On what basis did you develop your compiler and library system, if you
can't use the standard?
Using the standard when adding extensions? They are, for
obvious reasons, not in the standard. What I did not know was that
the standard reserved letters for extensions.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 15 '08 #22
jacob navia wrote:
Mark Bluemel wrote:
>On what basis did you develop your compiler and library system, if you
can't use the standard?

Using the standard when adding extensions?
Yes, of course - see below.
They are, for
obvious reasons, not in the standard. What I did not know was that
the standard reserved letters for extensions.
My point exactly - if you are developing a C implementation, you should
be doing so in accordance with the standard. That includes ensuring that
you abide by any restrictions/reservations in the standard.

It does not promote confidence when a person developing a C
implementation admits he was unaware of significant aspects of the
standard...
Jan 15 '08 #23
Mark Bluemel wrote:
It does not promote confidence when a person developing a C
implementation admits he was unaware of significant aspects of the
standard...
Yes. Do not use my software.

I did not learn it by heart.

And I am not perfect (contrary to you). I do make
mistakes because a sentence in the middle of a 800 pages
escaped my attention.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 15 '08 #24
jacob navia wrote:
Mark Bluemel wrote:
>It does not promote confidence when a person developing a C
implementation admits he was unaware of significant aspects of the
standard...

Yes. Do not use my software.
As I avoid Windows, there is no danger of me using it.
I did not learn it by heart.
You're not expected to. You are expected to refer to it in detail when
producing an implementation which, presumably, claims compliance.
And I am not perfect (contrary to you).
I'm not, and never claim to be, perfect.
I do make
mistakes because a sentence in the middle of a 800 pages
escaped my attention.
Unfortunately that is not, IMHO, a valid excuse for someone claiming to
produce, and charge for, professional-quality software.
Jan 15 '08 #25
jacob navia wrote:
....
uses it too. Since the next standard in C will happen maybe
in 2019, there is no risk to anyone if they use %b in their
code.
You're certain that no code currently written to be linked with the
lcc-win library will still be in existence in 2019? That's a pretty
negative opinion you have of either your product or your customers,
I'm not sure which.

The oldest program that I'm responsible for that I can easily check
had 399,749 lines on 1997-07-01. Of those lines, the command

diff -r -d -b -w old_version new_version | egrep "^<" | wc

shows only 11,688 lines have been removed or significantly modified,
and many of those lines were simply moved elsewhere (though I can't
easily get a count of how many). Files containing, at that time,
117,749 lines have since been removed, many of them by putting at
least some of their code into files with different names (though I
have no easy way of determining how many). I think it's safe to assume
that most of the remaining lines will survive to their 11-year mark,
and the program is more heavily used right now than it has ever been.

So all of your customers write code with a substantially shorter
lifetime than mine?
Jan 15 '08 #26

<ja*********@verizon.netwrote in message
news:bd**********************************@k39g2000 hsf.googlegroups.com...
jacob navia wrote:
...
>uses it too. Since the next standard in C will happen maybe
in 2019, there is no risk to anyone if they use %b in their
code.

You're certain that no code currently written to be linked with the
lcc-win library will still be in existence in 2019? That's a pretty
negative opinion you have of either your product or your customers,
I'm not sure which.
A program using %b in the binary will still run in 2019. Source code using
%b, compiled with the current lcc-win version, in 2019, will still run,
probably for many years after that.

Only if that source code was recompiled with a compiler that assigns a
different meaning to %b would there be a problem. Or if the library with
printf() is dynamically linked and it is updated anytime with a version
using %b for a different purpose, although it then itself would be guilty of
usurping the %b format if done prior to the next Standard.

But I'm sure the client has more urgent matters to worry about in the next
11 years than whether the rarely used %b format gives the right output. And
s/he could only have used %b knowing this was a non-standard feature of
lcc-win. And the fix is simple if recompilation is needed.

--
Bart

Jan 15 '08 #27
Bart C wrote:
<ja*********@verizon.netwrote in message
news:bd**********************************@k39g2000 hsf.googlegroups.com...
jacob navia wrote:
...
uses it too. Since the next standard in C will happen maybe
in 2019, there is no risk to anyone if they use %b in their
code.
You're certain that no code currently written to be linked with the
lcc-win library will still be in existence in 2019? That's a pretty
negative opinion you have of either your product or your customers,
I'm not sure which.
....
Only if that source code was recompiled with a compiler that assigns a
different meaning to %b would there be a problem. ...
Well, do you consider that an unlikely event? In my experience,
recompilation with a different compiler is quite a routine event, and
I don't think you can justify assuming that there's only one plausible
meaning for %b. While I'm sure some of his customers will never
recompile any of their code, I would expect a much larger number of
them will recompile at least some of their code with at least one
other compiler, somewhere along the line.
... And
s/he could only have used %b knowing this was a non-standard feature of
lcc-win. ...
In my experience, most users of compilers are not even aware of which
features of the language it compiles are non-standard. Most of the
rest of the users have incorrect ideas about which features are non-
standard.
Jan 16 '08 #28
On Tue, 15 Jan 2008 10:16:14 +0100, jacob navia wrote:
Mark Bluemel wrote:
>jacob navia wrote:
>>Ben Pfaff wrote:
jacob navia <ja***@nospam.comwrites:

lcc-win implements %b
#include <stdio.h>
int main(void)
{
printf("%b\n",12345);
}

The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.

Given that, why did you use a lowercase letter for your
extension?

Obvious: I did not know that.

On what basis did you develop your compiler and library system, if you
can't use the standard?

Using the standard when adding extensions? They are, for
obvious reasons, not in the standard. What I did not know was that
the standard reserved letters for extensions.
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?

Of course, that sort of thing would be fine if you're writing, oh, a BASIC
implementation, but you seem to be flogging it here as a _C_
implementation, which it ain't. As the above demonstrates.
Jan 16 '08 #29
Kelsey Bjarnason <kb********@gmail.comwrites:
On Tue, 15 Jan 2008 10:16:14 +0100, jacob navia wrote:
>Mark Bluemel wrote:
>>jacob navia wrote:
Ben Pfaff wrote:
jacob navia <ja***@nospam.comwrites:
>
>lcc-win implements %b
>#include <stdio.h>
>int main(void)
>{
> printf("%b\n",12345);
>}
>
The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.
>
Given that, why did you use a lowercase letter for your
extension?

Obvious: I did not know that.

On what basis did you develop your compiler and library system, if you
can't use the standard?

Using the standard when adding extensions? They are, for
obvious reasons, not in the standard. What I did not know was that
the standard reserved letters for extensions.

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?

Of course, that sort of thing would be fine if you're writing, oh, a BASIC
implementation, but you seem to be flogging it here as a _C_
implementation, which it ain't. As the above demonstrates.
That's too harsh. The %b extension cannot affect the execution
of any strictly conforming program.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Jan 16 '08 #30
Kelsey Bjarnason wrote:
On Tue, 15 Jan 2008 10:16:14 +0100, jacob navia wrote:
>Mark Bluemel wrote:
>>jacob navia wrote:
Ben Pfaff wrote:
jacob navia <ja***@nospam.comwrites:
>
>lcc-win implements %b
>#include <stdio.h>
>int main(void)
>{
> printf("%b\n",12345);
>}
The C standards reserve lowercase letters for use in future
versions of the standard library. It also explicitly allows
extensions to use any other characters.
>
Given that, why did you use a lowercase letter for your
extension?
Obvious: I did not know that.
On what basis did you develop your compiler and library system, if you
can't use the standard?
Using the standard when adding extensions? They are, for
obvious reasons, not in the standard. What I did not know was that
the standard reserved letters for extensions.

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?

Of course, that sort of thing would be fine if you're writing, oh, a BASIC
implementation, but you seem to be flogging it here as a _C_
implementation, which it ain't. As the above demonstrates.
I am bad bad bad...

:-)

Satisfied?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 16 '08 #31
ja*********@verizon.net wrote:
>
.... snip ...
>
In my experience, most users of compilers are not even aware of
which features of the language it compiles are non-standard.
Most of the rest of the users have incorrect ideas about which
features are non-standard.
Which is one more reason, IMO, for compiler systems to be
restricted to the standard language, barring specific use of
features to enable extensions.

I can get there by running the compilers through aliases. but it
is not universal - for example make bypasses it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 16 '08 #32
jacob navia wrote:
>
.... snip ...
>
lcc-win implements %b
#include <stdio.h>
int main(void) {
printf("%b\n",12345);
}

Output:
11000000111001
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.

You could use the following (tested) routine for binary output:

int pbin(size_t val, FILE *f) {

if (val)
if (pbin(val / 2, f) < 0) return EOF;
return putc((val & 1) + '0', f);
} /* pbin */

and you can also

#define pbinary(i) pbin(i, stdout)

Note that it mimics putc action on i/o error.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com

Jan 16 '08 #33
Ben Pfaff said:
Kelsey Bjarnason <kb********@gmail.comwrites:
>On Tue, 15 Jan 2008 10:16:14 +0100, jacob navia wrote:
<snip>
>>What I did not know was that
the standard reserved letters for extensions.

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?

Of course, that sort of thing would be fine if you're writing, oh, a
BASIC implementation, but you seem to be flogging it here as a _C_
implementation, which it ain't. As the above demonstrates.

That's too harsh. The %b extension cannot affect the execution
of any strictly conforming program.
Since %b in a printf format specifier is *reserved*, it can acquire a
meaning in future implementations of the Standard with different semantics
to that of the extension. So we have the odd situation that, if we take a
program that *would* be strictly conforming if only it didn't use this %b
extension to mean "give me some binary here", it might in the future
/become/ strictly conforming, at precisely the same time that it suddenly
stops working properly when re-linked to the standard library of an
implementation that conforms to this putative future Standard.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 16 '08 #34
jacob navia wrote:
I am bad bad bad...

:-)

Satisfied?
Nope. The beatings will continue until morale improves...
Jan 16 '08 #35
CBFalconer said:
jacob navia wrote:
>>
... snip ...
>>
lcc-win implements %b
#include <stdio.h>
int main(void) {
printf("%b\n",12345);
}

Output:
11000000111001

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 16 '08 #36
On Wed, 16 Jan 2008 08:44:03 +0000, Mark Bluemel wrote:
jacob navia wrote:
>I am bad bad bad...

:-)

Satisfied?

Nope. The beatings will continue until morale improves...
You say that as if it's ironic or something. ;)
Jan 16 '08 #37
[snips]

On Wed, 16 Jan 2008 05:39:03 +0100, jacob navia wrote:
>Of course, that sort of thing would be fine if you're writing, oh, a BASIC
implementation, but you seem to be flogging it here as a _C_
implementation, which it ain't. As the above demonstrates.

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.
Jan 16 '08 #38
CBFalconer wrote:
jacob navia wrote:
... snip ...
>lcc-win implements %b
#include <stdio.h>
int main(void) {
printf("%b\n",12345);
}

Output:
11000000111001

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
Jan 16 '08 #39
Philip Potter wrote:
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.

Jan 16 '08 #40
Kelsey Bjarnason <kb********@gmail.comwrote:
On Tue, 15 Jan 2008 10:16:14 +0100, jacob navia wrote:
Using the standard when adding extensions? They are, for
obvious reasons, not in the standard. What I did not know was that
the standard reserved letters for extensions.

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
Jan 16 '08 #41
Richard Heathfield wrote:
CBFalconer said:
>jacob navia wrote:
>>>
... snip ...
>>>
lcc-win implements %b
#include <stdio.h>
int main(void) {
printf("%b\n",12345);
}

Output:
11000000111001

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.
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 16 '08 #42
CBFalconer <cb********@yahoo.comwrites:
Richard Heathfield wrote:
>CBFalconer said:
>>jacob navia wrote:

... snip ...

lcc-win implements %b
#include <stdio.h>
int main(void) {
printf("%b\n",12345);
}

Output:
11000000111001

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.

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.

--
Ben.
Jan 16 '08 #43

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

20 posts views Thread by Christian Stigen Larsen | last post: by
10 posts views Thread by J. Campbell | last post: by
14 posts views Thread by Steven T. Hatton | last post: by
3 posts views Thread by Tanuki | last post: by
8 posts views Thread by Yeow | last post: by
25 posts views Thread by Gaurav Verma | last post: by
8 posts views Thread by Bruce Lee | last post: by
7 posts views Thread by elliotng.ee | last post: by
5 posts views Thread by Andrea | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.