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-20-2012
BartC <(E-Mail Removed)> wrote:

> "fir" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...


>>> the question is how syntax to choose to distinguish between
>>> pointers-to-one and pointers-to-many in such cases:
>>> void print(char* text) //pointer to undefined many
>>> {
>>> }
>>> void print(char(1)* text) //pointer to one ?
>>> {
>>> }


>> also think sometimes (like here) if java-like
>> syntax wouldnt be clearer


>> char a; //a is adress to one
>> char[] a; //a is adress to undefined many
>> char[16] a; //a is adress to chunk of 16 chars


If you want to call them addreses, you need to be careful as
to what is constant and what isn't.

In the first case, &a is a constant. In the third case,
I am not so sure, but a would be for char a[16];

>> it seem clearer and *a could be reserved
>> eventually for old way


> In my opinion, C type syntax is broken. And that's not just the convoluted
> syntax.


> It's because char[] means different things in different contexts: an array
> in some places, and a pointer in another:


> char a[]={65,66,67}; // array


> void fn (char[] a); // pointer


Not quite as many meanings as the word "static", though.

> char[] meaning array would be illegal in a parameter context, but instead of
> leaving that hole in the 'map' of possible types, everything moves up one
> instead! The penchant for C to gloss over any dereferences needed - or not
> needed - to index an array/pointer, just confuses things further.


I believe that some think that the function argument [] was a mistake,
though I sort of like it. (Not that I usually use it.)

The array case could have been done something like char a[*]={65,66,67};
indicating that there is an unknown length.

> I think you have your work cut out...


-- glen
 
Reply With Quote
 
 
 
 
fir
Guest
Posts: n/a
 
      11-20-2012
W dniu wtorek, 20 listopada 2012 16:47:22 UTC+1 użytkownik Bart napisał:
> "fir" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> > W dniu wtorek, 20 listopada 2012 13:52:40 UTC+1 użytkownik Ben Bacarisse

>
> > napisał:

>
>
>
> >> Nicer than what? As it happens, 'int[10]' is the type name

>
>
>
> > I mean that this way of array definition seem

>
> > to be better (than present)

>
> >

>
> > int t[100]; <- worse

>
> >

>
> > int[100] t; <- better

>
>
>
> Have a look at some other languages. For example the D programming language
>
> (dlang.org), which has tidied up the language quite a bit, and uses your
>
> syntax for arrays. It might give some ideas.
>
>
>
> (However I don't think it's gone quite far enough. That array would be
>
> declared, in another language I use, as:
>
>
>
> [100]int t
>
>
>
> this uses a consistent left-to-right syntax which matches the descriptionof
>
> the type in English.)
>
>


I ve done overview of D also, It is ok, but
my own improvements goes much different way

my c2 goes much to modular programming, also
polishes the surface (as here with lenghtof
and arrays or default passing by implicit
pointers in calls)

void foo(Some s) //s struct by implicit adres
{
s.x = 0;
}

, also posiibly operators
in "c = a (dot) b;" form, realloc mechanism
(keyword) for arrays, possibly binding soma
call contexts as in

void f()
{
for(;
{
char c = getchar("file.txt");

if(eof) //eofand error are wariables
break; // form getchar contex
if(error) // possibly statics of getchar
break;
}

}


float4 internal type (for sse accelerated
operations), many returned values

(int x, int y ) foo( int a, int b)
{

}

any binary data for min input output,
ad hoc enums (ad hoc enum values with no definietion
very convenient do_something(10,10,'quick') //'quick'
would be ad hoc enum)

and more - it is long list as to today already
but still searching for improvements

(so tnx for supporting it and bringing all the
possible source of concepts, it is welcome, though
really all of them on my own list was of my own thinking
and as today not even one was taken from reading
something external )

(fir)
 
Reply With Quote
 
 
 
 
fir
Guest
Posts: n/a
 
      11-20-2012
W dniu wtorek, 20 listopada 2012 18:08:07 UTC+1 użytkownik Kenneth Brody napisał:
> On 11/19/2012 2:22 PM, fir wrote:
>
> > W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał:

>
> >> On 12-11-19 09:42 AM, fir wrote:

>
> >>

>
> >>> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał:

>
> >>

>
> >>>>

>
> >>>>

>
> >>>> Note: there are only three values you can pass to exit() with behavior

>
> >>>> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0..

>
> >>>> The meanings of -1 or 13 can be different for different implementations

>
> >>>> of C.

>
> >>>

>
> >>> I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago,

>
> >>> here I just used it as an argument that clever

>
> >>> improvements ale welcome - so there is point

>
> >>> of inventing and also talking about them )

>
> [...]
>
> > (answer also to James Kuyper couse it is about the same thing) I just think that returning a

>
> > string (or possibly maybe even accepting any binary data thru input andoutput) will be

>
> > better and more informative. OS could do

>
> > everything he wants, possibly print it out

>
> > in console or send it as an input to other c program (it is much unix like in good way)

>
> > It is good idea imo.

>
> >

>
> > for example i would like much more return an

>
> > "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes

>
>
>
> But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S
>
> you are likely to run into, all permit a single integer (sometimes only 7
>
> bits, in fact) to be "returned", how do you propose to return a string to
>
> the O/S?
>
>
>
> The best you can hope for is a replacement for "exit(int)", such as
>
> "my_exit(char *,int)", which displays the string, and then returns the
>
> specified exit code to the O/S.
>
>


systems could be rewritten :O Iam spiking here
about 'technical goodnes' what would be good
(better then present)
it is not about exit("some string") but its
about, some like

char* main(char*)
{
return "halo world";
}

kool imo
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-20-2012
On 11/20/2012 02:37 PM, fir wrote:
> W dniu wtorek, 20 listopada 2012 18:08:07 UTC+1 użytkownik Kenneth Brody napisał:
>> On 11/19/2012 2:22 PM, fir wrote:

....
>> But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S
>> you are likely to run into, all permit a single integer (sometimes only 7
>> bits, in fact) to be "returned", how do you propose to return a string to
>>
>> the O/S?

....
> systems could be rewritten :O. ...


No, they cannot; at least, not by the C committee. It doesn't have that
authority. Only operating system designers have that authority (and if
they exercised that authority, it could easily break the vast majority
of existing programs). Those designers appear to have almost universally
disagreed with you on this issue. Even if you're right, they're not
likely to change their minds any time soon, and the chance that the
overwhelming majority of them will adopt your idea is vanishingly small
for the foreseeable future. Without that overwhelming majority, it
doesn't make sense for the C standard to adopt your idea.

So long as it is the goal of the C committee to define C in such a way
that it can in fact be implemented "almost everywhere", the definition
of C will have to cope with the fact that virtually every system that
has a concept of an exit status, uses an integer of some kind for that
status, and (almost?) none of them uses a text string for that purpose.

> ... Iam spiking here
> about 'technical goodnes' what would be good
> (better then present)
> it is not about exit("some string") but its
> about, some like
>
> char* main(char*)
> {
> return "halo world";
> }


The standard currently allows an implementation to accept such code. If
anybody ever decides to design an operating system that's compatible
with your concept, it would be entirely reasonable for an implementation
targeted for that operating system to do so. However, so long as the
overwhelming majority of existing operating systems accept only integers
as exit statuses, and not strings, the C standard can NOT mandate
acceptance of such code; not unless you're willing to address the issue
of what it should do when compiled for an operating system that doesn't
accept strings.

 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      11-20-2012
James Kuyper <(E-Mail Removed)> wrote:
> On 11/20/2012 02:37 PM, fir wrote:
>> W dniu wtorek, 20 listopada 2012 18:08:07 UTC+1 u??ytkownik Kenneth Brody napisa??:
>>> On 11/19/2012 2:22 PM, fir wrote:


>>> But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S
>>> you are likely to run into, all permit a single integer (sometimes only 7
>>> bits, in fact) to be "returned", how do you propose to return a string to
>>> the O/S?


>> systems could be rewritten :O. ...


> No, they cannot; at least, not by the C committee. It doesn't have that
> authority. Only operating system designers have that authority (and if
> they exercised that authority, it could easily break the vast majority
> of existing programs). Those designers appear to have almost universally
> disagreed with you on this issue. Even if you're right, they're not
> likely to change their minds any time soon, and the chance that the
> overwhelming majority of them will adopt your idea is vanishingly small
> for the foreseeable future. Without that overwhelming majority, it
> doesn't make sense for the C standard to adopt your idea.


Note that Fortran allows one to specify either a numeric or
string value on the STOP statement. That hasn't stopped implementations
on systems that didn't support string status values.

> So long as it is the goal of the C committee to define C in such a way
> that it can in fact be implemented "almost everywhere", the definition
> of C will have to cope with the fact that virtually every system that
> has a concept of an exit status, uses an integer of some kind for that
> status, and (almost?) none of them uses a text string for that purpose.


I am sure that the Fortran committee feels the same way.

The usual implementation, for either numeric or string value,
is to print it on along with the program output. Recent Fortran
has an ERROR_UNIT, what unix calls stderr.

Now, I know that people have complained about the value being
printed, either numeric or string, but it is part of the standard.

Some things are easier to work around than others, and standards
usually allow for such things.

-- glen
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-20-2012
fir <(E-Mail Removed)> writes:
>> I guess that English is not your first language, so perhaps you're
>> not aware that the word "stupid" is quite insulting. I suggest


I wrote the above. When you post a followup, whatever interface
you're using (Google Groups in your case) adds an attribution line,
indicating who wrote the quoted text. Please don't delete that line.
It makes it much easier to follow the discussion.

> I do like c in very much extent so it sound
> totaly fantastic (not real( to me, I use
> called it stupidness becouse I was/am real
> angry/mad to know that I cannot use const int
> in c99 and finding also explanation sort of 'consyt int x doeas not mean that x is const'
> (and the fact that i can throw c compilers to trashbin)
> I feel i can call it stupidnees though some
> explanations what do I mean would be required
> - I said what do I meant


"const int x;" certainly does mean that x is const. It doesn't mean
that x is *constant*.

The problem (and I agree that it's a problem) is that "const" doesn't
mean "constant". It means "read-only". As such, it works exactly the
way it's supposed to.

So as I see it, there are two problems here, neither of them horrible.

First, the "const" keyword would cause less confusion if it were spelled
"readonly". It could work exactly the way it works now, and it wouldn't
raise the expectation that a readonly object can be used as a constant
expression.

Second, there's no way (other than enum and #define, both of which have
their problems) to define an identifier that can be used as a constant
expression.

We don't have the luxury of redefining the language and breaking
existing code, but if we did, I'd suggest the following (among many
other things):

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

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

constant int x = 42;

constant int y = 1.0/3.0; /* not exactly representable,
but still constant */

constant char ESC = '\x1b';

A "constant" declaration does not create an object; no storage is
allocated for it, and it has no address. The defined identifier
can be used as a constant expression of the specified type, with
the value of the initializer. The initializer must be a constant
expression. The type must be a scalar type; I haven't thought about
the semantics for pointer types, but "const void *nullptr = NULL;"
would be permitted and useful.

I would *not* suggest having both "const" and "constant" as keywords;
that would be too confusing. Though I suppose the committee could
add a "constant" keyword, as described above, without breaking
anything other than code that uses "constant" as an identifier
(or adding a "_Constant" keyword and a <stdconstant.h> header with
"#define constant _Constant").

As for the current lack of this feature, I'd say you've already
made your point.

--
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
 
Keith Thompson
Guest
Posts: n/a
 
      11-20-2012
"BartC" <(E-Mail Removed)> writes:
[...]
> Apparently 'separate compilation' can involve hard-coding a constant
> imported from a 3rd-party header, which needs to be repeated when that
> header is updated.
>
> That, according to you, is completely different from hard-coding a constant
> imported from a header (3rd party or otherwise), if that header includes
> some automatically gleaned content. (Although for all we know, windows.h is
> also partly generated with tools we don't know about, extracting global data
> in the manner I've suggested.)


I have no problem with an automated tool that generates a .h file
from information in a .c file. It does create a dependency on
that .c file, but that's created by the build environment, not by
the language.

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

If I have a library implemented by source files foo.h and foo.c, and I
want to write a program that uses that library, all I need is foo.h and
foo.o. I can compile my main.c that has `#include "foo.h"`, and I can
link with foo.o, and I never need to see a copy of foo.c.

Breaking that model is not an option.

--
Keith Thompson (The_Other_Keith) (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
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      11-20-2012
Keith Thompson <(E-Mail Removed)> wrote:
> fir <(E-Mail Removed)> writes:
>>> I guess that English is not your first language, so perhaps you're
>>> not aware that the word "stupid" is quite insulting. I suggest


> I wrote the above. When you post a followup, whatever interface
> you're using (Google Groups in your case) adds an attribution line,
> indicating who wrote the quoted text. Please don't delete that line.
> It makes it much easier to follow the discussion.


(snip)

> "const int x;" certainly does mean that x is const.
> It doesn't mean that x is *constant*.


C does give words funny meanings sometimes, my old favorite
being "static" which has about five meanings.

> The problem (and I agree that it's a problem) is that "const" doesn't
> mean "constant". It means "read-only". As such, it works exactly the
> way it's supposed to.


> So as I see it, there are two problems here, neither of them horrible.


> First, the "const" keyword would cause less confusion if it were spelled
> "readonly". It could work exactly the way it works now, and it wouldn't
> raise the expectation that a readonly object can be used as a constant
> expression.


> Second, there's no way (other than enum and #define, both of which have
> their problems) to define an identifier that can be used as a constant
> expression.


Hmm. Java has static final where you need compile time constants.

Does C already have a meaning for static const?

Fortran has PARAMETER, I believe tracing back to some DEC compilers
from years ago. For a long time, Fortran didn't allow for constant
expressions. You couldn't dimension an array 2+2, but only 4.
There are some macro processors that will evaluate constant
expressions for languages that don't.

> We don't have the luxury of redefining the language and breaking
> existing code, but if we did, I'd suggest the following (among many
> other things):


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


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


> constant int x = 42;


> constant int y = 1.0/3.0; /* not exactly representable,
> but still constant */


> constant char ESC = '\x1b';


> A "constant" declaration does not create an object; no storage is
> allocated for it, and it has no address. The defined identifier
> can be used as a constant expression of the specified type, with
> the value of the initializer. The initializer must be a constant
> expression. The type must be a scalar type; I haven't thought about
> the semantics for pointer types, but "const void *nullptr = NULL;"
> would be permitted and useful.


I don't know that storage can't (couldn't) be allocated, but yes,
it seems likely that one couldn't have a pointer to one, as one
can't to other constants.

At least some systems would allow for constant pointers to
static data. (What OS/360 calls address constants, resolved
by the linker, and then relocated by program fetch.)

> I would *not* suggest having both "const" and "constant" as keywords;
> that would be too confusing. Though I suppose the committee could
> add a "constant" keyword, as described above, without breaking
> anything other than code that uses "constant" as an identifier
> (or adding a "_Constant" keyword and a <stdconstant.h> header with
> "#define constant _Constant").


> As for the current lack of this feature, I'd say you've already
> made your point.


-- glen
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-20-2012
On 11/21/12 10:14, Keith Thompson wrote:
>
> The problem (and I agree that it's a problem) is that "const" doesn't
> mean "constant". It means "read-only". As such, it works exactly the
> way it's supposed to.
>
> So as I see it, there are two problems here, neither of them horrible.
>
> First, the "const" keyword would cause less confusion if it were spelled
> "readonly". It could work exactly the way it works now, and it wouldn't
> raise the expectation that a readonly object can be used as a constant
> expression.
>
> Second, there's no way (other than enum and #define, both of which have
> their problems) to define an identifier that can be used as a constant
> expression.
>
> We don't have the luxury of redefining the language and breaking
> existing code, but if we did, I'd suggest the following (among many
> other things):
>
> 1. Change the "const" keyword to "readonly".
>
> 2. Add a "constant" keyword, allowing you to define things like:
>
> constant int x = 42;
>
> constant int y = 1.0/3.0; /* not exactly representable,
> but still constant */
>
> constant char ESC = '\x1b';


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

--
Ian Collins
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-20-2012
On 11/20/2012 04:14 PM, glen herrmannsfeldt wrote:
....
> Note that Fortran allows one to specify either a numeric or
> string value on the STOP statement. That hasn't stopped implementations
> on systems that didn't support string status values.


Yes, and the Fortran specifies what it does with that string: it
displays it, rather than attempting to pass it as an exit status. 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.
 
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