473,883 Members | 1,761 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

is "typedef int int;" illegal????

Hi

Suppose you have somewhere

#define BOOL int

and somewhere else

typedef BOOL int;

This gives

typedef int int;

To me, this looks like a null assignment:

a = a;

Would it break something if lcc-win32 would accept that,
maybe with a warning?

Is the compiler *required* to reject that?

Microsoft MSVC: rejects it.
lcc-win32 now rejects it.
gcc (with no flags) accepts it with some warnnings.

Thanks

jacob
---
A free compiler system for windows:
http://www.cs.virginia.edu/~lcc-win32

Mar 24 '06
134 9139
David R Tribble wrote:
....
Type names like 'long long' have the advantage of being decoupled
from the exact word size of the underlying CPU. That's why you
can write reasonably portable code for machines that don't have
nice multiple-of-8 word sizes.
int_least64_t shares that same characteristic in a more scalable
fashion.
Some programmers may prefer using 'int_least64_t' over 'long long'.
But I don't.


I would prefer using int64 over either of those alternatives, with
int64 being given the same meaning currently attached to int_least64_t.

Mar 29 '06 #81
Douglas A. Gwyn wrote:
ku****@wizard.n et wrote:
... It's specifically the choice of "long long" for the
type name that made it so objectionable.
Why is that objectionable?


Because it's the wrong solution, and adopting it into the standard
creates justification for anticipating (hopefully incorrectly) that
this wrong solution is the way that future versions of the standard
will handle new type sizes.
... It avoided using up another
identifier for a new keyword, did not embed some assumed
size in its name (unlike several extensions),
You consider that an advantage. I think it's a disadvantage to have a
type whose miniminum required size corresponds to 64 bits, but giving
it a name which does not make that fact explicit.

Also, I've heard it criticised because of the fact that it's form makes
it something unique in the standard: a doubled keyword that is neither
a syntax error nor eqivalent to the corresponding un-doubled keyword. I
don't know much about the internals of compiler design, but I've seen
comments on someone who thought he did, who claimed that this
distinction unnecessarily imposed an (admittedly small) additional
level of complexity on the parser.
and
matched the choice of some of the existing extensions.


I recognise the practical necesity of taking into consideration
existing practice. My criticism of 'long long' was aimed primarily at
those who created it in the first place as an extension to existing
implementations .

Mar 29 '06 #82
"Douglas A. Gwyn" <DA****@null.ne t> wrote:
jacob navia wrote:
lcc-win32 supports 128 bit integers. The type is named:
int128


We hope you defined the appropriate stuff in <stdint.h>
and <inttypes.h>, since that is what portable programs
will have to use instead of implementation-specific names.

Note also that you have made lcc-win32 non standards conformant.

^
even more
HTH; HAND.

Richard
Mar 29 '06 #83
ku****@wizard.n et wrote:

[ about "long long": ]
Also, I've heard it criticised because of the fact that it's form makes
it something unique in the standard: a doubled keyword that is neither
a syntax error nor eqivalent to the corresponding un-doubled keyword. I
don't know much about the internals of compiler design, but I've seen
comments on someone who thought he did, who claimed that this
distinction unnecessarily imposed an (admittedly small) additional
level of complexity on the parser.


More so than "long int", "signed int", and "unsigned short int" already
did? If so, I can't help thinking that the difference must have been
truly slight.

Richard
Mar 29 '06 #84
Douglas A. Gwyn a écrit :
jacob navia wrote:
lcc-win32 supports 128 bit integers. The type is named:
int128

We hope you defined the appropriate stuff in <stdint.h>
and <inttypes.h>, since that is what portable programs
will have to use instead of implementation-specific names.

Note also that you have made lcc-win32 non standards
conformant. You should have used an identifier reserved
for use by the C implementation, not one that is
guaranteed to be available for the application.


The use of int128 is only there IF you

#include <int128.h>

Otherwise you can use the identifier int128 as you want.

jacob
Mar 29 '06 #85
On 2006-03-29, jacob navia <ja***@jacob.re mcomp.fr> wrote:
Douglas A. Gwyn a écrit :
jacob navia wrote:
lcc-win32 supports 128 bit integers. The type is named:
int128

We hope you defined the appropriate stuff in <stdint.h>
and <inttypes.h>, since that is what portable programs
will have to use instead of implementation-specific names.

Note also that you have made lcc-win32 non standards
conformant. You should have used an identifier reserved
for use by the C implementation, not one that is
guaranteed to be available for the application.


The use of int128 is only there IF you

#include <int128.h>

Otherwise you can use the identifier int128 as you want.

jacob


In that case, why not use stdint.h and int128_t, int_least128_t, and
int_fast128_t?
Mar 29 '06 #86
On 2006-03-29, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
ku****@wizard.n et wrote:

[ about "long long": ]
Also, I've heard it criticised because of the fact that it's form makes
it something unique in the standard: a doubled keyword that is neither
a syntax error nor eqivalent to the corresponding un-doubled keyword. I
don't know much about the internals of compiler design, but I've seen
comments on someone who thought he did, who claimed that this
distinction unnecessarily imposed an (admittedly small) additional
level of complexity on the parser.


More so than "long int", "signed int", and "unsigned short int" already
did? If so, I can't help thinking that the difference must have been
truly slight.


Those still have only one of each keyword present. It's not like "long
long" acts as a 'pseudo-keyword' - "long int signed long" is a valid
name for the type.
Mar 29 '06 #87
Jordan Abel wrote:
On 2006-03-29, jacob navia <ja***@jacob.re mcomp.fr> wrote:
Douglas A. Gwyn a écrit :
jacob navia wrote:
lcc-win32 supports 128 bit integers. The type is named:
int128
We hope you defined the appropriate stuff in <stdint.h>
and <inttypes.h>, since that is what portable programs
will have to use instead of implementation-specific names.

Note also that you have made lcc-win32 non standards
conformant . You should have used an identifier reserved
for use by the C implementation, not one that is
guaranteed to be available for the application.


The use of int128 is only there IF you

#include <int128.h>

Otherwise you can use the identifier int128 as you want.

jacob

In that case, why not use stdint.h and int128_t, int_least128_t, and
int_fast128_t?


Because that would force ALL users of stdint.h to accept int128_t and
all the associated machinery, what is probably not what all of them want.

But the name int128 is not "cast in stone" and since I suppose the names
intXXX_t are reserved I could use those.

Basically this type is implemented using lcc-win32 specific extensions
like operator overloading, what allows to easily define new types. This
extensions are disabled when you invoke the compiler under the "no
extensions" mode. If I would put the 128 bit integers in the stdint
header, the operator overloading required would not work under the "ansi
c" environment, and problems would appear. That is why I use a special
header that will be used only by people the want those integer types.

Of course there is a strict ANSI C interface for 128 bit integers, but
if you use it, you would have to write

int128 a,b,c;
...
c = i128add(a,b);

instead of

c = a+b;
Mar 29 '06 #88
jacob navia schrieb:
Douglas A. Gwyn a écrit :
jacob navia wrote:
lcc-win32 supports 128 bit integers. The type is named:
int128


We hope you defined the appropriate stuff in <stdint.h>
and <inttypes.h>, since that is what portable programs
will have to use instead of implementation-specific names.

Note also that you have made lcc-win32 non standards
conformant. You should have used an identifier reserved
for use by the C implementation, not one that is
guaranteed to be available for the application.


The use of int128 is only there IF you

#include <int128.h>

Otherwise you can use the identifier int128 as you want.


This is IMO no good solution; if someone defined
typedef struct {
....
} int128;
in a library and one of your users wants to use this
library and another one which uses the
implementation-provided 128 bit exact width signed
integer type, he or she runs into a rather unnecessary
problem.
IMO, providing appropriate definitions in the
appropriate headers is better.

FWIW: I have seen enough "int64" and "Int64" structure
typedefs to assume that there may be the same for
128 bits.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Mar 29 '06 #89
"David R Tribble" <da***@tribble. com> wrote in message
news:11******** *************@i 39g2000cwa.goog legroups.com...
David R Tribble wrote:
I'm still waiting for a standard macro that tells me about endianness
(but that's
a topic for another thread).

Wojtek Lerch wrote:
One macro, or one per integer type? C doesn't disallow systems where
some
types are big endian and some little endian.

C doesn't even disallow "mixed endian" -- any permutation of bits is OK.
Would you just classify those as "other", or do you have something more
complicated in mind? Or would you just ban them?

And what about padding bits -- how useful is it to know the endianness of
a
type if you don't know where its padding bits are?


Something along the lines of:
http://david.tribble.com/text/c9xmach.txt


I have to say that I find it rather vague and simplistic, and can't find
where it answers my questions. I have absolutely no clue how you wanted to
handle implementations that are neither clearly little-endian nor clearly
big-endian. You didn't propose to ban them, did you?

/* Bit/byte/word order */

#define _ORD_BIG 0 /* Big-endian */
#define _ORD_LITTLE 1 /* Little-endian */

#define _ORD_BITF_HL 0 /* Bitfield fill order */
#define _ORD_BYTE_HL 0 /* Byte order within shorts */
#define _ORD_WORD_HL 0 /* Word order within longs */

What about implementations with one-byte shorts? What if the bit order
within a short doesn't match the bit order in a char? What if the byte
order within a two-byte short doesn't match the byte order within a half of
a four-byte long? What about the halves of an int? What about
implementations with three-byte longs? What if the most significant bits
sit in the middle byte? Or if the three most significant bits are mapped to
the least significant bit of the three bytes?
This was written in 1995, before 'long long' existed, so I'd have
to add a few more macros, including:

#define _ORD_LONG_HL n

My suggestion is just one of hundreds of ways to describe
endianness, bits sizes, alignment, padding, etc., that have been
invented over time. None of which ever made it into ISO C.


Perhaps because they all made the incorrect assumption that in every
conforming implementation, every integer type must necessarily be either
little endian or big endian?

Personally, I think it would be both easier and more useful not to try to
classify all types on all implementations , but instead to define names for
big- and little-endian types and make them all optional. For instance:

uint_be32_t -- a 32-bit unsigned type with no padding bits and a
big-endian representation, if such a type exists.

The representation is big-endian if:

* for any two value bits located in different bytes, the bit whose byte
has a lower address represents a higher value
* for any two value bits located in the same byte, the order of their
represented values matches the order of the values they represent in
unsigned char
Mar 29 '06 #90

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
3746
by: Fao | last post by:
Hi, I am in my first year of C++ in college and my professor wants me to Write a Program with multiple functions,to input two sets of user-defined data types: One type named 'Sign' declared by "typedef" to contain only either +10 or -10 and the other type named Color declared by "enum" to contain only black, blue, purple, red, white, and yellow.
0
9944
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9796
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11153
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10757
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10420
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7975
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5804
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4620
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3239
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.