Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > some well known stupidness in c99

Reply
Thread Tools

some well known stupidness in c99

 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      11-21-2012
BartC <(E-Mail Removed)> wrote:

(snip)

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


(Keith wrote)
>> But if you add a language feature that creates such a dependency,
>> then you break C's concept of separate compilation.


> 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
 
Reply With Quote
 
 
 
 
fir
Guest
Posts: n/a
 
      11-21-2012
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)
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      11-21-2012
"glen herrmannsfeldt" <(E-Mail Removed)> wrote in message
news:k8h6g4$mu4$(E-Mail Removed)...
> BartC <(E-Mail Removed)> wrote:


> (Keith wrote)
>>> But if you add a language feature that creates such a dependency,
>>> then you break C's concept of separate compilation.

>
>> 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.


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!

--
Bartc

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-21-2012
James Kuyper <(E-Mail Removed)> writes:

> On 11/20/2012 05:32 PM, Ben Bacarisse wrote:
>> Ian Collins <(E-Mail Removed)> writes:

> ...
>>> 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.

>
> Example, please?


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

<snip>
--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-21-2012
On 11/20/2012 08:52 PM, Ben Bacarisse wrote:
> James Kuyper <(E-Mail Removed)> writes:
>
>> On 11/20/2012 05:32 PM, Ben Bacarisse wrote:
>>> Ian Collins <(E-Mail Removed)> writes:

>> ...
>>>> 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.

>>
>> Example, please?

>
> 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.
--
James Kuyper
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-21-2012
glen herrmannsfeldt <(E-Mail Removed)> writes:
[...]
> 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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-21-2012
James Kuyper <(E-Mail Removed)> writes:

> On 11/20/2012 08:52 PM, Ben Bacarisse wrote:
>> James Kuyper <(E-Mail Removed)> writes:
>>
>>> On 11/20/2012 05:32 PM, Ben Bacarisse wrote:
>>>> Ian Collins <(E-Mail Removed)> writes:
>>> ...
>>>>> 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.
>>>
>>> Example, please?

>>
>> 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.


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.

--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-21-2012
On 11/20/2012 11:40 PM, Ben Bacarisse wrote:
> James Kuyper <(E-Mail Removed)> writes:

....
>> 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.


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.
--
James Kuyper
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-21-2012
W dniu środa, 21 listopada 2012 18:10:36 UTC+1 użytkownik KennethBrody napisał:
> On 11/20/2012 7:00 PM, fir wrote:
>
> > W dniu środa, 21 listopada 2012 00:26:16 UTC+1 użytkownik Greg Martin napisał:

>
> >> On 12-11-20 03:10 PM, fir wrote:

>
> >>
> >>
> >>> whats is wrong with which concept (c improvement) exactly?
> >>
> >>
> >> 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)

>
>
>
> 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?
>
>
>
> > 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

>
>
>
> 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?
>
>
>
> > (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)

>
>
>
> 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


 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      11-21-2012
Kenneth Brody <(E-Mail Removed)> wrote:

(snip, I wrote)
>> The tradition of switch/case is that they be resolved at compile
>> time, but is that required?


> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Is this phase-accumulator trick well-known??? Mike Treseler VHDL 0 02-08-2009 07:17 PM
List mutation method gotcha - How well known? Hendrik van Rooyen Python 20 03-16-2008 09:55 AM
Difference between "library parts" of C99 and "language parts" of C99 albert.neu@gmail.com C Programming 3 03-31-2007 08:14 PM
C99 struct initialization (C99/gcc) jilerner@yahoo.com C Programming 3 02-20-2006 04:41 AM
well-known Internet sites which use Java based web servers Mladen Adamovic Java 3 10-24-2005 09:48 PM



Advertisments