why they use the word modifies in c

[khatus]

Here i want to know why or in what sense the word modifies has been used.

[TimFox]

In English grammar, an adjective modifies the noun.

[Siwastaja]

As a side note, be careful with the listed modifiers. Constructing different datatypes was ****ed up in C originally, because these types are not compatible between different CPU architectures and operating systems, and producing portable code with them is difficult. This problem was finally fixed in 1999, with the C99 standard, which should be considered mature enough in 2020. C99 brings stdint.h, which gives you logically named and portable data types, such as:

int32_t: a signed number with 32 bits (range -2147483648 to +2147483647)
uint8_t: an unsigned number with 8 bits (range 0 to 255)

Int, long int, short int etc. can basically be "anything" and are not very useful, or at least you need to know the standard, and carefully consider they are what you actually want.

[coppice]

While lots of people write
    long i;
the full form is
    long int i;
so the word long has modified the word int.

[Doctorandus_P]

Completely agree wit Siwatiwatsa.

C is an old language and some of the stuff in it is for historical reasons, just to keep old code running.
C99 is some 30 years old now, and if you care about the number of bits in an integer, then use the typedef values from stdint.h.

These modifiers are not completely obsolete though.
If you look in stdint.h you will see things like:

Code: [Select]

/* Unsigned.  */
typedef unsigned char           uint8_t;
typedef unsigned short int      uint16_t;
typedef unsigned long int       uint32_t;
#ifdef __SDCC_LONGLONG
typedef unsigned long long int  uint64_t;
#endif
Edit:
About portability remark below:
The code above is a snippet from the SDCC compiler. The people who wrote that compiler know under what circumstances the comiler uses a particular number of bits for an "int". SDCC is a relatively simple compiler mostly made long ago for cross compiling 8051 stuff.
If you look at stdint.h from some of the many GCC variants then you'll see they have to go to a lot of trouble to make sure that an int16_t always is an int with 16 bits of data.

Obsolescence:
Using "long" "int" etc, is obsolete for program writers. It's not obsolete for for the compiler maintainers. Users should just never use "int" anymore since C99.

[janoc]

These modifiers are not completely obsolete though.
If you look in stdint.h you will see things like:

Code: [Select]

/* Unsigned.  */
typedef unsigned char           uint8_t;
typedef unsigned short int      uint16_t;
typedef unsigned long int       uint32_t;
#ifdef __SDCC_LONGLONG
typedef unsigned long long int  uint64_t;
#endif

(This version is from SDCC, which is a small C compiler. Header files of such compilers are often easier to read than from the big Compilers.)

They are not obsolete but are not portable at all. With the exception of signed/unsigned (which are useful in certain situations) they should be only used by the compiler writers to define these typedefs with an explicitly  specified size, nothing more (there is no other way in C to specify how many bits should a type have and the compiler authors know the type size for the architecture and their compiler).

In fact, the only type with an explicitly defined size in the standard is char which is defined as having 8 bits (a byte).

For ex. long int can be 32bits if you are on a 32bit x86 ABI and 64 bits if using the 64bit ABI on the same hw. The same for short and int. It also depends on the compilers.

[dmills]

Char is defined as the smallest addressable unit of memory, not as 8 bits.
There are conforming implementations where sizeof char == sizeof short == sizeof int == 1. The analogue devices Shark DSP springs to mind.

POSIX however does expect 8 bit bytes.

[coppice]

Char is defined as the smallest addressable unit of memory, not as 8 bits.
There are conforming implementations where sizeof char == sizeof short == sizeof int == 1. The analogue devices Shark DSP springs to mind.

POSIX however does expect 8 bit bytes.

Its not just the Shark that has an non-8bit char. Most DSPs had a char that was either 16 or 24 bits. There might well have been something with a 32 bit char, but I can't remember one off hand.

[dmills]

The shark is the one with the 32 bit char, being as the smallest addressable unit of memory on that processor is 32 bits. Perfectly compliant with the C standard.

[madires]

Some food for thought about portability:

Code: [Select]

int32_t      MyValue;
char         *Check = NULL;

MyValue = strtol(SomeString, *Check, 10);

vs.

Code: [Select]

long         MyValue;
char         *Check = NULL;

MyValue = strtol(SomeString, *Check, 10);

Which one is portable? Which one supports a 32-bit and a 64-bit CPU?

[coppice]

Some food for thought about portability:

Code: [Select]

int32_t      MyValue;
char         *Check = NULL;

MyValue = strtol(SomeString, *Check, 10);

vs.

Code: [Select]

long         MyValue;
char         *Check = NULL;

MyValue = strtol(SomeString, *Check, 10);

Which one is portable? Which one supports a 32-bit and a 64-bit CPU?

I assume the point you are trying to make is that there is a place for "give me the longest int" and "give me the natural, most efficient int". The stdint.h and inttypes.h files have types for this, alongside types like int32_t and int64_t. Using long is vague, and no guarantee of anything.

[Siwastaja]

Some food for thought about portability:

Code: [Select]

int32_t      MyValue;
char         *Check = NULL;

MyValue = strtol(SomeString, *Check, 10);

vs.

Code: [Select]

long         MyValue;
char         *Check = NULL;

MyValue = strtol(SomeString, *Check, 10);

Which one is portable? Which one supports a 32-bit and a 64-bit CPU?

The question makes little sense because strtol, by definition, returns long int, whatever it happens to be. It's only logical to store "long int" in "long int". But depending on system, it may be 32 bits, 64 bits, or something else. But you are limited by the library, not by your own code here.

strtoll returns long long int.

inttypes.h defines ( https://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html ) strtoimax, which returns intmax_t, which is the "maximum width integer type".

Sadly, writing portable code when using C standard library functions is far from trivial. Long long is guaranteed to be at least 64-bits, so neither of your examples works if you need portable 64-bit value from 32-bit and 64-bit systems. You need to use strtoll instead.

[coppice]

Sadly, writing portable code when using C standard library functions is far from trivial. Long long is guaranteed to be at least 64-bits, so neither of your examples works if you need portable 64-bit value from 32-bit and 64-bit systems. You need to use strtoll instead.

What is really sad is that people realised the limitations of the original C types very early on, but it took until 1999 to define sane types. By that time a huge amount of code has defined it own names for well controlled variable types, which are mutually incompatible, and all additions to the library up to C99 used poorly considered parameter and return types, because they had no sane ones to choose amongst.

[madires]

Sadly, writing portable code when using C standard library functions is far from trivial. Long long is guaranteed to be at least 64-bits, so neither of your examples works if you need portable 64-bit value from 32-bit and 64-bit systems. You need to use strtoll instead.

A 64-bit system most likely returns a 64-bit value for strtol(). So strtoll() would return a 128-bit value. But to be sure one would have to check. As you can see, strtoll() has the same issue as strtol(). intX_t and uintX_t make sure that you get the requested bit width, though they might cause a clash with library functions. Portability is a complex topic.

[TimFox]

Yes, I answered the original question:  "Here i want to know why or in what sense the word modifies has been used."
In English, the grammatical use is not the only meaning of "to modify".

[free_electron]

As a side note, be careful with the listed modifiers. Constructing different datatypes was ****ed up in C originally, because these types are not compatible between different CPU architectures and operating systems, and producing portable code with them is difficult. This problem was finally fixed in 1999, with the C99 standard, which should be considered mature enough in 2020. C99 brings stdint.h, which gives you logically named and portable data types, such as:

int32_t: a signed number with 32 bits (range -2147483648 to +2147483647)
uint8_t: an unsigned number with 8 bits (range 0 to 255)

Int, long int, short int etc. can basically be "anything" and are not very useful, or at least you need to know the standard, and carefully consider they are what you actually want.

This is the biggest source of problems with 'c'.  They lost an ariane rocket due to this idiocy ... the code was simulated on a 32 bit machine but compiled for a 16 bit microcontroller. yielding an overflow , steering the rocket off course.

[Siwastaja]

This is the biggest source of problems with 'c'.  They lost an ariane rocket due to this idiocy ... the code was simulated on a 32 bit machine but compiled for a 16 bit microcontroller. yielding an overflow , steering the rocket off course.

Yes, although to be fair, for low-level embedded work (with minimalistic C library, or completely own code), stdint.h from 1999 completely solves the issue, you just need to use it.

On higher level, the problem is still there because working with C standard library functions is still complex for portability.

[Nerull]

The Ariane code was was written in Ada, not C. Conversion of 64-bit floating point values to 16-bit values was a known possible issue but processor resources were limited so only 4 of the 7 such conversions in the code were given overflow protection. One of the three was the Horizontal Bias value, which was assumed to not overflow because it didn't on Ariane 4. Ariane 5's trajectory was different, which did cause an overflow. The overflow as detected and triggered an exception. The exception handling method was to assume that any exception indicated a processor fault and initiate CPU shutdown. Both redundant processors had the same error, both shut down, control was lost.

The issue had nothing to do with accidental conversions because they developed on one platform and ran the code on another. These were all explicit conversions between types, as Ada has a much stronger typing system than C.

[Karel]

As a side note, be careful with the listed modifiers. Constructing different datatypes was ****ed up in C originally, because these types are not compatible between different CPU architectures and operating systems, and producing portable code with them is difficult. This problem was finally fixed in 1999, with the C99 standard, which should be considered mature enough in 2020. C99 brings stdint.h, which gives you logically named and portable data types, such as:

int32_t: a signed number with 32 bits (range -2147483648 to +2147483647)
uint8_t: an unsigned number with 8 bits (range 0 to 255)

Int, long int, short int etc. can basically be "anything" and are not very useful, or at least you need to know the standard, and carefully consider they are what you actually want.

I completely agree.

Having said that, I always use int, long long, short, char, etc. (but never long because it can be 32 or 64 bit).
The reason is that I always use GCC so there's no need to use the standardized variables.
I also don't feel the need to be compatible with other compilers.

[coppice]

Having said that, I always use int, long long, short, char, etc. (but never long because it can be 32 or 64 bit).
The reason is that I always use GCC so there's no need to use the standardized variables.
I also don't feel the need to be compatible with other compilers.

For some target processors GCC's int is 16 bits, for others its 32 bits, and I think one of the MCU ports made it 8 bits.

[Doctorandus_P]

Karel's comment is not worth reading, nor commenting about.

I'm almost certain that an int is never less then 16 bits, but I really do not care anymore. It's just obsolete (for normal programmers). Just use the C99 typedefs.

A slight annoyance with my AVR programming (where every kB counts) is that the type for a switch is normally defined as at least 16 bits, while a switch() will very rarely have more then 256 cases and an uint8_t is fine, saves flash and execution time. GCC has a switch to use 8 bit var's for a switch(), but if you use it you are deviating from standards, and have to keep track of such details for the rest of eternity. Because long term maintenance of code is more important then such slight optimisations I decided to just live with the 16 bit vars for a switch().

It's part of the art of programming. If anyone else (or myself after a few years) ever reads that code, they will not get distracted (nor even notice) the thought that went into not deviating from standards. They (and I) have more important bugs to chase.

[Siwastaja]

Having said that, I always use int, long long, short, char, etc. (but never long because it can be 32 or 64 bit).
The reason is that I always use GCC so there's no need to use the standardized variables.
I also don't feel the need to be compatible with other compilers.

Wat?? No, no! int on gcc can be anything at least 16 bits, and actually often is 16, 32 or 64 bits!

16 bits on AVR (unless -mint8 is given on command line, in which case it's 8 bits (against C standard). When you need the performance, and you often do, use unsigned char or, even better, uint8_t in loops with max iteration count of 255, instead).
32 bits on ARM Cortex-M0 to ARM Cortex-M7
32 bits or 64 bits on Raspberry Pi, depending on what OS version you are running; this is an example where the number of bits in neither int nor pointers necessarily match the 64-bit CPU.
32 bits on some older PCs.
64 bits on most modern PCs.

All using GCC.

No, these are all systems you very likely encounter today, and no, limiting yourself to one compiler (such as gcc) doesn't help the slightest.

No problem in using int if you do realize your values are 100.000% surely never going outside range -32768 to +32767.

Know your ranges! stdint.h is great because the bit widths (hence, ranges) are explicitly given in the names, you don't have to remember the C standard.

If you use the old style names such as short int, long int, long long int, then it's best to really remember what the standard says about their widths, by heart.

Note that int32_fast_t is often the thing you actually want to use as a portable replacement for where you mostly used to use int. It's 32 bits on systems where int is 32 bits, and likely 64 bits on systems where int is 64 bits, but never 16 bits, which int might be.

Assuming int is always at least 32 bits is a common mistake; using int32_fast_t instead fixes that as it satisfies this assumption.

[Nerull]

I'm almost certain that an int is never less then 16 bits, but I really do not care anymore. It's just obsolete (for normal programmers). Just use the C99 typedefs.

'int' defaults to unsigned 8 bits in the CCS C Compiler for PIC18, though its a steaming pile of garbage in any case.

[Siwastaja]

'int' defaults to unsigned 8 bits in the CCS C Compiler for PIC18, though its a steaming pile of garbage in any case.

There are many special embedded and DSP "C" compilers which do not even try to implement the standard C language, but a C-like language of their own. There's nothing wrong with this, as long as you know it. This isn't always obvious, though. The purpose is to make the language look more appealing and easier to write small programs for people who do not know or have experience in the C language (and especially have never read the standard). This isn't necessarily a bad goal, either, and it provably works, but causes interesting clashes when someone more experienced in C tries to work with such tools.

[coppice]

16 bits on AVR (unless -mint8 is given on command line, in which case it's 8 bits (against C standard). When you need the performance, and you often do, use unsigned char or, even better, uint8_t in loops with max iteration count of 255, instead).
32 bits on ARM Cortex-M0 to ARM Cortex-M7
32 bits or 64 bits on Raspberry Pi, depending on what OS version you are running; this is an example where the number of bits in neither int nor pointers necessarily match the 64-bit CPU.
32 bits on some older PCs.
64 bits on most modern PCs.

All using GCC.

On a modern 64 bit PC a GCC "int" is a 32 bit value. I'm not sure about a 64 bit Raspberry Pi, but I think its the same. However, you are right about the AVR as well as the MSP430, PIC and other small machine ports using a 16 bit value for an "int". Your comment about the special mode for the AVR must be where I remembered the thing about 8 bit ints.

GCC was ported to some DSPs, so there might be machines with a 24 bit "int". There are certainly some other C compilers for DSPs where an "int' is 24 bits.