Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Avoiding "use of cast expressions in lvalues is deprecated"

Reply
Thread Tools

Avoiding "use of cast expressions in lvalues is deprecated"

 
 
Mark McIntyre
Guest
Posts: n/a
 
      09-19-2006
On Tue, 19 Sep 2006 21:51:56 +0200, in comp.lang.c , Skarmander
<(E-Mail Removed)> wrote:

>Oh, it's not just extensions. Aren't you just appalled that you can't
>compile some K&R C code with the latest versions of gcc? As if rewriting a
>fully functioning program to conform to ANSI improves it! How much would it
>have cost to keep full K&R support in the compiler, anyhow?


I guess the standards committee would argue that its the price one
pays for improving the typechecking system. Presumably there are those
in world would have their cake and eat it, that would insist they want
safer code but don't want to pay the cost . The same people probably
insist its their right to drive rusty pollution emitting physically
unsound trucks, after all it was good enough for grandaddy up in the
hills fifty years ago.

>The regrettable result of changing the language is that developers are kept
>busy for no immediate reward.


Speak for yourself! Good money in upgrading s/w to match modern
standards.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
Reply With Quote
 
 
 
 
Skarmander
Guest
Posts: n/a
 
      09-19-2006
Mark McIntyre wrote:
> On Tue, 19 Sep 2006 21:51:56 +0200, in comp.lang.c , Skarmander
> <(E-Mail Removed)> wrote:
>
>> Oh, it's not just extensions. Aren't you just appalled that you can't
>> compile some K&R C code with the latest versions of gcc? As if rewriting a
>> fully functioning program to conform to ANSI improves it! How much would it
>> have cost to keep full K&R support in the compiler, anyhow?

>
> I guess the standards committee would argue that its the price one
> pays for improving the typechecking system.


But perfect programs don't need an improved typechecking system. It already
works, so we should leave it alone. Of course, I do expect my compiler
vendor to keep improving the compiler, just not the language it compiles.
Those ANSI C folks just missed the boat when K&R laid down the law.

>> The regrettable result of changing the language is that developers are kept
>> busy for no immediate reward.

>
> Speak for yourself! Good money in upgrading s/w to match modern
> standards.
>

Yes, quite true. The "reward" I spoke of was in relation to the code
rewritten in the process (under the assumption that it's perfect, of
course), not the developers doing the rewriting... I should have been less
ambiguous.

S.
 
Reply With Quote
 
 
 
 
Frederick Gotham
Guest
Posts: n/a
 
      09-19-2006
jacob navia posted:

> I wanted to introduce the same extension as gcc what lvalued
> casts is concerned several years ago, but a huge OUTCRY in
> the lcc group refrained me from doing that...



What's wrong with the following?

#define L_VALUE_CAST(type,expr) (*(type*)&(expr))

Of course, it won't work with more complicated types such as arrays and
function pointers, but it's a start.

--

Frederick Gotham
 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      09-19-2006
jacob navia wrote:
> Skarmander wrote:
>> Oh, it's not just extensions. Aren't you just appalled that you can't
>> compile some K&R C code with the latest versions of gcc? As if
>> rewriting a fully functioning program to conform to ANSI improves it!
>> How much would it have cost to keep full K&R support in the compiler,
>> anyhow?
>>

> Wow, this is good news, I did not know that!!!
>

Don't get your hopes up. If people flock to a new compiler, it's not going
to be for K&R support.

> I am finishing the lcc-lin32 version of lcc-win32 for linux.
> It features a 32 bit compiler, much faster than gcc (approx
> a speedup of 10 times).
>

Good for you. It may have niche uses.

Well, don't get me wrong, compilation speed is one important aspect of a
compiler, but I won't be recompiling my Ubuntu distribution with it any time
soon. Maybe in a year or so, when other people have gathered experiences.

Actually, make that two years.

> This means I will get all those "clients" dissatisfied with
> gcc.
>

Really? You mean to say your compiler has none of the issues specified here
http://gcc.gnu.org/onlinedocs/gcc-4....ibilities.html
*and* is compatible with gcc in other respects?

I take it you're also going to make your compiler free for commercial or
educational use? Oh, and where can I download the source, in case I find a
bug I need to fix yesterday?

Hmm, well, you're not going to get *all* clients dissatisfied with gcc. And
don't forget there are other contenders for the "faster than gcc" title,
even on Linux.

> I wanted to introduce the same extension as gcc what lvalued
> casts is concerned several years ago, but a huge OUTCRY in
> the lcc group refrained me from doing that...
>
> Maybe I should try again


That would be evil[*]. There are perfectly portable ways of writing what you
can do with lvalued casts (leaving aside that some of it may nevertheless be
implementation-defined). For God's sake, it's not even hard to do! If you
deliberately implement this as an extension now, when even gcc is moving
away from it (with plenty of advance warning, I might add), you encourage
people to make (continued or new) use of a pointless extension. The result
is vendor lock-in, which is good for you, and proliferation of gratuitously
unportable code written in not-quite-C, which is good for people who don't
care about quality code. Neither of this is good for the world as a whole.

S.[*]I use the word in a strictly utilitarian sense.
 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      09-19-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Richard Tobin wrote:
> > It's never been standard C. It was allowed by some early C compilers
> > and in some drafts of the first ANSI C standard, and is allowed by gcc
> > as an extension.

>
> Now that I never knew - sometimes it's unwise to learn a language from
> a compiler.


No, it's _always_ unwise to learn a language from a compiler. The C
standard allows greate freedom in implementation, but also requires
them to make (and document) choices. As a consequence, the
implementation you 'learn' on one machine need not be the same as
others.

> > #define NEXT(type, p, t) ((t) = (p), p += sizeof(type), (type *)*(t))


#define NEXT(type, p) \
( * (type *) ( (p += sizeof(type)) - sizeof(type) ) )

Both assume that p is a pointer to a character type (amongst other
things.)

> Thanks guys, that's exactly what I needed - the standard way to think
> about the problem, and the pitfalls of doing it the cowboy method.


Well, it still has problems that the conversion of p to a type *
pointer need
not be defined (e.g. alignment). There are plenty of implementations
where
this method will fail miserably.

--
Peter

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-20-2006
Mark McIntyre wrote:
> On Tue, 19 Sep 2006 12:39:14 +0200, in comp.lang.c , jacob navia
> <(E-Mail Removed)> wrote:
>
>
>>In my opinion, a compiler that introduces an extension should be
>>fair to the users that use that extension and never take it back
>>without a means to the users to keep their code as is.

>
>
> Where possible, given new requirements placed upon the compiler by
> standardisation.
>
>>It is apparently not the way gcc works, maybe as a result of the
>>C++ habit of invalidating code bases. In C++ is a daily problem that
>>code that works with version x.x of the compiler will stop working
>>in version x.x+1.

>
>
> This from the man crying out for gets() to be removed from the C
> standard. Double standards as well as inflammatory disinformation.
>


The proposal I published in comp.std.c was to make an
Appendix to the standard where obsolescent features would be
described, that are no longer part of the official standard.

Nowhere I wanted to just delete gets(). Users that want to use it
could use it using a compatibillity library based on that Appendix.
Whether an implementation follows that (non-normative) standard
Appendix is up to the implementation. Since all implementations have
gets() NOW, building such a compatibility library would be
very easy and most vendors would have it.

You are just misrepresenting my proposal, and then... YOU accuse
me of "double standards"!!!
 
Reply With Quote
 
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
Guest
Posts: n/a
 
      09-20-2006
jacob navia wrote:
> Mark McIntyre wrote:
> > On Tue, 19 Sep 2006 12:39:14 +0200, in comp.lang.c , jacob navia
> > <(E-Mail Removed)> wrote:
> >
> >
> >>In my opinion, a compiler that introduces an extension should be
> >>fair to the users that use that extension and never take it back
> >>without a means to the users to keep their code as is.

> >
> >
> > Where possible, given new requirements placed upon the compiler by
> > standardisation.
> >
> >>It is apparently not the way gcc works, maybe as a result of the
> >>C++ habit of invalidating code bases. In C++ is a daily problem that
> >>code that works with version x.x of the compiler will stop working
> >>in version x.x+1.

> >
> >
> > This from the man crying out for gets() to be removed from the C
> > standard. Double standards as well as inflammatory disinformation.
> >

>
> The proposal I published in comp.std.c was to make an
> Appendix to the standard where obsolescent features would be
> described, that are no longer part of the official standard.
>
> Nowhere I wanted to just delete gets(). Users that want to use it
> could use it using a compatibillity library based on that Appendix.
> Whether an implementation follows that (non-normative) standard
> Appendix is up to the implementation. Since all implementations have
> gets() NOW, building such a compatibility library would be
> very easy and most vendors would have it.
>
> You are just misrepresenting my proposal, and then... YOU accuse
> me of "double standards"!!!


If gets() is removed from the normative text of the standard, a
conforming implementation cannot declare it in <stdio.h>, and must
accept any user definitions of gets.

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-20-2006
Harald van Dijk wrote:
> If gets() is removed from the normative text of the standard, a
> conforming implementation cannot declare it in <stdio.h>, and must
> accept any user definitions of gets.
>


Yes, of course. Why should it be kept in stdio?
It should be in "obsolete.h", the header describing
"obsolete.lib" or "obsolete.a". To use gets, people
would just add
#include "obsolete.h"
and link with the appropiate library.

This is not just *forcing* people to avoid gets(), but
avoiding any official support for it, what is a different
approach.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-20-2006
jacob navia <(E-Mail Removed)> writes:
> Harald van Dijk wrote:
>> If gets() is removed from the normative text of the standard, a
>> conforming implementation cannot declare it in <stdio.h>, and must
>> accept any user definitions of gets.
>>

>
> Yes, of course. Why should it be kept in stdio?
> It should be in "obsolete.h", the header describing
> "obsolete.lib" or "obsolete.a". To use gets, people
> would just add
> #include "obsolete.h"
> and link with the appropiate library.
>
> This is not just *forcing* people to avoid gets(), but
> avoiding any official support for it, what is a different
> approach.


So you want to break existing code (by requiring it to add a #include
directive for a new header) *and* keep gets(). Sounds like the worst
of both worlds to me.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-20-2006
Keith Thompson wrote:
> jacob navia <(E-Mail Removed)> writes:
>
>>Harald van Dijk wrote:
>>
>>>If gets() is removed from the normative text of the standard, a
>>>conforming implementation cannot declare it in <stdio.h>, and must
>>>accept any user definitions of gets.
>>>

>>
>>Yes, of course. Why should it be kept in stdio?
>>It should be in "obsolete.h", the header describing
>>"obsolete.lib" or "obsolete.a". To use gets, people
>>would just add
>>#include "obsolete.h"
>>and link with the appropiate library.
>>
>>This is not just *forcing* people to avoid gets(), but
>>avoiding any official support for it, what is a different
>>approach.

>
>
> So you want to break existing code (by requiring it to add a #include
> directive for a new header) *and* keep gets(). Sounds like the worst
> of both worlds to me.
>


Yea of course I am always wrong.

The idea that wth some flag like
-std=c99compatible

that include file is automatically included doesn't come to your
mind at all as in

#ifdef __STDC99_COMPATIBLE__
#include "compatible.h"
#endif

in stdio.h

and the compiler would set __STDC99_COMPATIBLE__
if that flag was passed at compile time
 
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
lvalues and rvalues Nicklas Karlsson C Programming 127 05-05-2010 10:58 PM
conversion of array to pointer not limited to lvalues nicolas.sitbon@gmail.com C Programming 18 08-06-2008 04:41 PM
casts and lvalues jacob navia C Programming 68 06-27-2007 03:32 PM
Lvalues and Rvalues ramasubramanian.rahul@gmail.com C Programming 3 10-14-2006 09:55 PM
lvalues -> incomplete types Mantorok Redgormor C Programming 7 02-07-2004 03:45 PM



Advertisments