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

 
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/18/2012 08:36 PM, BartC wrote:
> "James Kuyper" <(E-Mail Removed)> wrote in message
> news:k8c14j$t7a$(E-Mail Removed)...
>> On 11/18/2012 07:59 PM, BartC wrote:

....
>> It really doesn't matter how linkage occurs. If compilation of victim
>> requires access to information from the compilation of file1 or file2,
>> depending upon which one is used, then it is not true separate
>> compilation.

>
> In that case C doesn't have true separate compilation either, if it needs
> header files to tell it something about the contents of separate modules.


The header files are compiled separately as part of each translation
unit. It's even possible, and in some contexts useful, to have them
compile differently in different translation units. They're basically
just a technique for getting identical text into different translation
units.

>> It may be a useful concept when discussing a language that
>> works that way, but talking about "compile time constants" in comparison
>> to C, when using a language where "compile time" means something
>> radically different from what it does in C is pretty much meaningless.

>
> I'm sure that 'compile-time' means pretty much the same, ie. a value known
> to the compiler.


The implications are quite different when the things that can be known
at compile time are different. A #defined constant in a shared header
file can be known at compile time in C (and could be different in
different translation units for the same header file, if set up
properly). The value of an object with external linkage that is defined
in some other translation unit cannot be known at compile time in C, and
cannot (with defined behavior at least) be different in different
translation units, no matter what fancy tricks you use. The closest
equivalents in your language works quite differently, and that changes
the implications of "compile time".
--
James Kuyper
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/18/2012 08:38 PM, Ian Collins wrote:
....
> The one that really really bugged me was attempting to debug some code
> that had a excess of #define constants was the inability of the debugger
> to evaluate them.


Some debuggers handle that better. I was rather pleasantly surprised the
first time I accidentally made use of that feature.
--
James Kuyper
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/18/2012 08:38 PM, Ian Collins wrote:
....
> The one that really really bugged me was attempting to debug some code
> that had a excess of #define constants was the inability of the debugger
> to evaluate them.


Some debuggers handle that better. I was rather pleasantly surprised the
first time I accidentally made use of that feature.
--
James Kuyper
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-19-2012
Ian Collins <(E-Mail Removed)> writes:

> On 11/19/12 11:00, Eric Sosman wrote:
>>
>> But where's the case that `#define table_max 4096' is
>> inferior to "coinst"? So far, the *only* reason that's been
>> put forward is "fir doesn't like it." Somehow, "I don't like
>> it, therefore it's stupid" doesn't sound like the sort of
>> proof Euclid would be proud of.


<snip debug example>
> Another somewhat contrived example is:
>
> #define X 42
>
> void f( const int* p );
>
> int main(void)
> {
> f(&X);
> }


You can write f(&(int){X}); so that it will work no matter if X is a
macro, an enum name or an int object (const or otherwise).

I don't suggest this as an elegant solution, but simply as a solution
that might be useful if the situation arises in some large code base.

--
Ben.
 
Reply With Quote
 
Richard Damon
Guest
Posts: n/a
 
      11-19-2012
On 11/18/12 4:44 PM, Keith Thompson wrote:
> fir <(E-Mail Removed)> writes:
>> It is sad to say so but there is some real and terrible stupidnes in
>> c99. When i wrote programs in c (and I am involved c user) I just use
>> const int for array boundaries but in c99 (and some previous too,
>> terribly) it will not compile (see for example
>> http://stackoverflow.com/questions/1...-at-file-scope
>> ) It is terribly wrong thing for ppl who just wants to use const int
>> to this purposes and not to use preprocesor - as I do. It is terribly
>> stupidness in my opinion, it have to be changed.

....
>
> Personally, I agree that it would be nice if C treated const definitions
> with constant initializers the way C++ does, so that given
>
> const int answer = 42;
>
> answer would be a constant expression, and I would support such a
> change in a future revision. Kenneth Brody pointed out a case where
> such a change could break existing code:
>
> ===== file1.c
>
> const int table_max = 100;
>
> ===== file2.c
>
> extern const int table_max;
>
> This could probably be worked around by making the definition introduce
> a constant expression *and* a read-only object. Or, I suppose, the
> commitee could decide that it's ok to break existing code in this case,
> though that's probably unlikely.
>
> But such a change would require some significant work to define its
> behavior in *all* cases, followed by changes to all conforming C
> implementations.


having a const int not generate an external global read only object
would be a big mistake in my opinion. One solution would be to use

static const int table_max = 100;

being static, the name only has scope for that translation unit, and the
compiler is allowed to omit the actual generation of the object by the
"as if" rule if it is not needed.

The other thing to note, is I believe that currently, multiple
definitions of a global in different translation units is not a
constraint violation, but undefined behavior, so the compiler would be
allowed (but not required) to make it work as expected, letting the
program compile, link, and run, and even not take up memory for the
value if not needed. Typically this would be done by making a "weak
definition" for the object, and letting the linker discard it if not
needed, or allow multiple definitions as needed.

It might be possible for a future standard to REQUIRE the compiler to
make this case work, but it might be hard to find a specification that
actually allowed the desired multiple definitions without also forcing
the compiler to accept as valid multiple definitions that are really
programming errors.

Another option might be to allow a construct like

extern const int table_max = 100;

to declare the value as a constant expression without allocating memory
for it, and require exactly one translation unit to have a definition like:

const int table_max;

to generate the memory location for any uses that might need it.


 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
W dniu niedziela, 18 listopada 2012 23:20:51 UTC+1 użytkownik Keith Thompson napisał:
>
> your English is certainly better than my own nonexistent Polish.)
>


Mysle, ze to moze byc prawda, (but do not
matter).

May add some things about const and arrays:
(somewhat different topic and area than my simple 'lack od const int array handling is
unpleasant')

As to const imo in c 'const idea' may relate
to a couple of things,
1) solid constant value located in ram
2) immediate constant value defined in language but resolved as a bunch of immediate
values
3) some readonly-like modifier that can be
even applied and removed in runtime
4) maybe yet even other meanings (If one
would see some other I would like to read
about it)

The other 'think theme' is a c way of handling
array sizes and array lengths, which is in some
part nonexistant in c, In other part it is
existant and that c way is that that array
sizes are held by static, 'compiler space ' approach. So there is no tradition of
combining localized ram info about array
sizes with arrays

1) it is somewhat cleaver to do it on
compiler space level (c spirit)

2) if this (ram array size handling)
could be done it could be possibly
done in more automatic way - the array
length int should be possibly handled
by compiler, so it could be in a way
part of array info not free constant int
related to that

(but those are more elaborate topics,
I am working on it on the area of more far
c improvements)

 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
W dniu poniedziałek, 19 listopada 2012 10:21:10 UTC+1 użytkownik fir napisał:
>
> The other 'think theme' is a c way of handling
> array sizes and array lengths, which is in some
> part nonexistant in c, In other part it is
> existant and that c way is that that array
> sizes are held by static, 'compiler space ' approach. So there is no tradition of
> combining localized ram info about array
> sizes with arrays
>
>
>
> 1) it is somewhat cleaver to do it on
> compiler space level (c spirit)
>
> 2) if this (ram array size handling)
> could be done it could be possibly
> done in more automatic way - the array
> length int should be possibly handled
> by compiler, so it could be in a way
> part of array info not free constant int
> related to that
>
>
>
> (but those are more elaborate topics,
> I am working on it on the area of more far
> c improvements)



(a want to add something)


In this citation above, indeed, it wass said how could it be done (but will write it more
explicit here maybe):

some five years ago I was thinking some
amount about fatpointers (pairs pointer length), (some dialect of c called cyclone has it as faras i remember)
one can also try to send size thru function
argument (as in K&R book AFAIR) but i see
there is a better aproach:

->

c lacks an lengthof() operator, it could be
done easily and also use efficiently (more
efficient than size passing)

Its value can be obtained in some cases
for free in static, compiler time approach
on the other cases it could be obtained from
this array length ram value handled by compiler
i was mentioning about before (thios could be
stored by compiler, for 100 arays it would be 100 stored longs, assigned inthe

int table[8866]; // internal lengthof_table assigned to 8866

moment and accesible by lengthof() operator or
such ways

it is reasonably ok idea I think but should also be under some more thinking yet

(fir)

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-19-2012
"James Kuyper" <(E-Mail Removed)> wrote in message
news:k8c4i1$eeq$(E-Mail Removed)...
> On 11/18/2012 08:36 PM, BartC wrote:


>> In that case C doesn't have true separate compilation either, if it needs
>> header files to tell it something about the contents of separate modules.

>
> The header files are compiled separately as part of each translation
> unit. It's even possible, and in some contexts useful, to have them
> compile differently in different translation units. They're basically
> just a technique for getting identical text into different translation
> units.


I do the same; that 'import module' stuff just boils down to including a
file in the same way that C does it.

The difference is that I allow that file to be created automatically as part
of how the language works. If that feature wasn't available, I could write
that file by hand, or code it directly, just like you have to do in C.
Conversely, you could bolt-on some utility to C to construct certain headers
automatically, which I'm sure is already done (and as I've done with
function prototypes).

So, if I knew there was an array X in module B of length 10, I could write
this in module A:

#define XLEN 10

but I'd need to keep it up-to-date every time B changed. (Of course if the
sources to B were hidden, then I wouldn't know this unless the authors
explicitly made this known, via docs or via an include file (in which case I
might not need my #define).)

Effectively, we've managed to export a local array size, a compile-time
constant, from a module. We're arguing about the mechanisms for doing so
automatically.

>>> It may be a useful concept when discussing a language that
>>> works that way, but talking about "compile time constants" in comparison
>>> to C, when using a language where "compile time" means something
>>> radically different from what it does in C is pretty much meaningless.

>>
>> I'm sure that 'compile-time' means pretty much the same, ie. a value
>> known
>> to the compiler.

>
> The implications are quite different when the things that can be known
> at compile time are different. A #defined constant in a shared header
> file can be known at compile time in C (and could be different in
> different translation units for the same header file, if set up
> properly).


Yes, that's a feature of C that makes it so easy to compile! (When a #define
expression includes __LINE__ for example.)

> The value of an object with external linkage that is defined
> in some other translation unit cannot be known at compile time in C, and
> cannot (with defined behavior at least) be different in different
> translation units, no matter what fancy tricks you use. The closest
> equivalents in your language works quite differently, and that changes
> the implications of "compile time".


Well actually I'm not so interested in the values of objects that use
storage, not at compile time anyway. That is an issue for C because it's
what C uses for 'const ints', part of the OP's problem.

(If 'proper' named constants were used (even enums), then the problem
wouldn't arise, and C doesn't allow enums to be external.)

However, if the value of such an object, in the module where it's defined,
is determinable by the compiler to be constant, then there's no reason why
that information can't be 'exported' in the same way that a plain number
could be.

Although I agree a lot of the existing features of C can make that much more
difficult than it need be. In that case the compiler would need to be able
to determine whether that value was also invariant (be the same on repeated
compilations), not defined recursively (perhaps defined in terms of itself
via a chain of extern statements!) and so on. So perhaps in this case it's
more trouble than it's worth.

--
Bartc

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-19-2012
"fir" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> c lacks an lengthof() operator, it could be
> done easily and also use efficiently (more
> efficient than size passing)


You mean like this:

#define lengthof(x) (sizeof(x)/sizeof(x[0]))

In C it's all done with macros.

Oh I forgot, you don't like macros...

--
Bartc

 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
W dniu poniedziałek, 19 listopada 2012 12:35:39 UTC+1 użytkownik Bart napisał:
> "fir" <(E-Mail Removed)> wrote in message
>
>
>
> > c lacks an lengthof() operator, it could be
> > done easily and also use efficiently (more
> > efficient than size passing)

>
> You mean like this:
>
> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>
> In C it's all done with macros.
>
> Oh I forgot, you don't like macros...
>


yes, i do not use macros

internal lengthof() would be better for
many reasons, also this macro would not
work in all situations, Mechanism i described
beore would work

though to rethink is one question, this
hidden length variables naming and related
wuestions, they should be seenable thru the
linker from different modules, but possibly
(not sure to that) not stright accesible
to programmer (in favor of lengthof operator)
- maybe i am not sure to that (need to rethink it yet more)

(professor fir (aka grunge fightr))

 
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