standard include files

[Nick Keighley]

"Robert Wessel" <[email protected]> ha scritto nel messaggio

"Kaz Kylheku" <[email protected]> ha scritto nel messaggio
If a translation unit includes no standard headers at all, should it be
defining ptrdiff_t, et cetera?
There is a case to be made for hosted implementations being free to define
all
the standard material even if no header is included at all.
for resolve that problem one has to impose the names of standard .dll
[where are all executable functions as printf malloc and all
standard function]
and rename all functions and variable of that file as
thatStdFile_varibleOrFunctionName as thatStfFile_printf
and nobody can use one file that has name thatStdFile...

Nonsense.  You're assuming the implementation has DLLs, and has the C
library in a DLL, and organized in a particular way.  None of which is
required.

so you say standard C functions executable are not in any file
[that has one name] of sys

they don't have to be in any particualr file. Which contary to what
you said earlier. Insisting that all library names are visible even if
header files aren't included imposes no particular implementation on
the implementor. he certainly doesn't have to use a DLL (some systems
don't ahve DLLs) and if does use a DLL he doesn't have to call it by a
standard name. he could just preload his symbol table with the
reserved library names.

 

[Markus Wichmann]

[Big snip]

And there I was hoping, you'd just misunderstand. But it's worse: You
don't want to understand. Maybe I didn't explain it good enough, but I
should at least have provided some incentive to research the matter. You
didn't do that but stubbornly remained at your position (which is very
close to "all the world is an x86 PC with MS Windows"). Well, scorefile
adjusted.

Ciao,
Markus

 

[Kaz Kylheku]

And there I was hoping, you'd just misunderstand. But it's worse: You
don't want to understand.

And thus squarely belongs here.

 

[BGB]

On 2/26/2012 3:15 PM, Keith Thompson wrote:
17 AM, Robert Wessel wrote:
[...]
zOS (IBM mainframe) C/C++ developers often use PDSs to store header
files - these make names longer than eight characters problematic, at
best. In fact C header files are often stored in a PDS dedicated to
headers, and the header name does not include the ".h".

hmm... I had overlooked / was not aware of this.

but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

I fail to see how your criticism relates in any way to what BGB
actually wrote.


yeah... the issue was not saying that IBM mainframes are slow, but more
the PDS thing, with 8 character name limits. nevermind things like
EBCDIC and similar. along with such things as "Token Ring" and "Twinax"
cabling.

and where COBOL is still alive and well...

nevermind fixed-field form and menu-driven systems (with absurd color
schemes) accessed via terminal emulators, ... all on presumably fairly
modern (PowerPC based) HW... (I had brief exposure to some this once
before...).


IBM Mainframes (the S/360 line, "System z" now), is not at all PPC
based.

PPC (POWER) runs both of IBM's midrange lines, the *nix based System p
(formerly RS/6000, pSeries, etc.), and now the System i (the old S/38,
AS/400 minis). IIRC, IBM is rebranding both of those as "IBM Power
Systems". The System i still has a fair bit of green screen support
(5250's, rather than the 3270s seen on the mainframe systems).

well, yes, but will anyone try to disagree with me that it is all a bit
strange, if considered from the POV of Windows or Linux based PCs or
servers?...

I don't know. An AIX or Linux based pSeries box is certainly no
stranger than a Solaris, HP-UX, or any other *nix box. Sure it has
some unique attributes, but then so does Solaris, HP-UX...

Admittedly something running OS/400 ("IBM i" - hideous name) or zOS
will look pretty strange to someone with a *nix or Windows background.

But my major point was that mainframes aren't PPC/POWER.

ok, I just thought they were, for whatever reason.

IBM sells PPC, and IBM sells mainframes, one could infer them using the
same chips. can't seem to find much information on just what sort of CPU
they run though.

To be sure there's more x86 and ARM development, than say MIPS or PPC,
but just because *you* aren't seeing them, doesn't mean that MIPS and
PPC CPUs aren't in tens of thousands of devices. It's certain that
there are far more ARM CPUs in the world than x86, and it wouldn't
surprise me if there were more MIPS and PPC CPUs (than x86) as well.
And lets not even talk about smaller stuff, like 8051s, PICs, and
AVRs, that ship billions of units.

yes, but the issue is:
how many people develop for them;
vs, how many devices there are.

the thing is with most embedded devices, that maybe only a few
programmers write the software for a given device, and large numbers of
the units are sold to large numbers of people.

so, despite the large number of units, fewer people likely develop for
them in total.


x86 PC's, and more recently, and OS's running on ARM based devices (such
as Android and iOS), have probably a much larger pool of developers,
given that the architecture is much more open.

also, most PC code-bases tend towards being much larger, and hence more
people and more man-hours go into making them.

likewise, although some embedded systems run things like Linux, and game
consoles may use 3D engines like Unreal Engine and similar, both were
originally written for the PC, so their use on embedded systems and
similar doesn't really count.

 

[BGB]

http://en.wikipedia.org/wiki/IBM_z10_(microprocessor)
http://en.wikipedia.org/wiki/IBM_System_z10
http://speleotrove.com/decimal/IBM-z6-mainframe-microprocessor-Webb.pdf

looking:
interesting to note.

I was aware of an ISA being in use since the IBM System/360, but for
whatever reason had also thought it was a VM, rather than the actual ISA.


ok then.