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

 
 
fir
Guest
Posts: n/a
 
      11-19-2012
W dniu poniedziałek, 19 listopada 2012 17:42:18 UTC+1 użytkownik Eric Sosman napisał:
>
> trace its explosive resurgence to feature creep. Let's at least
> make it no worse, okay?
>


some improvements would be strngly velcome
for some, for example I am always mad when
i must exit(-1) or exit(13) instead of
exit("some string") For me cleaver improvements are nice.
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 12:06 PM, fir wrote:
> W dniu poniedziałek, 19 listopada 2012 17:42:18 UTC+1 użytkownik Eric Sosman napisał:
>>
>> trace its explosive resurgence to feature creep. Let's at least
>> make it no worse, okay?
>>

>
> some improvements would be strngly velcome
> for some, for example I am always mad when
> i must exit(-1) or exit(13) instead of
> exit("some string") For me cleaver improvements are nice.


Assume that the standard were changed to allow that - what would you
want it to do with the string? What should people do who don't want that
to happen? Whether you like it or not, many existing operating systems
require that when programs exit, they pass to the operating system an
exit status of some kind. If you use exit("some string"), which exit
status should it pass to the operating system? If someone wanted to pass
a different exit status, how could they do that?
Whatever it is you want that function to do, you can probably trivially
write your own function as a wrapper for exit(), and have it do whatever
it is that you want it to do:

void my_exit(const char*message)
{
fputs(message, stderr);
exit(EXIT_SUCCESS);
}

That way, only your code has to work this way; people who want different
behavior when the program exits are free to write they're own exit wrappers.

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.
 
Reply With Quote
 
 
 
 
fir
Guest
Posts: n/a
 
      11-19-2012
W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał:
> On 11/19/2012 12:06 PM, fir wrote:
>
> > W dniu poniedziałek, 19 listopada 2012 17:42:18 UTC+1 użytkownik Eric Sosman napisał:

>
> >>

>
> >> trace its explosive resurgence to feature creep. Let's at least

>
> >> make it no worse, okay?

>
> >>

>
> >

>
> > some improvements would be strngly velcome

>
> > for some, for example I am always mad when

>
> > i must exit(-1) or exit(13) instead of

>
> > exit("some string") For me cleaver improvements are nice.

>
>
>
> Assume that the standard were changed to allow that - what would you
>
> want it to do with the string? What should people do who don't want that
>
> to happen? Whether you like it or not, many existing operating systems
>
> require that when programs exit, they pass to the operating system an
>
> exit status of some kind. If you use exit("some string"), which exit
>
> status should it pass to the operating system? If someone wanted to pass
>
> a different exit status, how could they do that?
>
> Whatever it is you want that function to do, you can probably trivially
>
> write your own function as a wrapper for exit(), and have it do whatever
>
> it is that you want it to do:
>
>
>
> void my_exit(const char*message)
>
> {
>
> fputs(message, stderr);
>
> exit(EXIT_SUCCESS);
>
> }
>
>
>
> That way, only your code has to work this way; people who want different
>
> behavior when the program exits are free to write they're own exit wrappers.
>
>
>
> 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 )
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-19-2012
"Eric Sosman" <(E-Mail Removed)> wrote in message
news:k8dnh9$pot$(E-Mail Removed)...
> On 11/19/2012 9:25 AM, BartC wrote:


>> (However. once a string length *has* been calculated, you can then
>> construct a (pointer,length) type, and now you have counted strings! As
>> well as string slices, pointing to a substring in the middle of a
>> string, etc.)

>
> When strchr() finds a character in a string, what "span" should
> the returned pointer have? Should its limits cover the whole string,
> just the tail from the start of the search, just the part searched,
> the entire array containing the string, just the located character,
> or what?


As strchr() works now (I've just looked it up because I've never used it),
you pass it a char pointer (to a string), and it returns a char pointer (to
a char).

There's no particular advantage in using an enhanced pointer that also
contains a length, and the length of the result will be 1 if it's
successful.

But counted strings do have their uses: strlen() becomes trivial for a
start, also not requiring a zero terminator makes all sorts of things
possible. They wouldn't replace what's already in the language however. And
a lot of this can be done using existing language features (structs and
functions). It would just be tidier if 'fat' pointers were added to the
language.

--
Bartc

 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
> fputs(message, stderr);
>


why not fputs ? for aesthetic purposes
(as a programmer i work in beauty)

fputs is from library and without it one
can wrote useful programs without no api

but this bring it back to problem of arrays
and its sizes becouse of

(char* output, int lengthof_output) main(char* input, int lenghtof_input)
{

}

(char output[]) mian(char input[])
{

}

the second seem better in some ways
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-19-2012
"Eric Sosman" <(E-Mail Removed)> wrote in message
news:k8dljp$db3$(E-Mail Removed)...
> On 11/18/2012 7:04 PM, BartC wrote:


>> So when victim is compiled, it will use the current value of table_max
>> in whichever file1 or file2 has been chosen. To create two programs with
>> two different values of table_max, requires recompilation of victim in
>> each case.

>
> ... which was James' point: "Any language that allows you
> to do this does not support true separate compilation." If I
> must recompile victim.c for each potential partner fileX.c, there
> is no more separate compilation.


In your example, you were constructing two different programs: victim+file1,
or victim+file2.

You were deferring the selection of that companion file until 'link-time',
using a mechanism which I guess is not defined by the language.

In my example, I was suggesting that the selection was made at compile-time,
either victim+file1, or victim+file2 (with a mechanism not known to C
either). There isn't that much difference.

And in practice, changing a header file used by dozens of modules will
require recompilation of those modules; they are not that independent.

> But what you're suggesting requires
> re-compilation of a translation unit that has *not* changed, because
> of something that's happened in some other translation unit.


Yes, but there is an advantage in doing so (being able to use less
indirection for example because of dealing with constants not extern
variables).

But this happens in C anyway: if I supply you with a library (a binary file)
and a header for it, you need to compile a program using my header.

If I release an update, and a new header, it would be advisable to recompile
your program with that header, even though nothing has changed in your
program. You can say that that header is part of the same translation unit,
but that is just words (my files containing export data also become part of
the same translation unit).

--
Bartc

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 12:42 PM, fir wrote:
> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał:
>> On 11/19/2012 12:06 PM, fir wrote:

....
>>> for some, for example I am always mad when
>>> i must exit(-1) or exit(13) instead of
>>> exit("some string") For me cleaver improvements are nice.

>>
>> Assume that the standard were changed to allow that - what would you
>> want it to do with the string? What should people do who don't want that
>> to happen? Whether you like it or not, many existing operating systems
>> require that when programs exit, they pass to the operating system an
>> exit status of some kind. If you use exit("some string"), which exit
>> status should it pass to the operating system? If someone wanted to pass
>> a different exit status, how could they do that?
>> Whatever it is you want that function to do, you can probably trivially
>> write your own function as a wrapper for exit(), and have it do whatever
>> it is that you want it to do:
>>
>> void my_exit(const char*message)
>> {
>> fputs(message, stderr);
>> exit(EXIT_SUCCESS);
>> }
>>
>>
>> That way, only your code has to work this way; people who want different
>> behavior when the program exits are free to write they're own exit wrappers.
>>
>> 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,


That's fine, but doesn't really answer my question - after you return
that string value, what do you want to have happen to it? If all you
want to do is return it, and you don't really care what happens to it
after it has been returned, you can achieve essentially the same result
in C by just typing:

exit("some string",0);

If you don't consider that an acceptable solution to your problem, that
means that you do care what happens to it after it has been returned,
and you should tell us what you want that to be.
However, in that case, you've got a serious problem: exit() marks the
beginning of the end of a C program; when it's done, "control returns to
the host environment". From that point onwards, the possibilities for
what can happen are determined by the host environment, and not by the C
standard.

The only thing the C standard requires is the ability to distinguish
successful and unsuccessful exit status. The committee decided on this
as a least-common denominator that would be implementable on almost
every known platform. If the host environment doesn't allow reporting an
exit status, a conforming implementation can simply ignore the argument
passed to exit(). On almost every system that does allow an exit status
to be reported, the distinction between unsuccessful and successful
results is sufficient. If, in some environment, more distinctions are
desired, the argument passed to exit() provides an interface that allows
such inherently unportable code to be written. If the host environment
requires more information than can be encoded in an 'int',
implementations of C targeting that environment would have to implement
an extension to C allowing the extra information to be reported.

Now, if you want to restrict your code to host environments which allow
the exit status to be a string, the current standard allows a fully
conforming implementation of C for such an environment to accept code
like the following:

exit((int)"some string");

This implies that 'int' must be big enough to reversibly store the
location of the string. If that would make 'int' too large to be useful
for other purposes, then an implementation targeting that environment
would have to provide some other method of specifying the string to be
returned. It also implies that if there is any char* pointer which
converts to an int value of 0, the string it points at (if any) must be
treated as having a successful exit status.

The key point is that the C standard is deliberately intended to be
implementable in a wide variety of host environments, including ones
which do NOT allow returning a string as an exit status. Therefore, if
you want the C standard to allow exit("some string"), it will need to
specify the required behavior of exit() in an implementation of C
targeted for such an environment. What do you think that specification
should be?

For reference, the current specification is:
"If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful termination is
returned. If the value of status is EXIT_FAILURE, an
implementation-defined form of the status unsuccessful termination is
returned. Otherwise the status returned is implementation-defined."
(7.22.4.4p5)
Any new specification will need to be backward compatible with the
current one, or it will have no chance of being accepted.

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


Well, since you brought it up, I'm using it as an example of how
seemingly "clever" "improvements" may have unforeseen consequences that
render them neither "clever", nor an "improvement".

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 01:20 PM, fir wrote:
>> fputs(message, stderr);
>>

>
> why not fputs ? for aesthetic purposes


I did use fputs(). Did you mean "Why fputs()?" - if so, you should
specify your preferred alternative. That hardly matters - it was just
meant as an example. If you do have a preferred alternative, use it.

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-19-2012
On 11/19/2012 1:25 PM, BartC wrote:
> "Eric Sosman" <(E-Mail Removed)> wrote in message
> news:k8dljp$db3$(E-Mail Removed)...
>> On 11/18/2012 7:04 PM, BartC wrote:

>
>>> So when victim is compiled, it will use the current value of table_max
>>> in whichever file1 or file2 has been chosen. To create two programs with
>>> two different values of table_max, requires recompilation of victim in
>>> each case.

>>
>> ... which was James' point: "Any language that allows you
>> to do this does not support true separate compilation." If I
>> must recompile victim.c for each potential partner fileX.c, there
>> is no more separate compilation.

>
> In your example, you were constructing two different programs:
> victim+file1, or victim+file2.


Exactly.

> You were deferring the selection of that companion file until
> 'link-time', using a mechanism which I guess is not defined by the
> language.


You could improve your guess by reading 5.1.1.1, 5.1.1.2p1
(point , 6.2.2, and so on.

> In my example, I was suggesting that the selection was made at
> compile-time, either victim+file1, or victim+file2 (with a mechanism not
> known to C either). There isn't that much difference.


Exactly: You suggest "whole-program compilation" rather than
"separate compilation." C requires the latter.

> And in practice, changing a header file used by dozens of modules will
> require recompilation of those modules; they are not that independent.


That distinction's already been explained to you by me and
by others, but the explanations don't seem to have penetrated.

>> But what you're suggesting requires
>> re-compilation of a translation unit that has *not* changed, because
>> of something that's happened in some other translation unit.

>
> Yes, but there is an advantage in doing so (being able to use less
> indirection for example because of dealing with constants not extern
> variables).


Also the "advantage" of compiling each module once for use
in its unit test and again for use in the target program, with
the knowledge that in your model the two compilations are allowed
to produce drastically different code ...

Not sure where "indirection" comes into play.

> But this happens in C anyway: if I supply you with a library (a binary
> file) and a header for it, you need to compile a program using my header.
>
> If I release an update, and a new header, it would be advisable to
> recompile your program with that header, even though nothing has changed
> in your program.


Yes: A change in the header is a change in your API, and
I must recompile. But if you release an update *without* a new
header -- you've fixed a bug or implemented a speedup, say, while
leaving the API unchanged -- in C-as-it-is I need not recompile,
while in C-as-you-suggest I must.

> You can say that that header is part of the same
> translation unit, but that is just words (my files containing export
> data also become part of the same translation unit).


Nonsense. Do you claim that the Standard library is part
of the helloworld.c translation unit? (While reading 5.1.1.1,
you might want to take note of its definition of "translation
unit," and acquaint yourself with the way everybody else uses
"just words.")

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      11-19-2012
> functions). It would just be tidier if 'fat' pointers were added to the
> language.



probably some form of it would be needed
(maybe not fat pointers in general but
passing two values for any various
lenght array)

void clear(char table[])
{
for(int i=0; i<lengthof(table[]); i++)
{
table[i]=0;
}
}

here table adr and table lenght would
be sent thru stack

if one want to optimize it he could do


void clear(char table[4096]) // for 4096-size arrays only
{
for(int i=0; i<lengthof(table[]); i++)
{
table[i]=0;
}
}

and

void clear_table() // hardcoded
{
for(int i=0; i<lengthof(table[]); i++)
{
table[i]=0;
}
}

 
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