how to get binary representation of c objects ?

J

Joachim Schmitz

Mark said:
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
 
J

jacob navia

Joachim said:
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.
 
J

jacob navia

Mark said:
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.
 
M

Mark Bluemel

jacob said:
Mark Bluemel wrote:

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...
 
J

jacob navia

Mark said:
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.
 
M

Mark Bluemel

jacob said:
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.
 
N

noagbodjivictor

Mark stop it.

I have just downloaded lcc-win after trying many implementations, and
now you are saying all these things. I have spent all the whole week
(re)learn C in order to use it...

Jacob, are you serious when you say lcc-win does not have a debugger,
linker, assembler, optimizer?
 
J

James Kuyper

Mark stop it.

I have just downloaded lcc-win after trying many implementations, and
now you are saying all these things. I have spent all the whole week
(re)learn C in order to use it...

Jacob, are you serious when you say lcc-win does not have a debugger,
linker, assembler, optimizer?

Please read more carefully. Jacob said that lcc did not have them, and
as a result he's solely responsible for the ones that were added to lcc-win.
 
J

jacob navia

Mark stop it.

I have just downloaded lcc-win after trying many implementations, and
now you are saying all these things. I have spent all the whole week
(re)learn C in order to use it...

Jacob, are you serious when you say lcc-win does not have a debugger,
linker, assembler, optimizer?

I said "lcc" not lcc-win

"lcc" is a portable compiler designed and implemented by Dave Hanson and
Chris Fraser at ATT.

In 1995 I started working in my version of that, called "lcc-win". I
wrote all the extras, and all the library. When doing the library I
added printf, and I thought that %b would go well with
"binary", for binary representation. Watcom
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.
 
J

jameskuyper

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?
 
F

Flash Gordon

Mark stop it.

I have just downloaded lcc-win after trying many implementations, and
now you are saying all these things. I have spent all the whole week
(re)learn C in order to use it...

If you have learnt C properly (i.e. you know what is part of C and when
you are using something which is an extension) then you can easily move
to another implementation if you want. I am not saying you should, only
you can decide if Jacob's implementation meets your needs or not.
Jacob, are you serious when you say lcc-win does not have a debugger,
linker, assembler, optimizer?

As Jacob has stated, he was referring to lcc rather than lcc-win.
 
B

Bart C

jacob navia wrote:
...

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.
 
C

CBFalconer

Bart said:
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.

All this back-biting does not help either Jacob or his customers.
I suggest he should immediately enable the %B operation, together
with information that it and %b are given identical treatment at
present, and that %b is going to be removed. Ensure the printf
documentation specifies %B, not %b.
 
J

jameskuyper

Bart said:
....
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.
 
K

Kelsey Bjarnason

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.
 
B

Ben Pfaff

Kelsey Bjarnason said:
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.
 
J

jacob navia

Kelsey said:
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?
 
C

CBFalconer

.... 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.
 
R

Richard Heathfield

Ben Pfaff said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top