Should we broaden the topicality of this group?

[Flash Gordon]

Philip Potter wrote, On 03/10/07 09:32:

No. But it's not enough for a question to be answered eventually; if the
answers were (in the main) aggressive and unhelpful enough, the OP may
be put off asking any more questions here.

I agree that if the non-topical material in the C program is clearly not
germane then one should answer the question. I think it is also
appropriate to point out the things which are not standard C and the
things which whilst valid C90 or K&R are not valid C99, or things which
are just plain bad style (e.g. using K&R style declarations). All of
these things can be helpful even though they are not answers to the
question.

One should try to be polite, but no one is perfect so sometimes people
are curt or even down-right rude about it. Sometimes what some people
consider to be a harmless joke (either funny or not) others think is
insulting. Sometimes people simply don't realise how others might
interpret their posts.

Also don't forget that sometimes there is enough non-standard code that
people don't spot the error in the standard code.

(Or they may not. I'm getting into deeply hypothetical territory now,
and I should probably stop.)

I think you are still on meta-topic... ;-)

 

[Malcolm McLean]

There is nothing wrong or "faulty" about non-C compilers. They're
just not appropriate subjects for discussion in this newsgroup, that's
all.

Although it is better to use a standard compiler unless you have a really
good reason for not using it.
Which is actually a problem for people like Jacob Navia. I'm prepared to
accept that his garbage collector, for instance, is a valuable addition to
the language. Certainly I get fed up writing endless code to check for
memory allocation failures and unwind partially-constructed objects, when in
fact all that caller is likely to do is terminate anyway. However I am not
prepared to tie my code to lcc-win for this advantage.

 

[Keith Thompson]

One should try to be polite, but no one is perfect so sometimes people
are curt or even down-right rude about it. Sometimes what some people
consider to be a harmless joke (either funny or not) others think is
insulting. Sometimes people simply don't realise how others might
interpret their posts.

[...]

Rule 1: Try not to be offensive.
Rule 2: Try not to be offended.

This is closely analagous to Postel's Law: "Be conservative in what
you do; be liberal in what you accept from others." (*Please* don't
infer any relationship to US or other political labels.)

 

[Walter Roberson]

It'd be a lot easier for me to join group P if there were comp.lang.c.posix
and comp.lang.c.windows.

If there were a comp.lang.c.posix-1990, I would likely participate.
But not in a comp.lang.c.posix (1996) if it devolved mostly into
discussions of programming threads in C.

When I program in C, I program to C89 when practical; but if the
task inherently involves OS extensions (e.g., serial ports,
multiple processes) then I don't hesitate to use C89 with POSIX.1-1990.
The sum is not the same as comp.unix.programming, which has a wider
scope of languages and less focus on standards.

I am not advocating that -this- become a C + POSIX newsgroup, just
indicating where my C interests lie.

It has been stated that 98% of C programming is for embedded systems
these days; I have no information about whether that is an accurate
figure, but I can say that -I- for one continue to do C scientific and
systems programming.

 

[Richard]

Agreed, and I don't think it happens, in spite of all those decrying
the practice. It's a red herring.

It happens all the time. This is the entire crux of the matter. Falconer
in particular.

 

[Default User]

No. But it's not enough for a question to be answered eventually; if
the answers were (in the main) aggressive and unhelpful enough, the
OP may be put off asking any more questions here.

I agree, and I'm on record as disliking what I consider unhelpful
replies. However, I dispute that such replies are "in the main". I'll
further the challenge to ask for such examples.




Brian

 

[Chris Hills]

No, you seem to be out of touch with c.l.c.

Not at all just with a few of you. From the replies from others it seems
you are the one out of line

Your attitude is fine
on comp.arch.embedded.

I contribute there as well

However here you are discussing some
nebulous non-C compilers, that have some sort of certification for
compiling the unspecified non-C language to some similarly
unspecified runtime environment. From the c.l.c viewpoint the
systems are all faulty.

So there are no-non faulty compilers for C then... That is a ridiculous
and very unhelpful position to take.

Most safety critical and high integrity systems using C are written with
"faulty" compiler according to you! I wonder who is really out of touch
with the real world.

 

[Charlie Gordon]

Although it is better to use a standard compiler unless you have a really
good reason for not using it.
Which is actually a problem for people like Jacob Navia. I'm prepared to
accept that his garbage collector, for instance, is a valuable addition to
the language. Certainly I get fed up writing endless code to check for
memory allocation failures and unwind partially-constructed objects, when
in fact all that caller is likely to do is terminate anyway. However I am
not prepared to tie my code to lcc-win for this advantage.

So you would prefer that an optional GC be supported as an extension by the
Standard, with a specified interface and precise semantics.

 

[CBFalconer]

So you would prefer that an optional GC be supported as an
extension by the Standard, with a specified interface and
precise semantics.

Blithering idiocy and deliberate misinterpretation. Extensions
work in unspecified (by the standard) areas.

 

[Keith Thompson]

Blithering idiocy and deliberate misinterpretation. Extensions
work in unspecified (by the standard) areas.

GC could be an optional language feature; implementations wouldn't be
required to support it, but any that choose to do so (and that claim
conformance to the annex that defines it) must follow the
specification. C99 does this for IEC 60559 floating-point arithmetic
(Annex F).

"Extension" isn't the right word for this kind of thing, but misusing
the word doesn't constitute blithering idiocy.

 

[Malcolm McLean]

So you would prefer that an optional GC be supported as an extension by
the
Standard, with a specified interface and precise semantics.

I haven't thought through the garbage collection issue. However I am not
rejecting the idea out of hand on the grounds that Jacob Navia is a
Frenchman, or promotes his compiler too vigorously on clc, or likes trading
names with Richard Heathfield.

However it does need some sort of standardisation or de facto
standardisation before most people can use it. The most important
relationship is dependency. If I put some code on my website and also a link
to lcc-win, and say "download this, rejig your entire compiler set-up, and
then you can use my options-parsing routine, and you'll have a better
compiler to boot", it will simply be a nuisance to everyone. The benefit is
we can get rid of the "killoptions" call after finishing parsing - worth
having, but not worth all that.

 

[Richard Heathfield]

Malcolm McLean said:

I haven't thought through the garbage collection issue. However I am not
rejecting the idea out of hand on the grounds that Jacob Navia is a
Frenchman, or promotes his compiler too vigorously on clc, or likes
trading names with Richard Heathfield.

On that subject, it occurs to me that the topicality threads I started last
week have now served their purpose, so I'll be re-enabling my filter to
cut down on some of the noise.

Incidentally, whilst the filter was off, I noted that Mr Navia had posted a
link to a Linux version of lcc-win32, so I figured I'd do a little light
testing. I followed the installation instructions, such as they are, and
couldn't even get "hello, world" to compile.

Maybe it's just me. <shrug>

For the record, the error message I got was:

lcc: error while loading shared libraries: libbfd-2.11.92.0.12.so: cannot
open shared object file: No such file or directory

The mentioned file is in /usr/local/lib as required. I even copied it into
/usr/local/bin on the off-chance, but that didn't help.

So, as far as I'm concerned, the Linux implementation of lcc-win32 is
broken. I am not overly worried about this, since I already have a
perfectly good Linux compiler.

Nevertheless, in the interests of fairness, I'll leave my filter off for
another day or two to give Mr Navia a chance to reply politely and
intelligently, explaining what must be done to get the compiler to work.
Obviously he doesn't have to do that, but neither do I have to consider
the Linux version of lcc to be a working implementation if the best
information I have is that it is not.

 

[santosh]

Malcolm McLean said:



On that subject, it occurs to me that the topicality threads I started last
week have now served their purpose, so I'll be re-enabling my filter to
cut down on some of the noise.

Incidentally, whilst the filter was off, I noted that Mr Navia had posted a
link to a Linux version of lcc-win32, so I figured I'd do a little light
testing. I followed the installation instructions, such as they are, and
couldn't even get "hello, world" to compile.

Maybe it's just me. <shrug>

For the record, the error message I got was:

lcc: error while loading shared libraries: libbfd-2.11.92.0.12.so: cannot
open shared object file: No such file or directory

The mentioned file is in /usr/local/lib as required. I even copied it into
/usr/local/bin on the off-chance, but that didn't help.

Yes, I have encountered the same problem. A funny thing I note is that
while the executables and the libraries are to be placed, (according
to jacob's instructions), in /usr/local/bin/ and /usr/local/lib/, the
headers are to be placed into /usr/include/lcc/.

This seems inconsistent. Either all the files should be in the /usr/*
hierarchy or in the /usr/local/* hierarchy, not smeared out all over
the system. Also some shared and static libraries are copied into the /
usr/local/bin/ directory along with the 'lcc' executable, a bad idea.

Additionally the compiler does not mention exactly _which_ file it
couldn't open. The full path name that was attempted to be opened
should be print, not simply an error that says "I couldn't open foo."

So, as far as I'm concerned, the Linux implementation of lcc-win32 is
broken. I am not overly worried about this, since I already have a
perfectly good Linux compiler.
Yes.

Nevertheless, in the interests of fairness, I'll leave my filter off for
another day or two to give Mr Navia a chance to reply politely and
intelligently, explaining what must be done to get the compiler to work.
Obviously he doesn't have to do that, but neither do I have to consider
the Linux version of lcc to be a working implementation if the best
information I have is that it is not.

Ah I just remembered. He says that lcc can only _compile_ not link
under Linux. Use the '-c' flag to compile and use the regular system
linker to link, via gcc.

I just tried:

lcc -c hello.c

and

lcc -ansic -c hello.c

Same error.

Furthermore lcc does not respond to the universal UNIX conventions of
the '-h' and '--help' flags, and print an usage message. In fact just
invoking 'lcc' with no other arguments still gives the error message.

The compiler seems to be totally broken.

 

[santosh]

I found a temporary fix. Copy the above file to /usr/lib/ and things
seem to work. At least a hello world program could be compiled and
run.

Obviously the implementation has numerous Windows specific
assumptions.

<snip rest>

 

[Mark McIntyre]

I found a temporary fix. Copy the above file to /usr/lib/ and things
seem to work. At least a hello world program could be compiled and
run.

but to be fair to JN, he is at least trying and it is a very recent
release i think.

Obviously the implementation has numerous Windows specific
assumptions.

hopefully those will get ironed out over the coming months.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[jacob navia]

I found a temporary fix. Copy the above file to /usr/lib/ and things
seem to work. At least a hello world program could be compiled and
run.

Obviously the implementation has numerous Windows specific
assumptions.

<snip rest>

Hello Santosh

Obviously the shared object must be in your loader path...
I mean I can't fix that, it is up to the user now, because I did
not write an installation program yet.

Obviously too, /usr/lib is "windows specific"

I have worked in that version for months and months.
An assembler must be written, and I made the STRATEGIC MISTAKE of
using libbfd.so, with the assumption that that library
would be available in the user machine. Nope.

Besides, the debug information format under linux is different
than the one I use under windows. Since I can't write a debugger
now, as I did under windows, I must generate gdb compatible
debug information. This is done now.

I am changing the compiler now to use /usr/local/lcc, and added
following paths to the include search path:

/usr/local/lcc/include
/usr/local/include
/usr/include/lcc
/usr/include

I will try to write the driver tomorrow

Thanks for your input but please, think on the work
behind that program

 

[santosh]

Hello Santosh

I've cross-posted this to comp.compilers.lcc and set follow-ups to it.
Hope you don't mind.

Obviously the shared object must be in your loader path...
I mean I can't fix that, it is up to the user now, because I did
not write an installation program yet.

But you could have at least mentioned the issue.

Obviously too, /usr/lib is "windows specific"

I didn't say that.

I have worked in that version for months and months.
An assembler must be written,

Why can't you port the assembler that comes with lcc-win32? Or perhaps
use as? Or even emit object code directly?

and I made the STRATEGIC MISTAKE of
using libbfd.so, with the assumption that that library
would be available in the user machine. Nope.

It's not a mistake. You can just list libbfd as a prerequisite for
lcc-linux32. It easy enough to download, compile and install. Besides
it's becoming rather standard under most Linux distributions.

Besides, the debug information format under linux is different
than the one I use under windows. Since I can't write a debugger
now, as I did under windows, I must generate gdb compatible
debug information. This is done now.

Nice. Are all the command-line switches documented in the user manual
under Windows applicable? I think you should include a small file that
explain which switches are implemented and which are not.

I was rather annoyed to see that the usage message was not available.
What's so system specific about printing a bunch of strings to
stdout?

I am changing the compiler now to use /usr/local/lcc, and added
following paths to the include search path:

/usr/local/lcc/include

This should almost certainly be /usr/local/include/lcc/

/usr/local/include
/usr/include/lcc
/usr/include

In my opinion you should neatly encapsulate lcc's headers in it's
own 'lcc' sub-directory under the system include directories. That way
you don't need to bother with /usr/include/ and /usr/local/include/

I will try to write the driver tomorrow

Thanks for your input but please, think on the work
behind that program

Yes, I understand. I'm pleased that I can try out your compiler natively
under Linux with all the complications of WINE.

 

[CBFalconer]

but to be fair to JN, he is at least trying and it is a very
recent release i think.


hopefully those will get ironed out over the coming months.

The raw experience of trying to make something port, even if on the
same underlying hardware, may finally cause Jacob to appreciate the
purpose of c.l.c.

 

[Pierre Asselin]

lcc: error while loading shared libraries: libbfd-2.11.92.0.12.so: cannot
open shared object file: No such file or directory

The mentioned file is in /usr/local/lib as required. I even copied it into
/usr/local/bin on the off-chance, but that didn't help.

Did you run ldconfig (as root) after copying the libbfd.so ?
Oops, off-[meta]topic. Sorry.

 

[Richard Heathfield]

Pierre Asselin said:

Did you run ldconfig (as root) after copying the libbfd.so ?

The installation instructions did not specify this as a requirement. If
they had done so, I would have expected them also to mention why this was
necessary, what potential harm it could do to my system, and how I can
back out of the change if I later decide I don't want to use the software.

Personally, I prefer the "I won't write an installer for you - if you want
to run it, *you* install it - here are the steps you need" school of
software installation, because it gives you more control over what's going
on, and lets you decide intelligently whether the installation game is
worth the security candle.

When I am writing software for "normal" people - i.e. non-programmers,
non-propeller-heads, typically Windows users, not interested in anything
but "please just make it work" kind of people, I normally just give them
the binary. Nothing else. And no instructions. This works fine, because
they manage to work out all by themselves that there are no installation
steps to take (except, possibly, copying onto the hard disk), and
uninstallation is as simple as deleting the binary. About the only thing I
do tell them is "this doesn't write anything in your registry" (even
though I just get a blank look in return).

Okay okay, this reply really belonged in comp.programming - but I've just
written a C article in that group...