D
David Mathog
One thing that keeps coming up in this forum is that
standard C lacks many functions which are required in
a workstation or server but not possible in an embedded controller.
This results in a plethora of "don't ask here,
ask in comp.x.y instead", for queries on functions that from the
documentation available to the programmer appear to be part
of the C language. I think largely because of this "least common
denominator" C language standard we have POSIX, XPG4, etc, which
add these useful and in many instances necessary pieces. And this
multiplicity of standards can be a real pain. I would really rather
write code that complies with _ONE_ language standard than write code
that has to comply with _MANY_ interrelated language standards.
Just for the sake of argument, would it be so terribly wrong for the
ISO/ANSI C standard to define capabilities relevant for computers
other than dishwasher controllers? For instance, if the language
required the compiler define for the target platform these constants as
0 (not present) or 1 or higher (present, with number indicating various
future revision levels):
ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKING
ISOC_CAPABILITY_INTERPROCESS
etc.
The code could test for these, and if present, utilize the relevant
supported functions. For instance, if MULTIUSER was defined then
some form of "getusername" would be supported.
Note that this is more or less what compilers do now, except that the
constants refer to POSIX, XPG4, etc, and it is not so much including by
capability, but including by language extension, with the latter rarely
clearly associated with the former. This results in insanely messy
compiler provided include files in which it is often painful to trace
through the logic to determine which combination of posix,xpg4,ansi etc
must be set at compile time to obtain the desired functions.
For those purists who work on embedded controllers the potential
availability of these extra functions should pose no problem whatsoever.
They are perfectly free NOT to use them. The cross compiler would
negate these constants so that any code that accidentally tried to
use a function not supported on the target platform would be flagged at
compile time.
Regards,
David Mathog
standard C lacks many functions which are required in
a workstation or server but not possible in an embedded controller.
This results in a plethora of "don't ask here,
ask in comp.x.y instead", for queries on functions that from the
documentation available to the programmer appear to be part
of the C language. I think largely because of this "least common
denominator" C language standard we have POSIX, XPG4, etc, which
add these useful and in many instances necessary pieces. And this
multiplicity of standards can be a real pain. I would really rather
write code that complies with _ONE_ language standard than write code
that has to comply with _MANY_ interrelated language standards.
Just for the sake of argument, would it be so terribly wrong for the
ISO/ANSI C standard to define capabilities relevant for computers
other than dishwasher controllers? For instance, if the language
required the compiler define for the target platform these constants as
0 (not present) or 1 or higher (present, with number indicating various
future revision levels):
ISOC_CAPABILITY_MULTIUSER
ISOC_CAPABILITY_NETWORK_IPV4
ISOC_CAPABILITY_NETWORK_IPV6
ISOC_CAPABILITY_FILELOCKING
ISOC_CAPABILITY_INTERPROCESS
etc.
The code could test for these, and if present, utilize the relevant
supported functions. For instance, if MULTIUSER was defined then
some form of "getusername" would be supported.
Note that this is more or less what compilers do now, except that the
constants refer to POSIX, XPG4, etc, and it is not so much including by
capability, but including by language extension, with the latter rarely
clearly associated with the former. This results in insanely messy
compiler provided include files in which it is often painful to trace
through the logic to determine which combination of posix,xpg4,ansi etc
must be set at compile time to obtain the desired functions.
For those purists who work on embedded controllers the potential
availability of these extra functions should pose no problem whatsoever.
They are perfectly free NOT to use them. The cross compiler would
negate these constants so that any code that accidentally tried to
use a function not supported on the target platform would be flagged at
compile time.
Regards,
David Mathog