By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,958 Members | 1,179 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,958 IT Pros & Developers. It's quick & easy.

Curses for win32 with VT100/ANSI support

P: n/a
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.

1. No, I don't want to use cygwin
2. Yes, I know pdcurses, it is great and I plan to use it for normal
ncurses consoles but I need a socket-bound vt100 terminal library...

Thank you!

--
Daniele C.

May 21 '06 #1
Share this Question
Share on Google+
48 Replies


P: n/a
"Daniele C." <le********@users.sourceforge.net> writes:
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.


Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 21 '06 #2

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
"Daniele C." <le********@users.sourceforge.net> writes:
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.


Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)


This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 21 '06 #3

P: n/a
Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
"Daniele C." <le********@users.sourceforge.net> writes:
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind. Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)


This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

The OP is trying to *implement* a networked ncurses on a particular
platform. This is going to involve OS or library-specific stuff, unless you
believe in magic.
This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific

Very little of this will be C specific too, and that's what this newsgroup
is about. There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another matter.

S.
May 21 '06 #4

P: n/a
In article <44***********************@news.xs4all.nl>, Skarmander
<in*****@dontmailme.com> writes
Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
"Daniele C." <le********@users.sourceforge.net> writes:
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.
Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)
This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

The OP is trying to *implement* a networked ncurses on a particular
platform. This is going to involve OS or library-specific stuff, unless you
believe in magic.


SO there will be some OS specific parts of the code. The majority will
not be. Unless this NG is ONLY for pure portable ISO C99 code. As the NG
is not for that he can post here.
This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific

Very little of this will be C specific too, and that's what this newsgroup
is about.


It's written in C which is what this NG is about.
There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another matter.


Wrong. but you are entitled to your opinion.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 21 '06 #5

P: n/a
Chris Hills <ch***@phaedsys.org> writes:
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
"Daniele C." <le********@users.sourceforge.net> writes:
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.


Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)


This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific


He wasn't asking about the code. He wasn't asking how to implement
anything. He was asking whether anyone else had already implemented
such a library *for win32*. That's not a C question.

The Linux kernel is written in C; that doesn't make a question about
porting it to some specific platform topical here. Ditto for any of
the thousands of other software packages implemented in C.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 21 '06 #6

P: n/a
"Chris Hills" <ch***@phaedsys.org> wrote
In article Skarmander <in*****@dontmailme.com> writes
Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
"Daniele C." <le********@users.sourceforge.net> writes:
> As soon as my sourceforge.net project gets approved, I am going to
> build a ncurses port to win32 bindable to sockets, e.g. allowing
> VT100/ANSI terminals and the creation of simple terminal servers using
> the ncurses API for the UI. I plan to initially support only a subset
> of the ncurses lib, leaving the lib open to expansion/completion.
>
> Please stop me if I am going to reinvent the wheel, and tell me if
> there are any libraries of this kind.
Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)

This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.
The OP is trying to *implement* a networked ncurses on a particular
platform. This is going to involve OS or library-specific stuff, unless
you
believe in magic.


SO there will be some OS specific parts of the code. The majority will
not be. Unless this NG is ONLY for pure portable ISO C99 code. As the NG
is not for that he can post here.

And if I write a knitting program, probably the stitch database and most of
the logic will be implemented in portable ANSI C, with only a minor
Windows-specific user interface.
Does that make the knitting / crotchet debate topical here?
It's written in C which is what this NG is about.
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.
There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another
matter.


Wrong. but you are entitled to your opinion.

We could allow it, but it would be expanding the scope of the group. I've no
use for a curses system, for instance. If I need a non-stream user interface
I'll use a windowing library, or html forms, or Java.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
May 21 '06 #7

P: n/a
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote
In article Skarmander <in*****@dontmailme.com> writes
Chris Hills wrote:

There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another
matter.


Wrong. but you are entitled to your opinion.

We could allow it,


You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 22 '06 #8

P: n/a
Chris Hills <ch***@phaedsys.org> writes:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote
In article Skarmander <in*****@dontmailme.com> writes
Chris Hills wrote:

There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another
matter.

Wrong. but you are entitled to your opinion.

We could allow it,


You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.

It seems clear to me that any answer to the OP's actual question would
not be based on a knowledge of the C programming language.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 22 '06 #9

P: n/a
On 2006-05-22, Keith Thompson <ks***@mib.org> wrote:
Chris Hills <ch***@phaedsys.org> writes:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote
In article Skarmander <in*****@dontmailme.com> writes
>Chris Hills wrote:

> There are no questions about the C language here. If there are
>questions about what's portable and what's not, that would be another
>matter.

Wrong. but you are entitled to your opinion.

We could allow it,
You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.


The problem is that it's not clear what authority your opinion on what
was the pre-existing "scope of the group" which "allowing" this would be
"expanding" is based on.
It seems clear to me that any answer to the OP's actual question would
not be based on a knowledge of the C programming language.

May 22 '06 #10

P: n/a
On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.


Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around. Curses would just
be an unneccessary pain for compiler writers.

The only addition to the library that I think is feasable would be some
decent networking functions; all systems have networks, with the exception
of embedded systems, which already have their special small library.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
Get your game faces on, because this is not a game.
May 22 '06 #11

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
Chris Hills <ch***@phaedsys.org> writes:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote
In article Skarmander <in*****@dontmailme.com> writes
>Chris Hills wrote:

> There are no questions about the C language here. If there are
>questions about what's portable and what's not, that would be another
>matter.

Wrong. but you are entitled to your opinion.

We could allow it,


You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.


TO be more accurate *I* have a say in the matter but not an effective
enforcement system to correct you..... :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 22 '06 #12

P: n/a
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.
Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around.


This is incorrect. In fact this is one place where you probably might
need curses.
Curses would just
be an unneccessary pain for compiler writers.
Why? Compiler writers write compilers not libraries.
Library writers write libraries.
The only addition to the library that I think is feasable would be some
decent networking functions;
Not really there are far to many types of network to do a standard
network library.
all systems have networks,
Completely untrue by a VERY long way.
with the exception
of embedded systems,
Lots of embedded systems have networks of one sort or another. Profi,
CAN and LIN for starters.
which already have their special small library.


Complete bollox.

You seem to have a very limited knowledge of things.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 22 '06 #13

P: n/a
Chris Hills <ch***@phaedsys.org> writes:
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
Chris Hills <ch***@phaedsys.org> writes:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote
> In article Skarmander <in*****@dontmailme.com> writes
>>Chris Hills wrote:
>
>> There are no questions about the C language here. If there are
>>questions about what's portable and what's not, that would be another
>>matter.
>
> Wrong. but you are entitled to your opinion.
>
We could allow it,

You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.


TO be more accurate *I* have a say in the matter but not an effective
enforcement system to correct you..... :-)


I fail to see how that's more (or less) accurate that what I wrote.

The original question was about whether anyone had implemented a
certain kind of curses/ncurses library for win32 (something to do with
sockets; I don't remember the details). The OP was about to start
work on such a project, and wanted to avoid re-inventing the wheel.

Chris, can you explain just how such a question has anything to do
with the C programming language? I know that ncurses happens to be
implemented in C, but the OP wasn't asking about how to implement it.

I see absolutely nothing in the original question such that a
knowledge of the C programming language would be helpful in providing
an answer.

Why do you continue to insist that the question was topical? That's a
serious question.

(To be clear, I'm not angry at the OP for asking an off-topic
question; mistakes happen.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 22 '06 #14

P: n/a
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.
Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around.


This is incorrect. In fact this is one place where you probably might
need curses.

curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.
Curses would just
be an unneccessary pain for compiler writers.


Why? Compiler writers write compilers not libraries.
Library writers write libraries.

I stand corrected.
The only addition to the library that I think is feasable would be some
decent networking functions;


Not really there are far to many types of network to do a standard
network library.
all systems have networks,


Completely untrue by a VERY long way.

Not too far off; a system needs to communicate with the outside world
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.
with the exception
of embedded systems,


Lots of embedded systems have networks of one sort or another. Profi,
CAN and LIN for starters.

I should have said *some* embedded systems, which I thought was implied
by not stating *all* embedded systems.
which already have their special small library.


Complete bollox.

No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.
You seem to have a very limited knowledge of things.

That is true for everyone, no? ;-)

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
Get your game faces on, because this is not a game.
May 22 '06 #15

P: n/a
In article <oq**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
We could allow it,

You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


What charter? There is no hierarchy charter for comp or comp.lang
and comp.lang.c was created without reference to a charter.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
May 23 '06 #16

P: n/a
In article <sl**********************@localhost.localdomain> ,
Andrew Poelstra <ap*******@localhost.localdomain> wrote:
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne73pph.jdj.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
all systems have networks,
Completely untrue by a VERY long way.
Not too far off; a system needs to communicate with the outside world
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.


Input:

Keyboards (for typing), keyboards (musical type), touch-screen,
stylis, magnetic card, RFID chip, camera... even punch cards still
(e.g., some fare collection systems)

Output:

CRT, LCD displays, LCD screens, LED displays, plasma, printers
(inkjet, thermal, laser, photo), rewrite magnetic card, speakers,
CD/DVD writer...

Bidirectional:

Serial ports, parallel ports, infrared (e.g., PalmPilot), CD/DVD RW,
USB, USB memory stick, radio...
Consider for example cheap programmable calculators. Are they
"embedded" ? It could be so argued, but if they are programmable then
the distinction between embedded and not becomes blurred.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
May 23 '06 #17

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <oq**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes

We could allow it,

You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


What charter? There is no hierarchy charter for comp or comp.lang
and comp.lang.c was created without reference to a charter.


He knows that. I'm sure that was his point.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 23 '06 #18

P: n/a
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <oq**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes

We could allow it,

You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


What charter? There is no hierarchy charter for comp or comp.lang
and comp.lang.c was created without reference to a charter.


He knows that. I'm sure that was his point.


It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.
May 23 '06 #19

P: n/a
Jordan Abel <ra*******@gmail.com> writes:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <oq**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes

>We could allow it,

You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.

What charter? There is no hierarchy charter for comp or comp.lang
and comp.lang.c was created without reference to a charter.


He knows that. I'm sure that was his point.


It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.


I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 23 '06 #20

P: n/a
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <oq**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:
>In article <ya******************************@bt.com>, Malcolm
><re*******@btinternet.com> writes

>>We could allow it,

>You can not dis-allow it. You can have no say in the matter. I refer you
>to the charter.

What charter? There is no hierarchy charter for comp or comp.lang
and comp.lang.c was created without reference to a charter.

He knows that. I'm sure that was his point.


It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.


I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.


What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?
May 23 '06 #21

P: n/a
Jordan Abel said:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:

It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.


I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.


What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?


Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether many
of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins, Pfaffs,
etc) would stick around clc if it descended into a maelstrom of questions
about C#.NET, broken sockets programs, and so on.

If we want to discuss lcc-win32, there's already a newsgroup for that. If we
want to discuss Unix programming, there's already a group for that, too. If
we want to talk about Windows or C# or sockets, there are groups for those.
If we want to talk about future directions of the language, there's
comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can talk
about C without the group being cluttered up with platform-specific stuff?
I don't know of one. Do you?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
May 23 '06 #22

P: n/a
On 23 May 2006 12:23:03 GMT, Jordan Abel <ra*******@gmail.com> wrote:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
> In article <oq**************@phaedsys.demon.co.uk>,
> Chris Hills <ch***@phaedsys.demon.co.uk> wrote:
>>In article <ya******************************@bt.com>, Malcolm
>><re*******@btinternet.com> writes
>
>>>We could allow it,
>
>>You can not dis-allow it. You can have no say in the matter. I refer you
>>to the charter.
>
> What charter? There is no hierarchy charter for comp or comp.lang
> and comp.lang.c was created without reference to a charter.

He knows that. I'm sure that was his point.

It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.


I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.


What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?


A little time spent researching the archives would show you that such
a consensus exists among those who actually answer the questions here
;-)

We have an outstanding group of experts on tap. I'm grateful that they
donate their time and expertise, and don't want this group to turn
into a place they'll avoid.

--
Al Balmer
Sun City, AZ
May 23 '06 #23

P: n/a
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne73pph.jdj.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.

Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around.
This is incorrect. In fact this is one place where you probably might
need curses.

curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.


wrong again...

Curses would just
be an unneccessary pain for compiler writers.


Why? Compiler writers write compilers not libraries.
Library writers write libraries.

I stand corrected.
The only addition to the library that I think is feasable would be some
decent networking functions;


Not really there are far to many types of network to do a standard
network library.
all systems have networks,


Completely untrue by a VERY long way.

Not too far off; a system needs to communicate with the outside world


Many systems do not need to communicate with the outside world
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.
Yes.... some sort of communication but not always a network.

What sort of network library did you have in mind?

with the exception
of embedded systems,


Lots of embedded systems have networks of one sort or another. Profi,
CAN and LIN for starters.

I should have said *some* embedded systems, which I thought was implied
by not stating *all* embedded systems.


SO what sort of network library were you thinking of?
which already have their special small library.


Complete bollox.

No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.


Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.
You seem to have a very limited knowledge of things.

That is true for everyone, no? ;-)


No. Some are far more limited than others.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 23 '06 #24

P: n/a
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:

It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.

I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.
What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?


Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether many
of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins, Pfaffs,
etc) would stick around clc if it descended into a maelstrom of questions
about C#.NET, broken sockets programs, and so on.


C# is not C. By most sane definitions, the language accepted by gcc
isn't "not C."

If we want to discuss lcc-win32, there's already a newsgroup for that. If we
want to discuss Unix programming, there's already a group for that, too. If
we want to talk about Windows or C# or sockets, there are groups for those.
If we want to talk about future directions of the language, there's
comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can talk
about C without the group being cluttered up with platform-specific
stuff? I don't know of one. Do you?


Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms? For
example, big-endian-to-host-endian conversion, or struct packing. Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.
May 23 '06 #25

P: n/a
On 23 May 2006 17:14:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
>
> It's never been clear to me why it requires more of a consensus to
> change this "policy" than it apparently did to create it in the first
> place.

I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.

What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?
Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether many
of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins, Pfaffs,
etc) would stick around clc if it descended into a maelstrom of questions
about C#.NET, broken sockets programs, and so on.


C# is not C. By most sane definitions, the language accepted by gcc
isn't "not C."

If we want to discuss lcc-win32, there's already a newsgroup for that. If we
want to discuss Unix programming, there's already a group for that, too. If
we want to talk about Windows or C# or sockets, there are groups for those.
If we want to talk about future directions of the language, there's
comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can talk
about C without the group being cluttered up with platform-specific
stuff? I don't know of one. Do you?


Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms?


"How to write a header" and how to use the preprocessor to produce
different code for different defines (platforms) is topical here. The
details of tailoring specific code to specific processors is not.
For
example, big-endian-to-host-endian conversion, or struct packing. Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


Try comp.programming.

--
Al Balmer
Sun City, AZ
May 23 '06 #26

P: n/a
Al Balmer said:
On 23 May 2006 17:14:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:
Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


Try comp.programming.


In a way, the topic of comp.programming is even more limited than that of
comp.lang.c, insofar as discussions of specific /languages/ is, strictly
speaking, off-topic, let alone specific platforms.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
May 23 '06 #27

P: n/a
Chris Hills wrote:
In article <44***********************@news.xs4all.nl>, Skarmander
<in*****@dontmailme.com> writes
Chris Hills wrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
"Daniele C." <le********@users.sourceforge.net> writes:
> As soon as my sourceforge.net project gets approved, I am going to
> build a ncurses port to win32 bindable to sockets, e.g. allowing
> VT100/ANSI terminals and the creation of simple terminal servers using
> the ncurses API for the UI. I plan to initially support only a subset
> of the ncurses lib, leaving the lib open to expansion/completion.
>
> Please stop me if I am going to reinvent the wheel, and tell me if
> there are any libraries of this kind.
Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)
This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

The OP is trying to *implement* a networked ncurses on a particular
platform. This is going to involve OS or library-specific stuff, unless you
believe in magic.


SO there will be some OS specific parts of the code. The majority will
not be. Unless this NG is ONLY for pure portable ISO C99 code. As the NG
is not for that he can post here.

The answer to the OP's original question, "am I reinventing the wheel if I
implement a networked ncurses for Win32", is best answered elsewhere. Your
bold assertion that it has "bugger all to do with Windows" seems slightly
exaggerated.

There is no question that if the OP has questions specific to C (which isn't
necessarily "pure portable ISO C99 code", if only because pointing out
portability issues is just as relevant) then those questions can be posted here.
This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific

Very little of this will be C specific too, and that's what this newsgroup
is about.


It's written in C which is what this NG is about.

Not that old chestnut again. Any algorithm can be expressed in C. If
therefore any algorithm expressed in C becomes topical, this newsgroup would
become a whole lot less useful, since the C experts would get fed up with
the volume of chaff and leave. A newsgroup where anything expressed in C is
topical is just not half as good as a newsgroup where the C programming
language is topical.
There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another matter.


Wrong. but you are entitled to your opinion.

Thanks. You tolerating my opinion means a lot to me.

S.
May 23 '06 #28

P: n/a
Jordan Abel said:
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:

Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether
many of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins,
Pfaffs, etc) would stick around clc if it descended into a maelstrom of
questions about C#.NET, broken sockets programs, and so on.
C# is not C.


Indeed. And neither are sockets, or GTK+, or Win32 API, etc.
By most sane definitions, the language accepted by gcc
isn't "not C."
Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.
If we want to discuss lcc-win32, there's already a newsgroup for that. If
we want to discuss Unix programming, there's already a group for that,
too. If we want to talk about Windows or C# or sockets, there are groups
for those. If we want to talk about future directions of the language,
there's comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can
talk about C without the group being cluttered up with platform-specific
stuff? I don't know of one. Do you?


Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms?


As Al Balmer said, the C parts of such a discussion are topical. Groups
exist that provide support for specific platforms.
For
example, big-endian-to-host-endian conversion, or struct packing.
Implementations provide this kind of information in their documentation.
Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


If there is sufficient demand for such a group, no doubt one will be
created. In the meantime, the absence of a newsgroup where <foo> is topical
does not ipso facto make it a good idea to make <foo> topical in
comp.lang.c.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
May 23 '06 #29

P: n/a
On 2006-05-23, Al Balmer <al******@att.net> wrote:
On 23 May 2006 17:14:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:

On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
> Jordan Abel <ra*******@gmail.com> writes:
>>
>> It's never been clear to me why it requires more of a consensus to
>> change this "policy" than it apparently did to create it in the first
>> place.
>
> I'm not sure what you mean. I don't know what would be required to
> change the current de facto policy, but I haven't seen any consensus
> to change it.

What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?

Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether many
of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins, Pfaffs,
etc) would stick around clc if it descended into a maelstrom of questions
about C#.NET, broken sockets programs, and so on.


C# is not C. By most sane definitions, the language accepted by gcc
isn't "not C."

If we want to discuss lcc-win32, there's already a newsgroup for that. If we
want to discuss Unix programming, there's already a group for that, too. If
we want to talk about Windows or C# or sockets, there are groups for those.
If we want to talk about future directions of the language, there's
comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can talk
about C without the group being cluttered up with platform-specific
stuff? I don't know of one. Do you?


Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms?


"How to write a header" and how to use the preprocessor to produce
different code for different defines (platforms) is topical here. The
details of tailoring specific code to specific processors is not.


Is #ifdef __GNUC__ topical here? Regardless of the topicality of
anything in it.
For
example, big-endian-to-host-endian conversion, or struct packing.

Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


Try comp.programming.

May 23 '06 #30

P: n/a
On Tue, 23 May 2006 17:47:45 +0000, Richard Heathfield
<in*****@invalid.invalid> wrote:
Al Balmer said:
On 23 May 2006 17:14:13 GMT, Jordan Abel <ra*******@gmail.com> wrote:
Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


Try comp.programming.


In a way, the topic of comp.programming is even more limited than that of
comp.lang.c, insofar as discussions of specific /languages/ is, strictly
speaking, off-topic, let alone specific platforms.


True, according to its charter. In practice, though, discussions of
problems take place with respect to specific languages and platforms
all the time, and (probably more important) the range of available
expertise is not limited to specific topics. (Re-reading that, it's
not quite what I'm struggling to say, but the audience here will
understand ...).

In any case, Jordan is talking about issues which transcend a specific
platform, and I can't think of a better place.

--
Al Balmer
Sun City, AZ
May 23 '06 #31

P: n/a
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said:
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:

Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether
many of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins,
Pfaffs, etc) would stick around clc if it descended into a maelstrom of
questions about C#.NET, broken sockets programs, and so on.
C# is not C.


Indeed. And neither are sockets, or GTK+, or Win32 API, etc.
By most sane definitions, the language accepted by gcc
isn't "not C."


Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.


Yours is an example of what I would not call a "sane definition"

I didn't say it was C. I said it wasn't "not C".
If we want to discuss lcc-win32, there's already a newsgroup for that. If
we want to discuss Unix programming, there's already a group for that,
too. If we want to talk about Windows or C# or sockets, there are groups
for those. If we want to talk about future directions of the language,
there's comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can
talk about C without the group being cluttered up with platform-specific
stuff? I don't know of one. Do you?


Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms?


As Al Balmer said, the C parts of such a discussion are topical. Groups
exist that provide support for specific platforms.


Are the #ifdefs topical? Not the directive itself, but the discussion of
what constant identifies what set of platforms.
For
example, big-endian-to-host-endian conversion, or struct packing.


Implementations provide this kind of information in their
documentation.
Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


If there is sufficient demand for such a group, no doubt one will be
created. In the meantime, the absence of a newsgroup where <foo> is topical
does not ipso facto make it a good idea to make <foo> topical in
comp.lang.c.


Where would you have them go?
May 23 '06 #32

P: n/a
In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:
Is #ifdef __GNUC__ topical here? Regardless of the topicality of
anything in it.


Yes, but there is very little to say about it here: we can say
that __GNUC__ is in the namespace reserved for any use, and we can
talk generally about what #ifdef means. But any instance in
which the #ifdef does not evaluate to false is implementation-
defined behaviour that is not on topic here.
--
All is vanity. -- Ecclesiastes
May 23 '06 #33

P: n/a
In article <sl**********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:
Are the #ifdefs topical? Not the directive itself, but the discussion of
what constant identifies what set of platforms.


No, that is too implementation. The pre-defined macros depend
upon hardware, OS version, compiler version, applied patches, compiler
switches, and compiler extensions (e.g., a #pragma might result in
new predefined macros coming into effect.) The only way to discuss
and catalogue the possibilities would be to get into highly platform
dependant discussions.

Any question that requires reference to platform documentation for
resolution is off-topic here beyond the extent of establishing that
it is platform dependant.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
May 23 '06 #34

P: n/a
Jordan Abel <ra*******@gmail.com> writes:
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said: [...]
Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.


Yours is an example of what I would not call a "sane definition"

I didn't say it was C. I said it wasn't "not C".


Perhaps you'd care to explain that. Logically, everything in the
universe is exactly one of "C" or "not C".

[...]
Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.


If there is sufficient demand for such a group, no doubt one will be
created. In the meantime, the absence of a newsgroup where <foo> is topical
does not ipso facto make it a good idea to make <foo> topical in
comp.lang.c.


Where would you have them go?


To a newsgroup or other forum where it's topical. If there isn't one,
how is that our problem?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
May 23 '06 #35

P: n/a
Al Balmer wrote:
Jordan Abel <ra*******@gmail.com> wrote:

.... snip ...

Where would you have someone go to hear about how to write a
header that needs to support platform-specific stuff on multiple
platforms?


"How to write a header" and how to use the preprocessor to produce
different code for different defines (platforms) is topical here. The
details of tailoring specific code to specific processors is not.
For example, big-endian-to-host-endian conversion, or struct packing.

Any one platform-specific group is going to just say how to do it
with _their_ platform, and if you're lucky they'll also give you
a tiny piece of the #ifdef puzzle. Even then, it might be nice to
have someone chime in with an explanation of how to make it work
with some platform you haven't heard of and so didn't have in mind
in advance.


Try comp.programming.


Please don't. That is more for algorithms than system specific
stuff, although the denizens are quite tolerant. Get the specific
requirements from the system specific newsgroups, and integrate
into your isolated non-portable source modules.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
May 23 '06 #36

P: n/a
On 23 May 2006 12:23:03 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?


Oh gawd, here we go again .

Boring, boring boring.

*threadplonk*

--
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
May 23 '06 #37

P: n/a
On 2006-05-23, Chris Hills <ch***@phaedsys.org> wrote:
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne73pph.jdj.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
> The difference is that a curses library is something that programmers use.
> There is a case for including it in the standard library, though in fact the
> ANSI library has no such functions.

Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around.

This is incorrect. In fact this is one place where you probably might
need curses.

curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.


wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?
The only addition to the library that I think is feasable would be some
decent networking functions;

Not really there are far to many types of network to do a standard
network library.

all systems have networks,

Completely untrue by a VERY long way.

Not too far off; a system needs to communicate with the outside world


Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.


Yes.... some sort of communication but not always a network.

What sort of network library did you have in mind?

Something similar to stdio.h, I suppose. Or an extension of stdio.

FILE *sh = fopen("192.168.0.100", "n");
fprintf(sh, "Hello, other machine!\n");

You might suggest that not all networks use IP, but not all systems
use the same filesystem (and indeed there is much more diversity
there), and yet fopen for files is standardized. My first
statement is just as portable as fopen("/etc/hosts", "r").
which already have their special small library.

Complete bollox.

No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.


Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.

Refuting the credibility of the C standard on clc is not a very good
idea. ;-)
You seem to have a very limited knowledge of things.

That is true for everyone, no? ;-)


No. Some are far more limited than others.

The truthhood of a statement is binary; either a person is very
limited or they are not. While your second statement is true,
the first ("No.") is not logically connected to it.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
It's just like stealing teeth from a baby.
May 23 '06 #38

P: n/a
On 2006-05-23, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-05-23, Richard Heathfield <in*****@invalid.invalid> wrote:
Jordan Abel said: [...] Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.
Yours is an example of what I would not call a "sane definition"

I didn't say it was C. I said it wasn't "not C".


Perhaps you'd care to explain that. Logically, everything in the
universe is exactly one of "C" or "not C".


The phrase has a meaning which goes beyond the simple logical analysis
of the words. I'd say that for something to be "not C" it requires
a level of difference that mere addition of extra library functions,
a few extra reserved keywords, some more pre-defined macros, and
a bizarre mixture of c89 and c99, can provide. All of them (except a few
of the predefined macros in question) are permitted by the standard.

Those few predefined macros, like unix=1, are the ones that are possibly
the _most_ topical in here precisely _because_ you can run into
a problem compiling a strictly conforming program. In fact, those,
I think are actually on-topic, because

In <bnews.eagle.565> (1982-10-21) eagle!jerry wrote:
.... Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.


I'd say that it falls under "compiler bugs" in a way that still applies
in the modern incarnation of what's appropriate.
May 24 '06 #39

P: n/a
Jordan Abel wrote:
"not C"


Godwin's Law: The thread is over.

--
pete
May 24 '06 #40

P: n/a
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-23, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne74ec4.2ug.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne73pph.jdj.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
>On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
>> The difference is that a curses library is something that programmers use.
>> There is a case for including it in the standard library, though in factthe>> ANSI library has no such functions.
>
>Not a lot of systems have a screen. I've programmed routers with which I
>communicated with entirely by FTPing log files around.

This is incorrect. In fact this is one place where you probably might
need curses.

curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.
wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?


Yes. However that screen or terminal my not be connected to the system
all the time.

I have set up things like routes using a terminal connected to the
engineers rs232 port. When I worked on comms equipment there was always
a serial port for local initialisation etc. Usually a VT100 to VT52
terminal emulation was used. Curses would have been used for that.

Not everything has a web server built into it. Particularly as they are
not universal. A Vt100 or VT52 only needs a 40 col 25 line mono screen.
Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.


Toys, microwave ovens, fridges, dish washers, washing machines, bombs,
batteries.... the list is endless.

Very many embedded systems do not need to communicate outside their own
system. Many systems after they are switched on are automatic.
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.


Yes.... some sort of communication but not always a network.

What sort of network library did you have in mind?

Something similar to stdio.h, I suppose. Or an extension of stdio.

FILE *sh = fopen("192.168.0.100", "n");
fprintf(sh, "Hello, other machine!\n");


That already exists

However most safety critical or high integrity systems are not likely to
use stdio anyway.

Besides fprintf is of little use for fieldbus, CAN Lin etc.
You might suggest that not all networks use IP,
Not by a VERY long way. Automotive systems use CAN and LIN The busses
for all these systems and in fact all field-bus, control systems and
non-PC networks have their own standards....

So your new "standard" will be ignored by the embedded and controll
systems world to start with which are the majority of the C users these
days. On the desk top the majority have moved to C++, C#, Java etc
apart from the mob that never left COBOL and Fotran :-)

but not all systems
use the same filesystem (and indeed there is much more diversity
there),
Correct.
and yet fopen for files is standardized.
No it's not.... it depends on they system you are using. Many systems
have their own methods.
My first
statement is just as portable as fopen("/etc/hosts", "r").
but not much use. Why do you thing that in many systems printf is the
first to be banned. It is large and generic.
>which already have their special small library.

Complete bollox.

No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.


Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.

Refuting the credibility of the C standard on clc is not a very good
idea. ;-)


Why? Other members of the ISO C panel have also said much the same. And
if those of use who are on the ISO C panel say it who are you to say
otherwise? c.l.c is not the authority on ISO C

You seem to have a very limited knowledge of things.

That is true for everyone, no? ;-)


No. Some are far more limited than others.

The truthhood of a statement is binary; either a person is very
limited or they are not.


When you are young life is black and white. With experience you find
that life has only one absolute. -273.15 :-) Everything else is relative
and shades of gray. There are no absolutes.

Re knowledge. on exams whilst there is a pass fail you also find that
are a ranges or grades of both pass and fail so knowledge is graduated
not a binary thing.

Broadly some have a good knowledge of others limited and some very
limited. There are very few binary answers.
While your second statement is true,
the first ("No.") is not logically connected to it.


:-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 24 '06 #41

P: n/a
On 2006-05-24, Chris Hills <ch***@phaedsys.org> wrote:
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-23, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne74ec4.2ug.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
> In article <slrne73pph.jdj.ap*******@localhost.localdomain> , Andrew
> Poelstra <ap*******@localhost.localdomain> writes
>>On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
>>> The difference is that a curses library is something that programmers use.
>>> There is a case for including it in the standard library, though in factthe
>>> ANSI library has no such functions.
>>
>>Not a lot of systems have a screen. I've programmed routers with which I
>>communicated with entirely by FTPing log files around.
>
> This is incorrect. In fact this is one place where you probably might
> need curses.
>
curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.

wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?


Yes. However that screen or terminal my not be connected to the system
all the time.

I have set up things like routes using a terminal connected to the
engineers rs232 port.


For a more mundane example, the terminal may be another system which is
occasionally connected to the system on which curses is running via an
IP-based protocol such as Telnet, SECSH, or RLOGIN.
When I worked on comms equipment there was always
a serial port for local initialisation etc. Usually a VT100 to VT52
terminal emulation was used. Curses would have been used for that.

Not everything has a web server built into it. Particularly as they are
not universal. A Vt100 or VT52 only needs a 40 col 25 line mono screen.


I thought there were 80 columns, or in the case of a VT100, a choice of
80 or 132.
Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.


Toys, microwave ovens, fridges, dish washers, washing machines, bombs,
batteries.... the list is endless.

Very many embedded systems do not need to communicate outside their own
system. Many systems after they are switched on are automatic.


Microwave ovens often have a button pad and some seven-segment LCDs.

A bomb does communicate with the outside world. It makes quite a loud
report for anyone who's listening of its status when its sensors reach
whatever state they were monitoring for, or when its internal timer
elapses.

What kind of stuff is in a battery that makes it an embedded system? I'm
sure anything that would qualify would also be communicating with the
charger and/or device.
May 24 '06 #42

P: n/a
In article <sl***********************@random.yi.org>, Jordan Abel
<ra*******@gmail.com> writes
On 2006-05-24, Chris Hills <ch***@phaedsys.org> wrote:
>curses is a screen display, correct? So, unless I'm telnetting or
>SSHing onto a system without a screen, curses is useless.

wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?
Yes. However that screen or terminal my not be connected to the system
all the time.

I have set up things like routes using a terminal connected to the
engineers rs232 port.


For a more mundane example, the terminal may be another system which is
occasionally connected to the system on which curses is running via an
IP-based protocol such as Telnet, SECSH, or RLOGIN.


However many items have an rs232 port on them for initial set up on
first power-up etc. Also for doing some things that are not permitted
remotely.

When I worked on comms equipment there was always
a serial port for local initialisation etc. Usually a VT100 to VT52
terminal emulation was used. Curses would have been used for that.

Not everything has a web server built into it. Particularly as they are
not universal. A Vt100 or VT52 only needs a 40 col 25 line mono screen.

I thought there were 80 columns, or in the case of a VT100, a choice of
80 or 132.


yes... 80 cols as per a punched card.
Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.
Toys, microwave ovens, fridges, dish washers, washing machines, bombs,
batteries.... the list is endless.

Very many embedded systems do not need to communicate outside their own
system. Many systems after they are switched on are automatic.


Microwave ovens often have a button pad and some seven-segment LCDs.


but NOT a network.
A bomb does communicate with the outside world. It makes quite a loud
report for anyone who's listening of its status when its sensors reach
whatever state they were monitoring for, or when its internal timer
elapses.
:-)

What kind of stuff is in a battery that makes it an embedded system? I'm
sure anything that would qualify would also be communicating with the
charger and/or device.


Some batteries have MCU in them to control them I am reliably informed
by three of my customers..... These are not the sort of batteries you
buy in Tescos or Kwik Fit :-)
The battery in my PowerBook has a series of LED's to show how charged it
is. I assume that for a lot of these special batteries the charging
circuit is in the battery unit itself.

This idea of a standard networking library is about as much use as the
standard graphics library some one suggested a few months back. These
"new" standard libraries are usually suggested by people with little
experience of the industry. In both cases there are many specialised
systems already in use and performing well. The horse has long gone so
there is no point in bolting the stable door.

The only people whop could do such a library are MS as they have such a
large part of the industry using their compilers. They have done this
with the safe, safer, secure, bounded C library as a TR which will never
make it into the main standard or be used by anyone not on an MS
platform. A network library would go the same way.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 24 '06 #43

P: n/a
Andrew Poelstra <ap*******@localhost.localdomain> wrote:
On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.


Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around. Curses would just
be an unneccessary pain for compiler writers.

The only addition to the library that I think is feasable would be some
decent networking functions; all systems have networks, with the exception
of embedded systems,


This, too, is not even true. I have used several systems over the last
couple of years which did not have networks. More if you count those
whose only network is a dial-up line (my home machine, for example), and
even more if you count those whose network is not TCP/IP and hard to
mung into the usual POSIX requirements.

Richard
May 24 '06 #44

P: n/a
On 2006-05-24, Chris Hills <ch***@phaedsys.org> wrote:
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-23, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne74ec4.2ug.ap*******@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-22, Chris Hills <ch***@phaedsys.org> wrote:
> In article <slrne73pph.jdj.ap*******@localhost.localdomain> , Andrew
> Poelstra <ap*******@localhost.localdomain> writes
>>On 2006-05-21, Malcolm <re*******@btinternet.com> wrote:
>>> The difference is that a curses library is something that programmers use.
>>> There is a case for including it in the standard library, though in factthe
>>> ANSI library has no such functions.
>>
>>Not a lot of systems have a screen. I've programmed routers with which I
>>communicated with entirely by FTPing log files around.
>
> This is incorrect. In fact this is one place where you probably might
> need curses.
>
curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.

wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?


Yes. However that screen or terminal my not be connected to the system
all the time.

I have set up things like routes using a terminal connected to the
engineers rs232 port. When I worked on comms equipment there was always
a serial port for local initialisation etc. Usually a VT100 to VT52
terminal emulation was used. Curses would have been used for that.

I suppose. But wouldn't a basic command prompt be easier to maintain?
Not everything has a web server built into it. Particularly as they are
not universal. A Vt100 or VT52 only needs a 40 col 25 line mono screen.
Neither of us mentioned anything about a web server. I mentioned that I
communicated with a router via ftp and telnet (sans curses), and it works
fine.
Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.


Toys, microwave ovens, fridges, dish washers, washing machines, bombs,
batteries.... the list is endless.

If a toy outputs nothing, it could have been made just as well without
electronics. Microwave ovens always have inputs to control heat, as do
washing machines and fridges for similar reasons. A battery is not a
system.

Bombs, well, hmm.

Very many embedded systems do not need to communicate outside their own
system. Many systems after they are switched on are automatic.
Agreed.
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.

Yes.... some sort of communication but not always a network.

What sort of network library did you have in mind?

Something similar to stdio.h, I suppose. Or an extension of stdio.

FILE *sh = fopen("192.168.0.100", "n");
fprintf(sh, "Hello, other machine!\n");


That already exists

Where?
However most safety critical or high integrity systems are not likely to
use stdio anyway.

Besides fprintf is of little use for fieldbus, CAN Lin etc.
You might suggest that not all networks use IP,
Not by a VERY long way. Automotive systems use CAN and LIN The busses
for all these systems and in fact all field-bus, control systems and
non-PC networks have their own standards....

So your new "standard" will be ignored by the embedded and controll
systems world to start with which are the majority of the C users these
days. On the desk top the majority have moved to C++, C#, Java etc
apart from the mob that never left COBOL and Fotran :-)

Not a "new" standard. Please don't make me into a Jacob Navia here. ;-)
I merely suggested a new feature because the guys at comp.std.c scare me
and the negative reception here suggests that I shouldn't pursue this.
but not all systems
use the same filesystem (and indeed there is much more diversity
there),
Correct.
and yet fopen for files is standardized.


No it's not.... it depends on they system you are using. Many systems
have their own methods.

Yes, it is. It is extensible, but standardized.
My first
statement is just as portable as fopen("/etc/hosts", "r").


but not much use. Why do you thing that in many systems printf is the
first to be banned. It is large and generic.

I don't think that. However, if you are very concerned about space,
eliminating headers such as stdio or stdlib which contain large
functions (if you know the entire system, it's easy to replace
malloc) is a good idea.
>>which already have their special small library.
>
> Complete bollox.
>
No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.

Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.

Refuting the credibility of the C standard on clc is not a very good
idea. ;-)


Why? Other members of the ISO C panel have also said much the same. And
if those of use who are on the ISO C panel say it who are you to say
otherwise? c.l.c is not the authority on ISO C

By "current C standard" did you mean C99? If so, I apologise.
> You seem to have a very limited knowledge of things.
>
That is true for everyone, no? ;-)

No. Some are far more limited than others.

The truthhood of a statement is binary; either a person is very
limited or they are not.


When you are young life is black and white. With experience you find
that life has only one absolute. -273.15 :-) Everything else is relative
and shades of gray. There are no absolutes.

Not even. That's why I don't like physics. Pure mathematics is so much
cleaner. :-)

Now, this has become horribly OT, and you've given me some good reasons
for why my idea will not work. Therefore, as far as I'm concerned, this
thread is over. (Or this subset of this thread; I don't remember what
the OP said).

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
It's just like stealing teeth from a baby.
May 24 '06 #45

P: n/a
On 2006-05-24, Andrew Poelstra <ap*******@localhost.localdomain> wrote:
Bombs, well, hmm.


Does a report count as output?
May 24 '06 #46

P: n/a
In article <sl**********************@localhost.localdomain> , Andrew
Poelstra <ap*******@localhost.localdomain> writes
On 2006-05-24, Chris Hills <ch***@phaedsys.org> wrote:
In article <slrne771e3.a42.ap*******@localhost.localdomain> , Andrew
>curses is a screen display, correct? So, unless I'm telnetting or
>SSHing onto a system without a screen, curses is useless.

wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?
Yes. However that screen or terminal my not be connected to the system
all the time.

I have set up things like routes using a terminal connected to the
engineers rs232 port. When I worked on comms equipment there was always
a serial port for local initialisation etc. Usually a VT100 to VT52
terminal emulation was used. Curses would have been used for that.

I suppose. But wouldn't a basic command prompt be easier to maintain?


You mean a VT100 terminal? A "command prompt" is a terminal window...
If you have that then curses will run on it.
Not everything has a web server built into it. Particularly as they are
not universal. A Vt100 or VT52 only needs a 40 col 25 line mono screen.

Neither of us mentioned anything about a web server. I mentioned that I
communicated with a router via ftp and telnet (sans curses), and it works
fine.


Many systems these days have a web interface rather than a terminal.
Though over a serial line to "something" a VT100 or VT52 terminal sill
can't be beaten.
Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.


Toys, microwave ovens, fridges, dish washers, washing machines, bombs,
batteries.... the list is endless.

If a toy outputs nothing, it could have been made just as well without
electronics. Microwave ovens always have inputs to control heat, as do
washing machines and fridges for similar reasons. A battery is not a
system.

Bombs, well, hmm.


Of course. Many bombs have electronics in them. In fact it is hard to
find any air launched ordinance that does not these days. Start with a
cruise missile and work down...... naval bombs and mines also have lots
of electronics.

Not by a VERY long way. Automotive systems use CAN and LIN The busses
for all these systems and in fact all field-bus, control systems and
non-PC networks have their own standards....

So your new "standard" will be ignored by the embedded and controll
systems world to start with which are the majority of the C users these
days. On the desk top the majority have moved to C++, C#, Java etc
apart from the mob that never left COBOL and Fotran :-)

Not a "new" standard. Please don't make me into a Jacob Navia here. ;-)
I merely suggested a new feature because the guys at comp.std.c scare me


Why? We are usually friendly.
and the negative reception here suggests that I shouldn't pursue this.
Try it on comp.std.c all they can do is shout at you but you might learn
why not.
My first
statement is just as portable as fopen("/etc/hosts", "r").


but not much use. Why do you thing that in many systems printf is the
first to be banned. It is large and generic.

I don't think that. However, if you are very concerned about space,
eliminating headers such as stdio or stdlib which contain large
functions (if you know the entire system, it's easy to replace
malloc) is a good idea.


Don't use malloc either for obvious reasons.
>>>which already have their special small library.
>>
>> Complete bollox.
>>
>No, the C Standard specifies that small systems with limited space may
>use a small subset of the standard library.

Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.

Refuting the credibility of the C standard on clc is not a very good
idea. ;-)


Why? Other members of the ISO C panel have also said much the same. And
if those of use who are on the ISO C panel say it who are you to say
otherwise? c.l.c is not the authority on ISO C

By "current C standard" did you mean C99? If so, I apologise.


Of course I mean ISO 9899:1999 that is the standard. All the others are
Obsolete officially though in practice the de-facto standard is C95/6

When you are young life is black and white. With experience you find
that life has only one absolute. -273.15 :-) Everything else is relative
and shades of gray. There are no absolutes.

Not even. That's why I don't like physics. Pure mathematics is so much
cleaner. :-)


But Physics is reality. Maths does not exist in reality which is why you
need applied maths.
Now, this has become horribly OT, and you've given me some good reasons
for why my idea will not work. Therefore, as far as I'm concerned, this
thread is over. (Or this subset of this thread; I don't remember what
the OP said).


Search on google for fieldbus, profi-bus, CAN etc to see what some of
the other common busses are.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 24 '06 #47

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Chris Hills <ch***@phaedsys.org> writes:
In article <ya******************************@bt.com>, Malcolm
<re*******@btinternet.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote
In article Skarmander <in*****@dontmailme.com> writes
>Chris Hills wrote:

> There are no questions about the C language here. If there are
>questions about what's portable and what's not, that would be another
>matter.

Wrong. but you are entitled to your opinion.

We could allow it,


You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.


We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.


I have two responses to that.

Logical rational:
"An effective enforcement mechanism" an easy to obtain goal. This newsgroup
has enough messages to support four newsgroups including one entirely
dedicated to exactly what you want (Hurray!). So what are you waiting for?

Angry, but truthful:
Why do you keep whining about this? It only shows that you're a complete
failure at obtaining what you claim to want: power and control over a
newsgroup. That is, unless you really have some other agenda. Perhaps,
you're just masochistic and truly enjoy drama and the pain you feel from
repeated confrontations over this issue. Or perhaps, you're sadistic and
truly enjoy the pain you attempt to inflict on others regarding this. You
have no control here. If you want it, go somewhere else.
Rod Pemberton
May 27 '06 #48

P: n/a
On 24 May 2006 11:10:36 GMT, Jordan Abel <ra*******@gmail.com> wrote:
On 2006-05-24, Chris Hills <ch***@phaedsys.org> wrote:

<snip>
When I worked on comms equipment there was always
a serial port for local initialisation etc. Usually a VT100 to VT52
terminal emulation was used. Curses would have been used for that.

Not everything has a web server built into it. Particularly as they are
not universal. A Vt100 or VT52 only needs a 40 col 25 line mono screen.


I thought there were 80 columns, or in the case of a VT100, a choice of
80 or 132.

VT52 was 24 x 80, but IIRC had double-wide characters available.

VT100 was 24 x (80 or 132) but had double-wide and double-size (2wide
2high) (top and bottom) characters available. IIRC VT220 the same.

Some other (folks') terminals had at least part of a 25th line usable,
though not as part of the normal display, but AFAICR no DECs.

- David.Thompson1 at worldnet.att.net
Jun 8 '06 #49

This discussion thread is closed

Replies have been disabled for this discussion.