some well known stupidness in c99

[Ben Bacarisse]

On 11/21/12 10:14, Keith Thompson wrote:

Or just adopt the C++ rules and avoid breaking any valid existing
code!

There are valid C program that would break under C++'s rules. Maybe
these are not mainstream uses of const, but one of the troubles with
such changes is there is no reliable mechanism for the language
committee to find out what the impact of a change would be.

 

[glen herrmannsfeldt]

On 11/20/2012 04:14 PM, glen herrmannsfeldt wrote:

Yes, and the Fortran specifies what it does with that string: it
displays it, rather than attempting to pass it as an exit status.

Well, that is a popular implementation, but the standard is pretty
loose on the requirement. It does sound like an implementation on
a system that allowed for string exit status would return that value.

Also, implementations that don't allow for integer exit status
should print that, but again it isn't required.

VM/CMS prints any non-zero exit status from a program, but doesn't
do anything special for zero.

I've repeatedly asked fir to specify what he wanted done with the string
after it was returned, with no response. If he had said "print it to
stderr", that would be perfectly reasonable; but if so, he still needs
to specify what exit status should be returned, since he's hijacked what
used to be the only way of specifying that status.

It seems that Fortran exit codes for PAUSE and STOP go back to Fortran I
where the octal code is displayed on the address field of the storage
register (that is, lights on the front panel).

Now that most don't have a panel with lights and switches, it has
to go somewhere else.

-- glen

 

[fir]

W dniu wtorek, 20 listopada 2012 23:07:04 UTC+1 użytkownik Ian Collinsnapisał:

Well what else to you expect form a troll? Have a look at his previous
threads here.

I consider all people using their fav word 'troll' should go to some low level school
times yet again
do not involve me with that, its to much stupid. shame on you trol-trol-troll slightly tragic ppl, do not involve me with that (I am
saying that though I know it iis
endless, but do not matter)

 

[Greg Martin]

W dniu wtorek, 20 listopada 2012 23:07:04 UTC+1 użytkownik Ian Collins napisał:

I consider all people using their fav word 'troll' should go to some low level school
times yet again
do not involve me with that, its to much stupid. shame on you trol-trol-troll slightly tragic ppl, do not involve me with that (I am
saying that though I know it iis
endless, but do not matter)

If it seems endless perhaps you should reconsider some of your ideas.
They seem far fetched and poorly enough thought out to appear to be the
efforts of a troll. Inductive reasoning - if it walks like a duck and
quacks like a duck ... maybe you could change your tune?

 

[fir]

W dniu wtorek, 20 listopada 2012 23:01:23 UTC+1 użytkownik James Kuyper napisał:

On 11/20/2012 04:57 PM, Keith Thompson wrote:

...




I was just trying to get fir to be more specific about what he was
proposing. I agree with you that if this is what he was proposing
(something he's never bothered clarifying, despite repeated requests),
it's not really necessary - in fact, I've already pointed out to him the
ease with which he could define such a function himself.

Sorry for that, it is not intended, just
there is many texts here and i do not have
time to carefully try to answer to everything
this time.

(Also this cutting and editing stuff is
bothersome here in google groups (should find
better working newsgate)

If you want to get answer to something please write an exact question and Iwill answer to
that (couse I am little lost in not to much
exact questions maybe (If not I can get back
to some topics later, I am much interested in
c topics and can discuss it for years)

 

[fir]

W dniu wtorek, 20 listopada 2012 23:56:19 UTC+1 użytkownik Greg Martinnapisał:

If it seems endless perhaps you should reconsider some of your ideas.
They seem far fetched and poorly enough thought out to appear to be the
efforts of a troll. Inductive reasoning - if it walks like a duck and
quacks like a duck ... maybe you could change your tune?

whats is wrong with which concept (c improvement) exactly?

 

[James Kuyper]

There are valid C program that would break under C++'s rules.

Example, please? I believe that the change we're talking about would
simply involve adding "an lvalue of integer type that refers to a
non-volatile const object initialized with a constant expression" to
6.6p6, and to add "an lvalue that refers to a non-volatile const object
initialized with a constant expression" to 6.6p7. There's probably a
better way to organize it so that there's no so much duplicated
description between the two additions.

As far as I can see, the sole effect of such a change would be to give
standard-defined behavior to code constructs that were previously
constraint violations.

 

[Greg Martin]

W dniu wtorek, 20 listopada 2012 23:56:19 UTC+1 użytkownik Greg Martin napisał:

whats is wrong with which concept (c improvement) exactly?

Read the responses already given to your suggestions.

 

[fir]

W dniu wtorek, 20 listopada 2012 22:14:22 UTC+1 użytkownik Keith Thompson napisał:

1. Change the "const" keyword to "readonly".

2. Add a "constant" keyword, allowing you to define things like:

constant int x = 42;

constant int x = 50;

seem quite ok for me, As to readonly it do
not look such good for me (maybe something like 'immutable' attribute to set on and off for variables would be better - though I
never yet considered usability of this
immutability personally

 

[fir]

W dniu środa, 21 listopada 2012 00:26:16 UTC+1 użytkownik Greg Martin napisał:

Read the responses already given to your suggestions.

If you would find there any statements that would show me that my sugesstions (ideas/
concepts/propositions/improvements) are
logically/conceptually wrong I would very
much like to see it and talk about it

I can see no one.

For example as to

char* main(char* arg)
{
return "hallo world";
}

(or close to that couse there can be unresolved details here)

some people just said that no oses are
ready for that - but it is not important
here becousa I am talking about 'technical goodness' here - what would be good (not
about what will work on some oses) And it
would be good it would have many fine uses

(it is also not a matter of 'exit codes'
or 'exit status' as someona called that, it
is a mattaer of 'return value' from program
- this value can be used in many ways pottentialy it could be a whole 'robinson
crusoe' string or chunk of bytes, could
go thru ram buffer (not file buffer)
back to the system work fast and could
be fun, it is good idea (i was happy to get
on it some months back)

 

[glen herrmannsfeldt]

(snip)

Finally someone seems to get what I'm talking about...

(Keith wrote)

But it needn't be an actual dependency on the source code of another module.
Let's take the example files used before: victim.c and file1.c (we don't
need file2.c).

victim.c makes use of resources in file1.c, and currently this is done by
creating a header file1.h. The compiler of victim.c doesn't need to see
file1.c, only file1.h.

This sounds, as I previously mentioned, a lot like the module (.MOD)
facility in Fortran since, I believe, Fortran 90. The compiler writes
out a (usually with extension .MOD) file, and compilation of programs
that USE the module read them in.

My suggestion, if the concept of an 'import' statement was supported by the
language, could work the same way: the import statement could simply make
use of an 'exports' file called file1.h. The difference is that file1.h
might be generated automatically, by a separate process that does need
access to file1.c, but need have nothing to do with the compiler of
victim.c.

The .MOD files are not portable between compilers, maybe not even with
different versions of the same compiler.

C header (.h) files are often portable, though sometimes contain
system dependencies.

In fact, file1.c could be on the other side of the world (locked in a vault
below ground); all that's needed by the compiler of victim.c, is the public
exports file (eg. file1.h), which has been generated at some time in the
past.
(snip)

As I've explained above, that model can stay largely the same. Actually we
don't even need a new 'import' statement (although it's a lot tidier); just
'include' will suffice. It boils down to whether the exported names in
file1.c (functions which are not static, file-scope variables which are not
static, and I would extend it to explicitly exported typedefs, enums and so
on) make their way into file1.h with the help of the language or not.

-- glen

 

[fir]

W dniu środa, 21 listopada 2012 00:29:50 UTC+1 użytkownik fir napisał:

never yet considered usability of this
immutability personally

as to this immutability (readonlyness) i can
notice for example that this immutablility
may be attribute of not a whole variable but
the context of its usage,

for example int x can be writeable from one
function and readonly in the context of other
so maybe it could be 'set on' and 'set off'
not for some variable but in the context
of its usage


as to constant int x = 50 there is also a
difference of considering it as a ram localized 'ever and everywhere immutable' and a not ram localized value which will be resolvedas a bunch of immediates - and the second seem better in some way (sometimes)

 

[BartC]

BartC <[email protected]> wrote:

(Keith wrote)



This sounds, as I previously mentioned, a lot like the module (.MOD)
facility in Fortran since, I believe, Fortran 90. The compiler writes
out a (usually with extension .MOD) file, and compilation of programs
that USE the module read them in.

Yes, I think the concept is quite well known, it's just in this newsgroup
that any new-fangled ideas seem to be viewed with suspicion!

In this case it seems a public interface is exported, which is a better way
of putting it. If using such a feature means compilation is not technically
separate, then.. so what?

I use the idea in my own projects, and I can export functions, types,
variables, named constants (that is, proper ones!), and macros.

If I want to share one of these, I just stick 'global' in front of the
definition; then it will be added to the exports file when it's compiled,
and is available to any other module that imports this one. It's a joy not
to mess around with separate include or header files, and have to
declare/define everything twice and make sure the two correspond.

Maybe those who use advanced IDEs get help with this stuff, and don't need
support from the language, but some of us don't and do!

 

[Ben Bacarisse]

Example, please?

In C++, objects declared const and not explicitly declared extern have
internal linkage.

<snip>

 

[James Kuyper]

In C++, objects declared const and not explicitly declared extern have
internal linkage.

I believe that the intent of the suggestion was only to adopt the C++
rules that allow lvalues in constant expressions. Otherwise, the comment
about "and avoid breaking any valid existing code" wouldn't make much
sense, for precisely the reason you give.

 

[Keith Thompson]

Many years ago, I found that some expressions wouldn't work in
case statements, such as ones of the form: "abcd"[1].
So, even what seems to be a compile time constant might not
be in C terms.

Right, the C standard has a rigorous definition of "constant
expression". It's designed so that all "constant expression"s can be
evaluated at compile time, but not necessarily so that all expression
that can be evaluated at compile time are constant expressions.

N1370 6.6p6 defines the operands that may appear in an integer constant
expression:

An *integer constant expression* shall have integer type
and shall only have operands that are integer constants,
enumeration constants, character constants, sizeof expressions
whose results are integer constants, _Alignof expressions,
and floating constants that are the immediate operands of
casts. Cast operators in an integer constant expression shall
only convert arithmetic types to integer types, except as part
of an operand to the sizeof or _Alignof operator.

 

[Ben Bacarisse]

I believe that the intent of the suggestion was only to adopt the C++
rules that allow lvalues in constant expressions. Otherwise, the comment
about "and avoid breaking any valid existing code" wouldn't make much
sense, for precisely the reason you give.

Ah, another language issue. I read it as "adopt all C++'s const rules
and, as a result, avoid breaking any existing code" (which won't work)
whereas you read is as "adopt some of C++'s const rules and, in so
doing, avoid breaking existing code" which is, as you say, possible.

 

[James Kuyper]

Ah, another language issue. I read it as "adopt all C++'s const rules
and, as a result, avoid breaking any existing code" (which won't work)
whereas you read is as "adopt some of C++'s const rules and, in so
doing, avoid breaking existing code" which is, as you say, possible.

More accurately, I had a very good idea of precisely which C++ rules he
was talking about, from context. It's the "constant expression" rule
that is relevant, not the const rules. Also, a very large portion of the
texts of that rule in the C++ standard refers to various features of C++
that aren't relevant in a C context. Every aspect of those rules that's
relevant to the issues raised in this thread is included in my previous
message; nothing else is needed or, IMO, desirable.

Note: I had to split that one rule into two separate rules when adapting
it to C. That's because the C++ standard defines an integral constant
expression (ICE) as a constant expression of integral or enumeration
type, while C defines an integer constant expression (ICE) without
reference to the definition of constant expressions. However, the two
definitions match very closely. The only example I could come up with of
a constant expression of integer type that in not an ICE was
(int)(float)3, which is disqualified because of the (float) cast. If
I'm right, it would simplify things to define an ICE as a constant
expression of integer type, similar to the way C++ defines them. I'm no
big fan of expressions like "(int)(float)3", but allowing them to be
constant expressions while excluding them from being ICEs involves 5
lines of complicated redundant text to the standard. I wonder how many
compilers get that issue right?

One aspect of the C++ constant expression rules bothers me, and I
"corrected" it when restating it for a C context. Given

const int i = 30;
const double d = 30.0;

If I'm reading the C++ rules correctly, then i and 30 are both integer
constant expressions. The expressions i, 30, and 30.0 are all constant
expressions, but d is not. The relevant part of 5.19 allows
lvalue-to-rvalue conversions in constant expressions only when they have
integral and enumeration type (ignoring some C++-specific exceptions).
The C standard doesn't use the phrase "lvalue-to-rvalue conversion",
though the thing described by that phrase does occur in C. Also, it uses
"integer" instead of "integral", and "enumerated type" instead of
"enumeration type", and in C, enumerated types qualify as integer types,
so if it were desired to duplicate that restriction in C, it would be
simplified to "integer type" - but I don't see the need for such a
restriction.

 

[fir]

W dniu środa, 21 listopada 2012 18:10:36 UTC+1 użytkownik KennethBrody napisał:

Well, as has been pointed out, virtually no O/S you are likely to run into
will allow such a value to be returned to it. So, as has been repeatedly
asked of you, what should be done on an O/S that only allows an 8-bit
integer value as the exit code?






Whether or not such a change would be an "improvement" would be a separate
discussion. To add a feature that nearly 0% of implementations could use,
is not likely to be very high on *anyone* on the Standards committee.



How is such an "improvement" good for the language?






I'm not sure I follow. But, given that a string *cannot* be a program's
"exit value" on virtually *any* platform you are likely to come across, how
do you envision this being implemented?

As to details of possible implementations:
As far as i know executable formats (like PE)
has some fields in it that can be used (to denote, that this is a prog, that can return some data, not just int)

How it can be returned? I think by some
ram memory. Possibly returning program could
call some allocMemory, then fiil it with his results, than exit, and OS should use this ram as its result.

(Alloc becouse it would be good to return any (not just hard limited) amount of data with that) (of course I would like to get it efficient though)

(How argv[] is passed to main() ? I do not know
exactly - but must be close to that - some ram
buffer )

Those above are tehnical details - Sure os must (I mean 'will must' do notknow how it is in english) be ready to that, but those are side questions - the meritum is that such way is more general and
better,

Some ppl (os, compiler, program writerss) must
to write that and then... they will get that - and it would be good

 

[glen herrmannsfeldt]

(snip, I wrote)

If the value cannot be determined at compile time, the compiler cannot know
if there will be a conflict at link time.
(snip)

I think it boils down to the fact that every "case" must be distinct, and
there is no way to know this if the value cannot be determined at compile time.

But why does it have to be resolved an detected at compile time?

Well, new functionality, including labels that aren't resolved at
compile time and that don't have to be distinct should probably come
with a new and differently named statement.

How about select/case that takes the first among the choices, and where
values can be determined at run time?

Maybe a slightly less efficient implementation, but that is the
programmer's choice.

-- glen